... | ... | @@ -61,8 +61,76 @@ Although the main workflow focus is for things CMB does, we should design the wo |
|
|
I think this question is best addressed after one or more use-cases have been examined. But to start, I would vote for an approach like Ansible, which uses a declarative specification (yml) at the top level, that can invoke programs and procedural scripts when processed by the Ansible runtime. In our case, for example, a user could "initialize" a new workflow by specifying a yml file to the workflow manager.
|
|
|
|
|
|
---
|
|
|
# comments from Yumin
|
|
|
|
|
|
### UI mockup
|
|
|
|
|
|
![Screen_Shot_2016-07-25_at_5.13.01_PM](/uploads/24f6771319bb97898dcb5a50350291a6/Screen_Shot_2016-07-25_at_5.13.01_PM.png) |
|
|
\ No newline at end of file |
|
|
# from Yumin
|
|
|
### xml
|
|
|
```xml
|
|
|
<SMTK_AttributeManager Version="1">
|
|
|
<!--********** Workflows ***********-->
|
|
|
<Workflow Title="AdHSurfaceWater">
|
|
|
<Includes>
|
|
|
<!-- Uses definitions of polygon operators -->
|
|
|
<File>smtk/bridge/polygon/operators/extractedge.sbt</File>
|
|
|
<File>smtk/bridge/polygon/operators/editedge.sbt</File>
|
|
|
<File>smtk/bridge/polygon/operators/splitedge.sbt</File>
|
|
|
</Includes>
|
|
|
|
|
|
<Tasks Session="polygon">
|
|
|
<Task Type="ModelEntityOperation" Title="Entity Operations">
|
|
|
<Type>extract edges from image</Type>
|
|
|
<Type>edit edge</Type>
|
|
|
<Type>split edge</Type>
|
|
|
</Task>
|
|
|
<Task Type="MeshingOperation" Title="Meshing Operation" />
|
|
|
<Task Type="AssignAttribute" Title="Assign Attribute" />
|
|
|
<Task Type="ExportSimulation" Title="Export Simulation" />
|
|
|
</Tasks>
|
|
|
|
|
|
</Workflow>
|
|
|
</SMTK_AttributeManager>
|
|
|
```
|
|
|
### mockup
|
|
|
|
|
|
![Screen_Shot_2016-07-25_at_1.31.47_PM](/uploads/2321a2d60ae084b3562d0f964c46eacd/Screen_Shot_2016-07-25_at_1.31.47_PM.png)
|
|
|
|
|
|
Use Cases
|
|
|
===
|
|
|
Surface Water Workflow
|
|
|
---
|
|
|
Lets assume that a user have the following set of Tasks that constitute a workflow:
|
|
|
|
|
|
1. Model 2D Domain
|
|
|
* Load in a reference image
|
|
|
* Extract coastline
|
|
|
* Define surface(s)
|
|
|
2. Model Simulation Information
|
|
|
* Create Attributes
|
|
|
* Modify coastline and water surface where needed to allow proper association of boundary conditions and materials
|
|
|
* Provide the ability to form groups to simplify attribute process
|
|
|
3. Generate Mesh(es)
|
|
|
4. Export/Submit Simulation
|
|
|
5. Visualize Results
|
|
|
|
|
|
###Couple of things to observe concerning the above workflow:
|
|
|
|
|
|
* Tasks 1must be completed before Tasks 2 and 3 can begin
|
|
|
* Tasks 2 and 3 must be completed prior to Task 4
|
|
|
* Task 4 must be completed prior to 5
|
|
|
* The bulleted sub-tasks in 1 must be done in order while the tasks in 2 can be done out of order
|
|
|
|
|
|
In terms of resources (meshes, models, and attributes systems) - the model defined in Task 1 is the same model used in tasks 2-4 while the attribute systems used in the workflow are not so straight forward:
|
|
|
|
|
|
* The attribute system in Task 1 simply holds the operator definition
|
|
|
* In Task 2 there are two attribute systems (the one from Task 1 for operators and the one the user creates for the simulation information)
|
|
|
* Task 3 has its own for the meshing information (unless like Task 2, the user is allowed to modify the model boundary which would require the need of accessing Task 1's attribute system
|
|
|
* Task 4 uses the attribute system created in Task 2
|
|
|
|
|
|
### Task Completion
|
|
|
There needs to be a mechanism to indicate that a task is completed (or at least completed enough to move to the next dependent task). So each task would have an optional completion validator. Ideally SMTK would provide some simple ones that the designer could use in their task description - for example in the above workflow the validation criteria could be the following:
|
|
|
|
|
|
* Task 1: Does model exist and does it contain at least 1 Face
|
|
|
* Task 2: Does each model face have an attribute of type material and does each outside edge have a boundary condition
|
|
|
* Task 3: Is there a mesh
|
|
|
* Task 4: Was a simulation job submitted
|
|
|
* Task 5: None
|
|
|
|
|
|
In terms of when to evaluate the completion criteria, ideally each active task could call its validation method after an operation is executed - conversely the user could be made to hit a completed button when he/she thinks the task is completed. In this approach if the task's validation checker passes, the task is marked as done and cannot be edited further and the tasks that depend on it that can be made active are activated. Note that there would be an edit button for completed tasks. When a tasks is reopened for editing, all dependent tasks are "frozen" until the task validated as completed. |
|
|
\ No newline at end of file |