Using Query-Based Selection

Considerations for Efficient Dynamic Queries

Dynamic queries impact performance of a simulation and should be used judiciously. Generally, this performance cost occurs during editing (that is, when objects are added to or removed from the query selection) and not during long-running actions such as meshing and solving.

Factors

Common factors that impact query performance include:

• Order of appearance of the predicates
• Number of objects to evaluate
• Number of predicates to evaluate
• Combination of predicates employed
• Types of objects to be queried

Strategies

• Multiple-level nested query predicates impact evaluation times. Try to write short, efficient queries.
• Query predicates that eliminate the most objects should usually be placed first in the query predicate list. This limits the number of objects evaluated for the successive predicates.

  Less effective query	More effective query

  For more details, see Example of How Sequence Affects Query Effectiveness.
• When possible, join predicates with AND rather than OR.
• Some predicate types are more efficient than others. Type, Name, and Tag predicates are typically more efficient. Relationship, Metadata, and Inherited Parts predicates are the least efficient.

  Even the least efficient predicates are appropriate when they provide the desired results in the shortest query.

Activating a Dynamic Query

To activate a dynamic query:

1. Click the query editor button () in the right half of the property (typically the Parts property).
   
   
2. Define the query for selecting objects. The techniques for defining this query are the same as those for a filter. For details, see Using Filters.
   
   

   At the bottom left of the dialog, text indicates the number of matches.

Prioritizing Assignment of Parts

When you use dynamic query selection to assign parts across a number of similar objects, you can find that an additional level of prioritization is necessary. Simcenter STAR-CCM+ allows you to define the order of priority in which objects receive parts through dynamic query selection. Objects that come higher in the list receive parts in preference to objects that come after them.

The types of objects to which you can prioritize assignment are regions, boundaries, subgroupings (on regions and boundaries), and boundary interfaces. For these types of objects, the manager node that contains them exposes a property, Part Selection Priority, that contains the priority list. The order in which objects appear on the priority list sets the order in which Simcenter STAR-CCM+ assigns parts to those object properties that require them—when dynamic queries are used in place of a static list of parts.

For example, suppose that you have two regions existing within the Regions node, EngineRegion and CompressorRegion. You require that EngineRegion is automatically assigned all parts that have Engine in the name, and that CompressorRegion is automatically assigned all parts with Compressor in the name. For the Parts property of the EngineRegion, you define the dynamic query, Name contains Engine, and for the Parts property of CompressorRegion, you define the dynamic query, Name contains Compressor.

These queries successfully assign parts such as Compressor-Duct-1, Compressor-Chamber-1, Engine-Port-1, Engine-Port-2, and so on. However, if you then add a part, Engine-Compressor-Inlet1, you cannot tell in advance whether EngineRegion or CompressorRegion receives the part.

To make sure that such a part gets assigned to CompressorRegion, use the following technique:

1. Select the Regions manager node.
2. In the Part Selection Priority property, click (Custom Editor).
3. In the Regions - Part Selection Priority dialog, specify the order of priority. In this example, you make sure that CompressorRegion appears at the top of the list. .
   
   

   Use any of the buttons (top to bottom) as follows:

   • Move to top: move the region to the top of the list
   • Move up: move the region up one position
   • Move down: move the region down one position
   • Move to bottom: move the region to the bottom of the list
   • Alphabetize entire list: reorder the items alphabetically
4. Click OK.

Now, when Simcenter STAR-CCM+ detects that the dynamic queries for both CompressorRegion and EngineRegion can accept the part, Engine-Compressor-Inlet1, Simcenter STAR-CCM+ gives priority to CompressorRegion over EngineRegion.

Consider the following as you work with these objects:

• Regions with statically assigned parts (that is, using the standard technique for manually assigning parts to regions) will take priority over regions with dynamically assigned parts, regardless of the order specified in the part selection priority dialog. They appear in the dialog to allow setting priority before or after you assign queries. However, once you assign a part statically, the only way to remove it is to deselect it manually or assign it to another region.
• Boundaries and boundary interfaces work the same way as regions. However, since only boundary interfaces are assigned part contacts, non-boundary interfaces do not get listed in the part selection priority dialog.

Example of How Sequence Affects Query Effectiveness

This example shows how you can reduce the number of objects scanned by the query from 54,800 to 25,450, shortening the time required for evaluation. Consider a simulation with the following contents:

• There are 25,000 objects that can be scanned by a query.
• 5,000 of them are geometry parts.
• 100 of the geometry parts are specifically composite parts.
• 250 of the 25,000 objects contain the word steel in their name.
• Among the 250, 200 are geometry parts including 5 specifically composite parts.

The goal is to write a dynamic query that returns all geometry parts that are not composite parts and that contain the word steel in the name.

A query filter with the following three predicates, connected by AND, return the correct results:

1. Type IS NOT Composite Part
2. Type IS Geometry Part
3. Name CONTAINS steel

When considering the time required to perform the query filter evaluation, order is important. Consider the order in the list above:

1. Type IS NOT Composite Part—the predicate scans 25,000 objects and returns 24,900.
2. Type IS Geometry Part—the predicate scans the remaining 24,900 objects and returns 4,900.
3. Name CONTAINS steel—the predicate scans the remaining 4,900 parts and returns 195.

The total number of objects scanned is 54,800.

Understanding the makeup of the simulation can help improve the efficiency of the above query filter. The first predicate scans 25,000 objects and only eliminates 100. The second predicate eliminates all but 4,900, so the result of re-ordering the first two predicates produces a more efficient query:

1. Type IS Geometry Part—the predicate scans 25,000 objects and returns 5,000.
2. Type IS NOT Composite Part—the predicate scans 5,000 objects and returns 4,900.
3. Name CONTAINS steel—the predicate scans the remaining 4,900 parts and returns 195.

The total number of objects scanned is 34,900.

The query filter can be improved even further by knowing that there are not many objects with names containing steel:

1. Name CONTAINS steel—the predicate scans the remaining 25,000 parts and returns 250.
2. Type IS Geometry Part—the predicate scans 250 objects and returns 200.
3. Type IS NOT Composite Part—the predicate scans 200 objects and returns 195.

The total number of objects scanned is 25,450, fewer than half the scans of the first and more than 9,000 fewer than the second.