5.1.6. The Conditional Work Flow Pattern

The "Conditional Work Flow Pattern" allows to run two or more different external applications according to the value of a mathematical expression.

In this test case a set of Input Files (A.dat and B.dat) is created by the application ApplicationAB. These Input Files are then transferred to two different applications (ApplicationA and ApplicationB) depending on the value of the conditional node Switch .

Both applications must write an Output File named out.dat which must be passed to another application, that do not do anything but collect the file out.dat coming from either ApplicationA or ApplicationB, because an Output File can be linked to only one application.

Note:

the format of this Output File MUST be identical for both application (or similar if we are going to extract the ouput variable using a relative position mining rule) because the Output Variables will be extracted using a unique template Output File

The Work Flow (Figure 5.49, "the Process Flow window") shows the Event Sequence and the Data Flow for this project as well as the files transferred between the applications.

Figure 5.49. the Process Flow window

The project for this Work Flow can be found in:

.../modeFRONTIER30x/projects/testcase/switch/testSwitch.prj

or, if we prefer, we can rebuild it following the following steps.

Building the Event Sequence

Since we want to choose ApplicationA or ApplicationB accordingly to the value of the Input Variable x the first thing to do is to define two Input Variables, so put two Input Variables icons in the Work Flow canvas and define them like in Figure 5.50, "The Input Variables definition".

Figure 5.50. The Input Variables definition

Now we start creating the Logic Flow which define the application sequence that evaluate each design.

Select from the tool bar four External Script objects and one Switch Node object and place them on the Work Flow desktop.

To complete the logic Flow for this example, we need to set a starting point and, at least, one ending point. So we need to select from the tool bar a Scheduler object and two Logic End object .

Give each logic nodes a meaningful name renaming them as ApplicationAB, ApplicationA, ApplicationB and Collector.

Double LMB click on one of the Logic End and change the End Status in Failed and click the Ok button to accept the change.

At this point Work Flow will be like in Figure 5.51, "the Logic Flow components".

Figure 5.51. the Logic Flow components

As we can see in the Logic Log panel there a lot of errors that will disappear while the project creation goes on.

Double LMB click on a ApplicationAB icon to bring up the properties editor and do the following:

Click on Edit Script and the External Script Editor window will appear and we write a simple batch of commands as in Figure 5.52, "the ApplicationAB node".
Note:
we can load the script from:
.../modeFRONTIER30x/projects/testcase/switch/ApplicationAB.shj
Check the Scheduler box to link the ApplicationAB to the Scheduler icon so that the ApplicationAB is going to be the first external application to start.
Check the Switch Node box to link the Switch icon as a Possible output nodes and specify the application's Exit Condition =0.
Click the Ok button to accept all changes (Figure 5.52, "the ApplicationAB node").

Figure 5.52. the ApplicationAB node

Double LMB click on a Switch icon to bring up the properties editor and do the following:

Write x as Switch Expression (it means that the condition will be evaluated using the x input variable as reference).
The Possible input node field is already defined with the ApplicationAB.
Choose ApplicationA, ApplicationB and End Logic Failed as Possible output node and define the condition for each one.
We want that the next appication will be ApplicationA if (x <= -1), will be ApplicationB if (-1 <= x >= +1) and there will not be any analysis if (x >= +1).
Click the Ok button to accept all changes, (Figure 5.53, "the Switch node properties").

Figure 5.53. the Switch node properties

Double LMB click on a ApplicationA icon to bring up the properties editor and do the following:

Click on Edit Script and the External Script Editor window will appear and the script used is as in Figure 5.54, "the applicationA node".
Note:
we can load the script from:
.../modeFRONTIER30x/projects/testcase/switch/ApplicationA.sh
The Possible input nodes field is already defined because it is related to the definition of the Switch node.
Select the Collector as a Possible output nodes, specify the application's Exit Condition =0.
Click the Ok button to accept all changes (Figure 5.54, "the applicationA node").

Figure 5.54. the applicationA node

Double LMB click on a ApplicationB icon to bring up the properties editor and do the following (more or less the same operation we did for ApplicationA):

Click on Edit Script and the External Script Editor window will appear and the script used is as in Figure 5.55, "the applicationB node".
Note:
we can load the script from:
.../modeFRONTIER30x/projects/testcase/switch/ApplicationB.sh
The Possible input nodes field is already defined because it is related to the definition of the Switch node.
Select the Collector as a Possible output nodes, specify the application's Exit Condition =0.
Click the Ok button to accept all changes (Figure 5.55, "the applicationB node").

Figure 5.55. the applicationB node

Since an Output File can be linked to only one External Script node we need to define a further External Script node named Collector which is used for receiving the Output File out.dat created by either ApplicationA or ApplicationB.

Double LMB click on the Collector icon to bring up the properties editor and do the following:

Click on Edit Script and the External Script Editor window will appear and the script used is as in Figure 5.56, "the Collector node".
Note:
we can load the script from:
.../modeFRONTIER30x/projects/testcase/switch/Collector.sh
Note:
This node node do not do anything but it will store the Output File out.dat created by either ApplicationA or ApplicationB in order to have only one External Script node from where to extract the Output File out.dat.
The Possible input nodes field is already defined because it has been already defined during the definition of the node ApplicationA and ApplicationB.
Select the End Ok as a Possible output nodes, specify the application's Exit Condition =0.
Click the Ok button to accept all changes (Figure 5.56, "the Collector node").

Figure 5.56. the Collector node

Now define the DOE and Scheduler nodes as we did in the Simple Process Flow Pattern, see Figure 5.57, "the DOE settings" and Figure 5.58, "the Scheduler settings".

Figure 5.57. the DOE settings

Figure 5.58. the Scheduler settings

Building the Data Flow

Now we have to build the Data Flow from the definition of the model, inserting the Input Variables into the Input Files to the extraction of the Output Variables from Output Files.

The Input Variables have been already defined because one of them was necessary for the Switch node definition.

Create the Input File selecting the relative object from the palette on the left and place them on the Work Flow desktop.

The Input File object must then be configured.

Double LMB click on the Input File icon to bring up the properties editor (Figure 5.59, "the Input File loading") and do the following:

Change the Name into inAB.dat.
Check the two Possible input nodes boxes to link the Input File with the Input Variables (x and y).
Check the Possible output nodes box to link the Input File with ApplicationAB.
Click the Prewiew button to see the Work Flow updated.
Click on Open and browse into our file system to select the template input file, (Figure 5.60, "The Input File node").
Note:
we can load the input file from:
.../modeFRONTIER30x/projects/testcase/switch/inAB.dat
When the suitable file is located on the file system click on the Open button to load it inside the Template Input Editor.
Click the Ok button to accept all changes (Figure 5.59, "the Input File loading").

Figure 5.59. the Input File loading

Figure 5.60. The Input File node

In the lower part of the Template Input Editor a list of all the linked Input Variables is shown.

To define how an Input Variable is going to be inserted into the template file during the optimisation loop do the follow:

Select the Input Variable to be included in the list.
Highlight with the mouse pointer the corresponding value on the file editor.
Click with the RMB to bring up a pop-up menu and select Insert Variable.
Specify the correct format ("0.000000") the variable will use when written into the file.

Repeat until all Input Variables are properly linked to the Input File, the result of those actions are a set of new tags inserted in the original inAB.dat file (Figure 5.61, "the Input Variables inserted"): Check out the format to make sure number format is like the following:

  <VAR name="x" format="0.000000" />
  <VAR name="y" format="0.000000" />

During the optimisation loop the tags will be substituted with the Input Variables numerical values using the specified format.

Figure 5.61. the Input Variables inserted

Two more Input Files (A.dat and B.dat) has to be defined because they are necessary to the ApplicationAB.

Create two more Input File selecting the relative object from the palette on the left and place them on the Work Flow desktop.

Configure them as in (Figure 5.62, "two more files needed by the ApplicationAB") and load the files A.dat and B.dat which we can find in:

.../modeFRONTIER30x/projects/testcase/switch/B.dat

.../modeFRONTIER30x/projects/testcase/switch/A.dat

see Figure 5.63, "the Input Variables inserted".

Figure 5.62. two more files needed by the ApplicationAB

Figure 5.63. the Input Variables inserted

Now the ApplicationAB has all files necessary to run. The ApplicationAB creates two input files (inA.dat and inB.dat) for the following applications (ApplicationA and ApplicationB) so we have to pass the files to the respective application (inA.dat to ApplicationA and inB.dat to ApplicationB). Furthermore, both ApplicationA and ApplicationB write the results into a file named out.dat that must be passed to the Collector application for the Output Variables extraction. The simplest way to copy files from an application to another one is to insert a Transfer File(s) between the two application .

Put four nodes into the Work Flow desktop. Define the Transfer Files from ApplicationAB to ApplicationA and ApplicationB as in Figure 5.64, "The File Transfer from ApplicationAB to ApplicationA and ApplicationB". Define the Transfer Files from ApplicationA and ApplicationB to Collector as in Figure 5.65, "The File Transfer from ApplicationA and ApplicationB to Collector".

Figure 5.64. The File Transfer from ApplicationAB to ApplicationA and ApplicationB

Figure 5.65. The File Transfer from ApplicationA and ApplicationB to Collector

The last thing to do is to define the extration of the Output Variables from the Output File. As we said before, the Output File is passed to the application Collector so we have to define an Output File named out.dat and link it to the Collector application. After that we store results in two Output Variables named o1 and o2.

Create two Output Variables selecting the objects from the palette on the left and place them on the Work Flow desktop and define them as in Figure 5.66, "the Output Variables".

Figure 5.66. the Output Variables

Create now an Output File selecting the relative object from the palette on the left and place them on the Work Flow desktop.

The Output File object must then be configured.

Double LMB click on the Output File icon to bring up the properties editor (Figure 5.67, "the Output File Properties") and do the following:

Change the Name into out.dat.
Check the Possible input nodes box to link the Output File with the Collector objects.
Specify the Collector Exit Condition =0. The Output File is going to be processed or not depending on the Collector Exit Condition.
Check the two Possible output node boxes to link the Output File with the two Output Variables (o1 , o2).
Click the Open button and browse into the file system looking for an Output File to use as template output file, see Figure 5.67, "the Output File Properties".
Note:
we can load the output file from:
.../modeFRONTIER30x/projects/testcase/switch/out.dat
When we have find the proper file click on Open to select it.
Select the Output Variable whose value has to be extracted from the file.
Click with the RMB to show up a pop-up menu and select the Absolute Position item.
Repeat until all Output Variables are properly associated with a Mining Rule. The result of this operation is a list of rules (Figure 5.68, "the Mining Rule definition") that will be used by modeFRONTIER^TM to extract data from the Output Files during the simulation loop.
In particular the following rules:
```
                     
  NAME=o1,TYPE=ABSOLUTE,ROW=1,COL=1 for the o1
  NAME=o2,TYPE=ABSOLUTE,ROW=2,COL=1 for the o2
  
```
Shows that the value of the variable o1 is extracted from the "first row and first column" of the Output File out.dat, the o2's value is extracted from the "second row and first column" of the Output File out.dat.
Click the Ok button to accept all changes.

Figure 5.67. the Output File Properties

Figure 5.68. the Mining Rule definition

Defining the Goals

The user has to define a set of goals to be achieved during the optimisation loop.

In our example some Objectives are defined for this problem:

maximize o1.
maximize o2.

To implement these "Goals" in the Work Flow, we link two Objectives objects to our Output Variables:

The obj1 to be maximized.
The obj2 to be maximized.

Every Objective can be edited, as we have done for the other components using its Properties Dialog. Double LMB click on a Objective icon to bring up the properties editor (Figure 5.69, "Objective Properties window") and do the following:

Change the objective Name in obj1.
Set Type to Maximize.
Select User Expression and write the expression o1.
Click the Ok button to accept all changes.

Then double LMB click on the other Objective icon to bring up the properties editor (Figure 5.69, "Objective Properties window") and do the following:

Change the objective Name in obj2.
Set Type to Maximize.
Select User Expression and write the expression o2.
Click the Ok button to accept all changes.

Figure 5.69. Objective Properties window

The completed logic flow looks like in Figure 5.49, "the Process Flow window". No error or warning messages appears in the Logic Log panel, and no objects on the Work Flow desktop have a yellow border.

Before exiting modeFRONTIER^TM we can save the project as testSwitch.prj.

If we are not sure to have correctly built this project a tested copy is already available in:

.../modeFRONTIER30x/projects/testcase/switch/testSwitch.prj