... | ... | @@ -133,10 +133,13 @@ The above discussion assumes that the entire workflow of the user is being manag |
|
|
This is a good enumeration of CMB modules for performing workflows. And the extension to external workflow execution is great.
|
|
|
|
|
|
* Is the thinking that each "single task" is specified with declarative syntax? That would still be my recommendation -- using the same general approach as provisioning systems like Ansible.
|
|
|
* @bob.obara : I was thinking we would start with a declarative syntax but maybe also allow a simple task to be a Python Script as well.
|
|
|
* The choice of a single flow sequence (with hierarchy) versus a directed graph -- was that a keep-it-simple decision? It will limit the granularity at which workflows can be specified (which might be a good thing). In the AdH simulation, for example, I would typically consider the meshing and simulation-attribute tasks to be independent and not done serially.
|
|
|
* @bob.obara : I did want to keep the design initially simple (though expanding from a tree to a DAG would be doable). In terms of doing meshing and simulation-attribute specification in either order. You could group them in a Parallel Task Group which would result in the workflow you described.
|
|
|
* I like the ideal of task hierarchy, however, encapsulation could quickly break down for things like "selector" and "parallel" tasks, when the input requirements are different among the various sub-tasks. So there will be situations were some parts of a selector or parallel task can be performed but not others, so the readiness of the parent task is not a binary yes or no.
|
|
|
* You don't mention whether feedback is supported or not, but I am presuming that a workflow can be started/restarted at any point in the sequence.
|
|
|
* @bob.obara : Yes - you should be able to save the state of a partially saved workflow and reload it in.
|
|
|
* I'll add my usual comment that we should support workflow tasks that are executed by "external" processing, that is, scripts or other non-CMB executables.
|
|
|
* @bob.obara : absolutely
|
|
|
* I suspect it will be hard to avoid duplication of workflow specifications from different projects, but that is something we should try to minimize.
|
|
|
|
|
|
|
|
|
* @bob.obara : I would hope that we could resume tasks so maybe we would have a task library for specific domains. |
|
|
\ No newline at end of file |