> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Optimize Group element search
> Optimize Group element search in FlexiLayout Studio: quality-1 chains halt hypothesis generation, so apply FuzzyQuality penalties for correct detection.
If all the hypotheses of the chain of elements in the **Group** element have the quality value of 1, then the other hypotheses of these elements will not be analyzed.
This is done to optimize the FlexiLayout, to speed up the matching procedure, and to avoid the unwanted "branching" of the tree of hypotheses. However, a hypothesis that is optimal for FlexiLayout Studio does not necessarily correspond to the sought object on the image.
This might happen if the search constraints for the element are not strict enough. When such a situation arises, first analyze the parameters set for the element search.
## The `GO.fsp` sample project
Consider the project `GO.fsp` (folder `%public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1`), where the goal is to find the field "Invoice number".
The project has two pages:
* **Page 1** – The image quality is good.
* **Page 2** – The name of the sought field is noisy.
The project contains the group **InvoiceGroup**, which contains the element used to search for the field name: a **Static Text** element named **InvoiceHeader** with the value "INVOICE".
To search for the field "Invoice number" itself, the project uses a **Character String** element named **InvoiceNumber**. The search constraints for the field relative to the name are specified in the **Relations** section of the **InvoiceNumber** element.
The letter case of the name in the **Search text** section is irrelevant.
## Why hypothesis generation stops at a quality-1 chain
Note that the string "Invoice" specified as the value for the **InvoiceHeader** element occurs on the images three times: as the name of the "Invoice number" field, as a substring in the name "Invoice date", and at the bottom of the invoice, as a substring in the payment conditions "Current **invoice** is…".
You can therefore predict that there will be three hypotheses after the matching procedure.
After running the FlexiLayout matching procedure by selecting the **Match** command, you can see that the tree of hypotheses in the **Group** element **InvoiceGroup** has only one complete chain instead of the expected three, and that single chain does not correspond to the name being detected.
If you look at the properties of each of the elements in the generated chain, you will see that the **Chain quality** of each hypothesis is 1, which triggered the optimization: when FlexiLayout Studio detects an ideal chain in terms of quality (that is, a chain with the quality of 1), it stops generating hypotheses.
To see the tree of hypotheses of the group, double-click the name of the **Group** element in the tree of hypotheses, or press **Enter**, or select **Show Details** from the shortcut menu.
The FlexiLayout Studio algorithm determines which object of the image is preferred over the others during hypothesis generation.
Since the results of matching the FlexiLayout are unsatisfactory, the reasons for the problem need to be analyzed to decide how it can be solved.
First, the search area for the **InvoiceHeader** element is not limited. Second, the description of the **InvoiceNumber** element specifies that the string of digits can be of any length (because the possible length of the invoice number is not known). It also specifies that the string should be looked for to the right of the name, at approximately the same horizontal level.
As you can see, all three instances of the word "Invoice" match these conditions. That is why the incorrect detection of the name automatically caused the incorrect detection of the field "Invoice number". You must add some limiting constraints so that the correct hypothesis is the best in the end, and the FlexiLayout is optimal not only in terms of matching speed.
## Anchor the name to the right page edge with Nearest
If the arrangement of the fields is assumed to be identical on all the pages of the project, the easiest way is to "tell" FlexiLayout Studio that the required string "Invoice" is the element nearest to the right edge of the page. To do this, write the following code in the **Advanced pre-search relations** section of the **InvoiceHeader** element: `Nearest: PageRight;`.
This works because the name of the sought field "Invoice number" is the *only* element nearest to the right edge of the page. If this were not the case, or if the document were not formalized, the `Nearest` function could not solve the problem.
## Penalize distant number hypotheses with FuzzyQuality
Alternative ways to perform this task, including the case of a semi-structured document, are shown in the `GO.fsp` project (folder `GO\2`).
As you can see on the images, the distance between the digit string and the word "invoice" is the smallest in the sought field "Invoice number".
This is true on all the pages, which makes it possible to affect the quality values of generated hypotheses by entering the following code in the **Advanced post-search relations** section of the **InvoiceNumber** element:
```text theme={null}
if (not InvoiceHeader.IsNull) and (not IsNull) then
{ FuzzyQuality: Rect.Left - InvoiceHeader.Rect.Right, {0, 0, 0, 10000}*dt; }
```
This means that if both elements are detected, the distance between the elements is calculated for the hypothesis of the **InvoiceNumber** element, and FlexiLayout Studio checks whether it belongs to the interval `{0, 0, 0, 10000}*dt`.
This description of the interval shows the linear dependency between the quality of the hypothesis and the distance between the elements: the longer the distance, the greater the penalty (the `FuzzyQuality` function returns the post-search quality of the hypothesis, which can be seen in the **Properties** window of the hypothesis).
The value for the right boundary of the interval (10000dt) was determined experimentally. When choosing this value, you should take into account the distance between the corresponding objects on test images.
As the following figure shows, under the specified interval properties, the maximum penalty (1) will correspond to a distance of 10000dt. Accordingly, a distance of 1000dt will bring a penalty of 0.1, a distance of 100dt a penalty of 0.01, and so on.
So for real distances of about 100-300 dots, which can be seen on the images, the penalty coefficient will be 0.99-0.97.
For more information about the use of these functions, see [Search for elements with Nearest and FuzzyQuality](/flexi-capture/fls/tips-tricks/date9).
For the images in this batch, the hypothesis corresponding to the unwanted field "Invoice number" with the value "2005" got the maximum penalty, while the hypothesis corresponding to the sought field got the minimum penalty.
Since penalizing made the **Post-search quality** of all the hypotheses different from 1, all the hypotheses of both elements of the **Group** element **InvoiceGroup** will now be analyzed.
Note that the field "Invoice number" was correctly detected even on page 2, where the name "Invoice" is very noisy, which caused a recognition error and, consequently, additional penalties for the hypothesis.
