...
- Is this dataset an eAirs mesh?
- Is this dataset an eAirs input file?
- Result files: coefhist.rlt, error.rlt, result.rlt, time.rlt, cp.rlt, force_com.rlt, result.vtk. We should capture enough information to know what each of these files represent as far as outputs.
Mime types of the files that are outputs from the eAIRS workflow
- .rlt
- .vtk
Workflows Bean
WorkflowBean & WorkflowStepBean
Below you will find an example of a PTPFlow workflow.xml file. This file cannot be altered since it is understood by PTPFlow and Each workflow is described in an XML file that outlines the steps in the process workflow including which resource to run on, executables that will be launched, input files to use, etc. Initially, we will simply store the workflow information in a single WorkflowStepBean that has a reference to the file containing the xml and the DatasetBeans. Ogrescript xml files can be complex, but if we can logically separate out the steps or parts into individual beans that can be used to generate the full workflow xml file required by the HPC machines, then we can include workflow steps as separate beans and provide a UI for adding steps dynamically.
This bean will wrap the workflow and all of its parts.
| Code Block | ||
|---|---|---|
| ||
private String title;
private String description;
private Date date;
private List<WorkflowStepBean> workflowSteps; // only one step initially which will be the workflow file that PTPFlow can launch right now
private PersonBean creator;
private Collection<PersonBean> contributors;
|
This bean will represent a step in the workflow.
Ideally, this file would be wrapped into the current WorkflowBean and/or WorkflowStepBean in the edu.uiuc.ncsa.cet.bean plug-in. If this is not possible, the KNSG framework will need its own workflow bean.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<workflow-builder name="eAIRS-Single" experimentId="singleCFDWorkflow" eventLevel="DEBUG">
<!-- <global-resource>grid-abe.ncsa.teragrid.org</global-resource> -->
<global-resource></global-resource>
<scheduling>
<profile name="batch">
<property name="submissionType">
<value>batch</value>
</property>
</profile>
</scheduling>
<execution>
<profile name="mesh0">
<property name="RESULT_LOC">
<value></value>
</property>
<property name="executable">
<value></value>
</property>
<property name="meshType">
<value>fakeType</value>
</property>
<property name="inputParam">
<value>fakeInput</value>
</property>
</profile>
</execution>
<graph>
<execute name="compute0">
<scheduler-constraints>batch</scheduler-constraints>
<execute-profiles>mesh0</execute-profiles>
<payload>2DComp</payload>
</execute>
</graph>
<scripts>
<payload name="2DComp" type="elf">
<elf>
<serial-scripts>
<ogrescript>
<!-- This is the old way of executing this, with the user specifying the executable
we no longer need to copy it anywhere
<copy>
<uri-pair source="file:${executable}" target="file:${runtime.dir}/2D_Comp-2.0"/>
</copy>
<chmod taskName="CHMOD_SOURCE" permissions="755" pathExpression="${runtime.dir}/2D_Comp-2.0" recursive="false"/>
-->
<echo message="Result location = file:${RESULT_LOC}/${service.job.name} result directory is file:${runtime.dir}/result, copy target is file:${RESULT_LOC}/${service.job.name}"/>
<simple-process execution-dir="${runtime.dir}" out-file="cfd.out" >
<command-line>${executable} -mesh ${meshType} -param ${inputParam}</command-line>
<!-- <command-line>${runtime.dir}/2D_Comp-2.0 -mesh ${meshType} -param ${inputParam}</command-line> -->
</simple-process>
<mkdir>
<uri>file:${RESULT_LOC}/${service.job.name}</uri>
</mkdir>
<copy sourceDir="file:${runtime.dir}/result" target="file:${RESULT_LOC}/${service.job.name}"/>
</ogrescript>
</serial-scripts>
</elf>
</payload>
</scripts>
</workflow-builder> | ||||
| Code Block | ||||
| ||||
private String title;
private PersonBean creator;
private Date date;
private List<DatasetBean> inputDatasets; // all data inputs associated with this step
private DatasetBean workflow; // initially our steps will only include a single step, the entire workflow
|
Service Manager
...
RMI Service Registry View
...