 |
|
The Work Flow window is used to define the Logic and Data flow for each design evaluation. During the optimisation loop this Logic will be run every time a design evaluation is needed. Before starting with the Work Flow for this simple pattern let's have a look to the canvas where the Logic and Data Flow can be laid out (see Figure 5.1, "The Work Flow window").
The window is divided into three parts:
the top part (the proper Work Flow graphical panel, marked
in a cyan 
box):
it is the desktop where the logic is created.
the bottom part (Logic Log/Summary, marked in a yellow
box):
click on one of the tabs to toggle between their respective panels..
The Logic Log panel shows a list of warning/error messages detected by the just-in-time logic compiler. Only if there are no errors a project is ready to be run.
The Summary panel shows a brief summary of the project, about its components and their relevant properties; thus it's possible to keep the entire process logic under control with just a glance. Some tables are editable for quick modification.
The left part (a Tool Bar marked in a magenta
box):
it includes all the components needed to create data & Logic Flow.
Note:
above the Work Flow there is another tool bar, here not marked, which use is more specific and is not handled in this tutorial.
When we start a new project, the Logic Log shows an error message (as we can see in Figure 5.1, "The Work Flow window"):
Error 150 MISSING SCHEDULER NODE
This is perfectly normal, since the project is empty: we miss not only the scheduler node, but also all the other necessary nodes that have to be implemented in a correct project definition.
Proceeding in the construction of the project, other errors will appear, marking the various phases of our work in progress.
Many components are needed in order to construct properly a project: but the order in which these components are defined is more a question of user's style or logic.
Two main flows can be found in any project: a Data Flow that is the line going from "input data" to "output data" and a Logic Flow that is the line going from the "start" to the "end" of the execution process. As we will see, these two flows intersect in the External Script node.
In this tutorial we will define first the Data Flow, since it is simpler for a new user to follow the path going from Input Variables toOutput Variables.
These Input/Output Variables can however be completed, modified, created or removed at any time during the logic creation process, as can be done with every other component.
Note:
from now on, an "RMB click" will indicate a click with the right mouse button, while an "LMB click" or simply "click" will indicate a click with the left mouse button
To place a component on the Work Flow desktop, select it by clicking on the left Tool Bar, then click on the desktop; to place many copies of the same selected component, click on the desktop as many times as the number of objects needed, while pressing the <CTRL> key.
Once a component is created, we can select it with a click, access its properties by a double click. With a RMB click a menu will pop-up menu, where we can select some actions to perform on the component:
Remove Node to remove the selected object from the Logic Flow.
Remove Links to remove all links from the selected object to any other node previously linked to.
Edit Graphic Properties to edit the object graphic properties.
Edit Node Properties to access the object properties (equivalent to a double click).
If a component is selected and we want to leave the "component
insertion mode", click on the "neutral icon"
on top of the Work Flow Tool Bar.
Although the Work Flow shown in Figure 5.2, "Simplest Process Flow" is one of the simplest possible, the majority of the real word problems can be solved using this approach.
This represents the simplest way to access an external application, using an Input File for the configuration and producing an Output File containing the results.
The Work Flow is composed of two main streams:
The Event Sequence (white arrows) defines the chronological sequence of the applications used for the design evaluation. Every application is fed by one or more Input File and generates one or more Output File.
The Data Flow (blue arrows) defines all the actions necessary for merging the Input Variables into the template files and the mining operations to extract the Output Variables from the Output Files.
The project for this Work Flow can be found in: .../modeFRONTIER30x/projects/testcase/simple/testSimple.prj or, if we prefer, we can rebuild it by following this short tutorial.
The Event Sequence (Figure 5.3, "Simplest Event Sequence") is as simple as they get.
Select from the tool bar a External Script object
and place it on the Work Flow canvas.
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 a Logic End object
.
The new External Script object must then be configured. Double LMB click on its icon to bring up the properties editor (Figure 5.3, "Simplest Event Sequence") and do the following:
Change the application name in ApplicationA
Note:
if you are going to run an application on WindowsTM, without using the cygwinTM environment, it is mondatory that the application name has got the extension .bat (e.g. : ApplicationA.bat).
Check the Scheduler box to link the ApplicationA to the Scheduler icon which defines the Logic Start. The ApplicationA is going to be the first External Script to be executed.
Check the EndOK1 box to link Logic End icon and specify the application exit condition =0 (it means that the current Design will be considered successfully evaluated only if the exit condition of this External Script is 0).
Click the button to accept all changes.
Note:
Even if not explicitly shown, all the other possible exit conditions (<>0) generate Logic Failed event.
All the error or warning messages are displayed in the Logic Log panel. These messages help the user to understand what is going on during the Work Flow building.
In this case the messages:
Error 151 SCHEDULER NOT DEFINED Scheduler
Error 155 INPUT VARIABLES ARE NOT DEFINED FOR THE SELECTED SCHEDULER Scheduler
Error 160 NO DOE DESIGN AVAILABLE DOE
Error 103 MISSING SCRIPT FILE ApplicationA
The first three errors will be fixed when we define the Scheduler and DOE properties. The fourth prompt us that there is not yet any script defined in the External Script ApplicationA.
Now we have to create the script that will perform the external tasks. The script can be very simple or more sophisticated according to the user's needs: in this case we create one simple script executing the bc (an interactive processor for a language that resembles C but provides unlimited-precision arithmetic, it takes input from any files given).
Double LMB click on the ApplicationA icon to bring up the properties editor (Figure 5.3, "Simplest Event Sequence") and do the following:
Click on the button and a simple text editor will show up.
Write a simple batch of commands, where the key one is the bc program, see Figure 5.4, "Application Script Editor"
Click on the button to confirm all changes.
Note:
It is always recommended to test the script in our normal shell environment, if its performances are as we expected it will do the same inside modeFRONTIERTM
The Application Script Editor (Figure 5.5, "Searching the script"), as in the most used text editors, has a set of simple actions that will let us load, save, and edit our external scripts or batch files. However when we press the button the loaded script will be stored inside the project.
If we have already prepared and tested the script and we want to load it into modeFRONTIERTM do the following:
click on the open icon 
.
browse into the file system looking for the proper file.
select the file we want to open and click on the button to load it into the External Script Editor.
Click on the button to confirm our choice.
For this tutorial an example of script can be found in: .../modeFRONTIER30x/projects/testcase/simple/ApplicationA.sh
At this point the Logic Log display only error messages relative to DOE and Scheduler. However we have completed only the Event Sequence part of the Work Flow. The Data Flow part, will describe in the following paragraphs, how the input data are handled and transformed for the correct use by the external application. As well as how the application's output data are extracted and used by modeFRONTIERTM in the optimisation loop.
Create two Input Variables
selecting the objects from the palette on the left and place them on the Work Flow desktop.
The Input Variables objects must then be configured.
Double LMB click on the Input Variable icon to bring up the properties editor (Figure 5.6, "the Process Flow desktop with input variables placed") and do the following:
Change the Name into x
Set Lower/Upper Bound to [-5.0 , 5.0].
Set the Base to 100001.
Click the button to accept all changes.
Repeat the previous actions for the other Input Variables to complete the input variables set up.
All the properties can be viewed or edited using the panel as well (Figure 5.6, "the Process Flow desktop with input variables placed").
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.7, "the Process Flow desktop with input variables and input file placed") and do the following:
Change the Name into inA.dat.
Check the two Possible input nodes boxes to link the Input File with the Input Variables objects.
Check the Possible output node box to link the Input File with ApplicationA
Click the button to accept all changes.
The Logic Log panel is now showing a new error:
Error 104 MISSING TEMPLATE FILE inA.dat
Error 105 MISMATCH BETWEEN TEMPLATE FILE AND INPUT inA.dat
The next step is to create the template file for the Input File inA.dat. The operation can be carried out loading an existing inA.dat file using the button in the Input File properties. The action will bring up a File Chooser Dialog (Figure 5.8, "Selecting template input file") and an example of inA.dat template file for this tutorial can be found in:
.../modeFRONTIER30x/projects/testcase/simple/inA.dat
When the suitable file is located on the file system click on the button to load it inside the Template Input Editor (Figure 5.9, "Insert an Input Variable in the input file"). 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 (Figure 5.9, "Insert an Input Variable in the input file").
Specify the correct format the variable will use when written into the file (Figure 5.10, "Selecting a number format").
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 inA.dat file (Figure 5.11, "All Input Variables are 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.
Note:
pay attention to the check boxes close to the variable names. As the input variable insertion process progresses, the system marks checked every variable correctly inserted
Note:
the system will not allow the insertion of variables if special characters are included into the selected string. The end-of-line is also a special character, the number must be precisely selected!
When everything seems correctly configured click on the button to accept all changes.
This section describes how to extract the Output Variables from the Output Files generated by the ApplicationA.
Create two Output Variables 
selecting the objects from the palette on the left and place them on the Work Flow desktop.
The first Output Variable objects must then be configured. Double LMB click on the Output Variable icon to bring up the properties editor and change its name in o1.
Press button when finished. Repeat the actions for the second Output Variable calling it o2.
All the properties can be viewed or edited using the panel as well.
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.12, "Linking output file to the application and to output variables") and do the following:
Change the Name into outA.dat.
Check the Possible input nodes box to link the Output File with the ApplicationA object.
Specify the ApplicationA exit Condition =0. The Output File is going to be processed or not depending on the ApplicationA exit condition.
Check the two Possible output node boxes to link the Output File with the two Output Variables ( o1 , o2 ).
Click the button to accept all changes.
After the variables are connected the modeFRONTIERTM Work Flow should look like the following figure (Figure 5.12, "Linking output file to the application and to output variables"):
A new error message in the Logic Log window show that we have not define any Mining Rules for the Output Variables o1 and o2.
Error 108 MISSING MINING RULE(S) IN OUTPUT FILE outA.dat
The Mining Rule is a rule which defines the way the Output Variable is extracted from the Output File. To apply a Mining Rule to an Output Variable inside the modeFRONTIERTM Work Flow do the follow (Figure 5.13, "Open File dialog"):
Press the button in the Output File properties window to show up file chooser dialog.
Select a suitable file, a sample output file outA.dat produced by our External Script ApplicationA, and click on the button. For this tutorial an example of outA.dat can be found in: .../modeFRONTIER30x/projects/testcase/simple/outA.dat
The loaded file outA.dat is displayed by the Template Output Editor window as well as all Output Variables previously defined are shown in the grid below the text (Figure 5.14, "Setting Absolute position").
To define the Mining Rule associated to an Output variable do the follow:
Select the Output Variable whose value has to be extracted from the file.
RMB click to show up a pop-up menu and select the Absolute Position item. (Figure 5.14, "Setting Absolute position")
Repeat until all Output Variables are properly associated with a Mining Rule, the result of those operations is a list of rules (Figure 5.15, "All Output Variables are extracted") that will be used by modeFRONTIERTM 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 o2
NAME=o2,TYPE=ABSOLUTE,ROW=2,COL=1 for the o1
Shows that the value of the variable o1 is extracted from the "first row and first column" of the Output File outA.dat, the out2's value is extracted from the "second row and first column" of the Output File outA.dat.
Note:
As the Output Variable mining process progresses, the system marks checked every variable correctly mined, until all are done
Now we can click on the button to accept all changes, the Work Flow desktop should look like in Figure 5.16, "The Process Flow after the output variable mining process".
The Work Flow logic is now completed, and a DOE based exploration of the design space can be performed. However an optimisation loop requires the definition of the set of "Goals" as well as the DOE and Scheduler set-up to be complete.
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 our Output Variables:
The obj1 to be maximized.
The obj2 to be maximized.
Change the objective name in obj1.
Set Type to Maximize.
Select User Expression and write the expression o1.
Click the button to accept all changes.
Repeat the operations with other Objective object, see Figure 5.18, "Objective Properties window".
Finally the Logic is completed and the Work Flow desktop should look like in Figure 5.2, "Simplest Process Flow". Now the logic is laid down correctly and can be used in a complete optimisation loop.
Now we have to define DOE and Scheduler properties.
Double LMB click on the 
icon to bring up the DOE properties editor and do the following:
Select the Random Sequence Algorithm from the DOE Algorithm tree.
Set Number of Random Designs to "10".
Set Seed to "1".
Click on , now the DOE properties window look like in Figure 5.19, "DOE Properties window".
Click on the button the DOE will be stored inside the project.
Double LMB click on the 
icon to bring up the Scheduler properties editor and do the following:
Select MOGA Algorithm from the Scheduler Algorithm tree.
Set Number of Generation to "40".
Click on , now the Scheduler properties window look like in Figure 5.20, "DOE Properties window".
Click on the button the Scheduler properties will be stored inside the project.
Now the project is ready to run.
Note:
No error or warning messages should appear in the logic log, no objects should have a yellow border!
If we are not sure to have correctly built this project a tested copy is already available in .../modeFRONTIER30x/projects/testcase/simple/testSimple.prj
