This topic is designed to show you how to improve performances when working with Knowledge Expert rules in large models.
The proposed solutions to improve performances are the following:
To do so, it is highly recommended to use the
> operator when working with 2 identical
types.
WireA : Wire;WireB : Wire |
Not recommended: In the example opposite,
the same type (wire) is used twice to compute the distance between two
wires : we go through the rule n² times, n being the number of wires in the document. We have three wires (wire1,wire2, and wire3), so the following combinations are possible: wire1/wire1, wire1/wire2, wire1/wire3, wire2/wire1, wire2/wire2, wire2/wire3, wire3/wire1, wire3/wire2, wire3/wire3. The rule goes through each combination. |
WireA : Wire;WireB : Wire
|
Recommended: The combination wire1/wire1
is not useful to compute the distance, and the distance between wire1/wire2,
and wire2/wire1 is identical. The only way to optimize the rule is to
add the following statement: WireA>WireB (see opposite.) The rule
is then solved n*(n+1)/2 times. Warning: The weight of each variable cannot be foreseen. In the example, WireA is superior to WireB. With 3 wires (wire1, wire2, and wire3), it is impossible to know in advance if wire1 > wire2 or if wire2 >wire1. It is a a way to eliminate combinations that are not interesting. |
When using the logical operators And/ Or in a condition, make sure that the condition is structured as follows:
And Condition: In the example below, we use the Elec_DistanceCommon
function, which is very time-consuming. So, before using this function, we use conditions
that will eliminate some cases: if one of the wires is not blue, the other conditions
(WireB.Elec_Color == "red" AND Elec_DistanceCommon(WireA,WireB) > 100mm)
will not be examined.
WireA : Wire; WireB : Wire
|
Or Condition: In the example below, if one of the wires is blue, the message
is fired without evaluating the other conditions, that is to say Elec_DistanceCommon
which is time-consuming.
WireA : Wire; WireB : Wire
|
It is strongly recommended to use attributes instead of using the GetAttribute method.
So, instead of writing:
P:Part |
Write:
P:Part |
When creating rules, use the Knowledge Expert language. Its scope is limited
because it allows the use of the
If...then
keywords only, but only in this case the process time will be optimized.
Therefore avoid using the following constructs:
It is recommended to use at most 2 variables. A possible workaround consists in finding the second object using the first one.
For example, when working with electrical applications, we may use two objects, the bundle and the wire. The following rule is valid:
Bundle : BundleSegment ; Wire : Wire
|
But this rule is not optimized. This is especially true if you have many bundles and wires. The rule below is optimized, the rule is solved a limited number of times:
Bundle : BundleSegment
|
To reduce the process time, if you know the objects that you want to work on, use CAA to provide the solver with instances.
Prefer Manual Update instead of Automatic Update when working in a Part context. Using the Automatic Update increases the global computation time when using a complex Rule Base.
You can manually update a Rule Base by:
either Right-clicking the rule base and selecting RuleBase Object > Manual Complete Solve
or Right-clicking the rule base and selecting RuleBase Object > Manual Optimized Solve
A Rule base runs globally on a whole document. i.e. a Rule Base takes into account the whole document and not a single modified item.