Using the CSL Debugger
The CMWB includes a debugger that allows you to suspend the flow of execution of CSL modules at a specified breakpoint, that is, at the evaluation of a specified formula or rule. When the flow of evaluation is suspended, the debugger allows you to examine the following:
• Context of evaluation of the formula or rule
• Values of all in-scope formulas and rules
• Values of all in-scope CSL standard inputs (as well as values of all the inputs’ fields, and so on, recursively)
Following are some tips on using the debugger:
• Save your changes before you run the debugger—otherwise you might not be evaluating the code you expect. The last saved code is always the one evaluated.
• Ensure that the part you have open in aPriori Desktop is using the VPE and process group you currently have open in the debugger
• When you select Show Debug Panel from the View menu, the debug panel may sometimes be collapsed to a very narrow pane on the right-hand side of the CMWB—just drag the edge to make it bigger.
• Before returning to work with the current part in aPriori, remember to Click the stop button, 
.
.The debug panel also includes a profiler that allows you to determine the proportion of costing time spent on the evaluation of each module, formula, and rule.
Displaying the Debugger
The debug pane is located to the right of the editing pane, and is visible by default. To display it if it is not visible, select Show Debug Panel from the CMWB View menu.
For releases prior to 2018 R1 SP1, you might need to drag the edge of the editing pane to the left to display the debug pane.
Adding Breakpoints
Add a breakpoint as follows: in the editing pane, right click a formula name or rule name and select Add Breakpoint from the context menu.
Alternatively, ensure that the debugger is displayed, and follow the steps below. These steps allow you to add a conditional breakpoint, which stops execution at a specified location only when a specified condition is met:
1 Click Add Breakpoint to display the Breakpoint Properties window.
If this button is disabled, open the CSL file that contains the formula for which you want to set the breakpoint.
2 Select the breakpoint type and a formula or rule.
Select Formula to select a CSL formula from the drop-down list. Select Rule to select a rule from the drop-down list.
3 Select the breakpoint condition.
Select Always halt to stop cost modeling as soon as the formula or rule finishes. Select Halt only if to specify an additional condition under which costing is suspended. For example, you might suspend costing only when a certain boundary condition obtains, for example when gcd.name == ‘SimpleHole:1’.
4 Click OK to close the window and display the breakpoint on the Breakpoints tab of the debug pane.
To remove a breakpoint, right-click on it in the Breakpoints tab, and select Remove from the context menu.
Running the Debugger
Click 
to perform costing until the cost engine evaluates the specified formula or rule.
to perform costing until the cost engine evaluates the specified formula or rule.If the CSL file containing the breakpoint is open, the line containing the formula is highlighted and displayed.
Click Continue to resume costing until the cost engine reaches the next breakpoint. Note that a single breakpoint can be hit many times in a single cost event. Consider, for example, an operation for a given GCD type, such as SimpleHole. Since the operation may be performed multiple times (once for each GCD of that type), a breakpoint in such an operation may be hit multiple times.
Click to stop the debugger.
to stop the debugger.When costing is suspended at a breakpoint, the debugger displays information in the following tabs:
• Breakpoints: current breakpoints and context of evaluation of the formula or rule. This tab displays the evaluation stack, including the following:
o Other formulas or rules whose evaluation required evaluation of the breakpoint
o Current process or operation
o Current operation sequence (if any)
o Current material stock (if any)
o Current process routing
o Current GCD
• In-scope Formulas: values of all in-scope formulas and rules
• Inputs/Formula Results: values of all in-scope CSL standard inputs (as well as values of all the inputs’ fields, and so on, recursively). Expand nodes of the tree to see field values. Alternatively, enter a search string in the search field and click Find:
Check any combination of the checkboxes to indicate the search domain:
o Property: search for occurrences of a string in the Name column of the tree.
o Value: search for occurrences of a string in the Value column of the tree.
o Path: search for occurrences of a string in the full path to an input’s field (the full path to the length field of the input stock, for example, is stock.length).
You can specify multiple, space-separated search strings; tree nodes are matched only if they contain all the search strings. To search for a string that contains spaces (this only applies to field values), enclose the whole string in double-quotes.
Click on a search result to highlight the result in the tree. Search results are initially sorted by the level of the tree in which the result occurs (users can re-sort by clicking a column heading).
The search covers the number of levels of the tree specified in the Depth field. This is set to 5, initially, but you can decrease the depth to 1, or increase it to 10. In many cases, the greater the depth at which a result appears, the less relevant it is likely to be. (System administrators can configure the maximum available depth by setting the property ide.display.inputs.max.search.depth in apriori.properties—see the System Administration Guide. Note that search depths significantly higher than 10 run the risk of long search times and, in some cases, exhausting the Java heap.)
You can enter a CSL expression in the Dynamic CSL Evaluation pane, below the editing pane. Click in the evaluation pane (or type Ctrl + Enter) to display the result of evaluating, in the current context, the expression you entered.
in the evaluation pane (or type Ctrl + Enter) to display the result of evaluating, in the current context, the expression you entered.You can also drag an item from the Inputs/Formula Results tree into either an open CSL module or the Dynamic CSL Evaluation pane to get a full path reference to the item. See Dragging Items from the Inputs/Formula Results Tree for more information.
Note that you can undo and redo actions performed in the Dynamic CSL Evaluation pane (in the usual way, by selecting Undo or Redo from Edit menu or by typing Ctrl+Z or Ctrl+Y, when the focus is on the evaluation pane).
Dragging Items from the Inputs/Formula Results Tree
You can drag an item from the Inputs/Formula Results tree into either an open CSL module or the Dynamic CSL Evaluation pane to get a full path reference to the item, in the current debugger context (see Running the Debugger).
If you drag an item into the Evaluation pane or a CSL module, and the path to the item does not include a collection (that is, if the dragged item has no ancestor in the Inputs/Formula Results tree that is a collection), the code that appears is appropriate for use in CSL logic to refer to the dragged item.
However, if the path to the dragged item does include a collection, you must modify the code that appears in order to render it appropriate for inclusion in a CSL module. You can modify the code to do any of the following:
• Refer to the dragged item.
• Refer to a collection of items that are on the same level of the tree as the dragged item and that have the collection as an ancestor.
• Aggregate a collection of values (by taking the sum or maximum, for example) that include items that are on the same level of the tree as the dragged item and that have the collection as an ancestor.
See the following sections for more information:
Paths with One Collection
If the path to the dragged item includes one collection, the Cost Model Workbench displays the following dialog which lets you choose a code style.
In CSL, collection elements are typically accessed in one of the following ways:
• select expression: this is similar to an SQL select statement; it treats the collection as a table with one row for each element and with columns for properties of the elements. See Query. You must modify the select expression in order to focus in on the item or items of interest (see below).
• foreach expression: this is a loop that processes each collection element in turn, and builds up a set of results, or formulates a single result. See Foreach Expressions. You must modify the foreach expression in order to focus in on the item or items of interest (see below).
• listGet call: a call to listGet returns the collection element at a specified position. See listGet(list, i).
• Important Note: the listGet call is not appropriate for use in a CSL module, because the collection element in the path is identified by its position in the collection (the second argument to ListGet), which is often arbitrary and/or unstable. With select and foreach expressions, in contrast, the collection item or items of interest are generally identified by their property values; the dragged item, for example, might be identified as the diameter of the collection element with the largest diameter—see the examples below.
If you choose either select expression or foreach expression, one or both of the following sorts of modifications is generally needed:
• Use of a where clause (for select) or conditional (for foreach) to narrow down the selected items, so as to help identify the items of interest.
• Use of an aggregation function to further focus in on items of interest, to uniquely identify an item of interest, or to aggregate values of interest.
See Paths with One Collection: select expresion and Paths with One Collection: foreach expression, below, for more information.
Paths with One Collection: select expresion
This section contains an example of modifying the code that appears when you drag an item, so that the code refers to the dragged item. Consider the path to the diameter of the current part's largest-diameter SimpleHole. This path goes from the part to the collection of its childArtifacts (child GCDs), to the part's largest-diameter SimpleHole, to that hole's diameter.
Suppose you drag this diameter item to the Evaluation pane, then choose select expression from the Select code style dialog. The Evaluation pane is populated with a select expression that requires changes. If you evaluate the unmodified expression, an exception results because some of the selected collection elements lack a diameter property (that is, some child GCDs of the part, such as PlanarFaces, don't have a diameter property).
The expression requires two changes which effectively single out the collection element of interest; that is, the collection element in the path to the dragged object:
1 Addition of a where clause: since the element of interest is a SimpleHole, the where clause must filter the selected objects to include only SimpleHole GCDs. This change eliminates the cause of the exception, since all SimpleHole GCDs have a diameter property. The modified expression evaluates to a collection whose elements are the diameters of the part's SimpleHoles.
2 Addition of an aggregation function: with the where clause, the select expression evaluates to a collection of diameters rather than just the largest diameter. You can single out the largest diameter by using the query-aggregation function max:
Paths with One Collection: foreach expression
If you choose foreach expression instead of select expression from the Select code style dialog, the Evaluation pane or CSL module is populated with a foreach expression. This expression may require changes that focus in on, and possibly aggregate, items of interest. If you evaluate the unmodified expression, an exception may result, as with the select expression (described above).
One or both of the following sorts of changes are generally required:
1 Conditional assignment of the iteration variable: the foreach loop must filter the results to include only the specific objects or values of interest (diameters of SimpleHoles, in the example).
2 Replacement of the aggregation function: the unmodified foreach expression uses the foreach-aggregation function getAll. You can further narrow or aggregate the foreach results by using a different aggregation function. This example singles out the largest diameter by using the foreach-aggregation function getMax:
Paths with Two Collections
If you drag an item to the Evaluation pane or a CSL module, and the path to the dragged item includes exactly two collections, the Cost Model Workbench displays the following dialog:
If you choose foreach wrapping select, the Evaluation pane or CSL module is populated with a foreach expression whose body contains a select expression. This code requires changes in order to aggregate or focus in on items of interest.
Suppose, for example, you want to construct a CSL expression that evaluates to the surface area of the part's largest-surface-area SimpleHole. To start, you might drag to the Evaluation pane the finishArea (surface area) item of a CurvedWall child of one of the part's SimpleHoles. (SimpleHoles have no surface area property, so the code we construct will reference the hole's CurvedWall children.) This path goes from the part to the collection of its childArtifacts, to the SimpleHole, to the collection of that SimpleHole's childArtifacts, to the CurvedWall, to the areaFinished of that CurvedWall.
Now suppose that, after dragging the finishArea item, you choose foreach wrapping select from the Select code style dialog. The Evaluation pane is populated with an initial CSL expression based on the dragged item. In most cases, evaluating the unmodified expression will result in an exception due to certain collection elements visited by the select statement lacking an areaFinished property.
The following changes are required to render this code appropriate for use in a CSL module:
1 Addition of a where clause: the first collection in the path is that containing the part’s top-level GCDs. It includes the SimpleHole that appears within path to the dragged item. From this collection, the path to the dragged item includes a CurvedWall, so we use a where clause to filter the objects selected from this collection so as to include only CurvedWall GCDs. This change eliminates the cause of the exception since all CurvedWall GCDs have an areaFinished property. The modified expression evaluates to a collection whose elements are collections of areaFinished values. There is one collection of areaFinished values for each of the part's children that itself has CurvedWall children. Each sub-collection contains the areaFinished values for the CurvedWall children.
2 Conditional assignment of the iteration variable: we now have areaFinished values for CurvedWall GCDs, but some of these may belong to top-level GCDs of types other than SimpleHole. We stated earlier we were only interested in SimpleHoles, so we need to filter the collection of top-level GCDs to remove non-SimpleHole types. We use conditional assignment of the foreach expression’s iteration variable to achieve this:
3 Addition of a query-aggregation function: with the where clause and foreach conditional assignment, the expression evaluates to a collection of pairs (since each SimpleHole has exactly two CurvedWall children). You can obtain the total surface area for each SimpleHole by introducing the aggregation function sum to the select expression. In effect, this adds together the two areaFinished values in each pair:
4 Addition of a foreach-aggregation function: with the use of the query-aggregation function, the expression evaluates to a collection of surface area values. We can now single out the largest of these values with the foreach-aggregation function getMax:
If, instead of foreach wrapping select, you choose select from right-most collection, the code that appears uses a select expression that queries elements from the collection that is nearest the dragged item, i.e. the right-most collection in the path to the dragged item. The generated expression includes calls to listGet, which must be replaced in order to render the code appropriate for use in CSL module.
If you choose listGet, the code that appears is not suitable for inclusion in a CSL module, but rather is for diagnostic purposes only.
Paths with More than Two Collections
If you drag an item to the Evaluation pane or a CSL module, and the path to the dragged item includes more than two collections, the Cost Model Workbench displays the following dialog:
If you choose select from right-most collection, the code that appears uses a select expression that queries elements from the collection that is nearest the dragged item, i.e. the right-most collection in the path to the dragged item. The generated expression includes calls to listGet, which must be replaced in order to render the code appropriate for use in CSL module.
If you choose listGet, the code that appears is not suitable for inclusion in a CSL module, but rather is for diagnostic purposes only.