A major missing piece in CMB V4 is the ability to explicitly define a task/activity. In V3 things were pretty simple - ModelBuilder could only be used to define a simulation while in V4 ModelBuilder's task of Simulation Construction is loosely modeled:
Which model(s) should be used?
The attribute system is not specifically tied to the simulation but is a "common" resource
Operations for Simulation Construction are not specified - you get everything that is available in the Sessions
In order to complete the task you need to export the simulation (but this step is not presented well)
There are a bunch of other tasks that need to be done in a CMB Workflow:
Meshing - right now its a custom panel
In the multi-scale workflow there are a bunch of model construction tasks
What is a Task?
A task is a conceptual part of a workflow. In fact a set of tasks is what defines a workflow. Here are some example tasks (and related subtasks):
Create a Domain for a Surface Water Problem
Using DEMs or
Fix up Boundaries
Specify Meshing Parameters
Define a Simulation
Assign Material Properties to parts of the domain
Assign Boundary Conditions
Specify Numerical Information for Solver
Define a Task object that represents a specific activity in a workflow
A task would have associated with it the following:
Resources (and their specific roles) related by the Task - these could be owned by the Task itself, made available to the Task, or created and returned by the Task. For example a Task could require model1 (discrete model) and model2(polygon model). In the case of attribute system, it would specify the templates that should be used.
List of Plugin to be loaded
Set of operators needed by the task (along with how to visualize them) This could include meshing, job submission, and post-processing operations.
Set of Views/Layouts
Active Condition - when can the Task be active
Completion Condition - when is the Task finished
The ability to change defaults in the attribute system owned by the Task as well as operator defualts
Tasks should have the ability to modify menu bars, tool pallets, etc...
In addition there would also be a Task Manager (or Workflow) that would be responsible to properly manager the Tasks.
For example the following is a conceptual example of a workflow containing 3 tasks:
The active task would have complete access to the components of the client interface (menubar, toolbar and the "main" widget (in this case the body of the tab widget.
Which parts of a task is declative (defined by attributes?) vs. procedural (Python?) ?
Where does REMUS, Molequeue and Cumulus fit in ?
Comments 06-Jul-2016 (john)
I presume that this is a continuation of the previous workflow discussions, but to make sure I am calibrated:
A "workflow" is analogous to a recipe for producing some desired engineering data.
A "task" is analogous to one step in a workflow.
And the "tasks" we are talking about are not automated or hands-off, but instead involve human-machine interaction, at least typically.
Use Case Analysis
I think a set of use-case descriptions would be very helpful toward understanding the software requirements. To start, I can formalize the GSSHA simulation workflow that Amanda described to Bob and me last year (although I am not sure when I will do that...).
The current description is focused on defining workflows and tasks. Looking ahead to the execution, the "workflow manager" will need some kind of repository to store/track the data involved in each individual workflow. Girder might be a good starting point for that infrastructure, but I don't want to get too far ahead of myself.
Although the main workflow focus is for things CMB does, we should design the workflow manager to support tools outside of CMB. As a simple example, I can foresee the need for a "review" task, in which one or more people "sign off" on some data/resource before it is considered ready for use in downstream tasks.
Declarative vs. Procedural
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.
<SMTK_AttributeManagerVersion="1"><!--********** Workflows ***********--><WorkflowTitle="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><TasksSession="polygon"><TaskType="ModelEntityOperation"Title="Entity Operations"><Type>extract edges from image</Type><Type>edit edge</Type><Type>split edge</Type></Task><TaskType="MeshingOperation"Title="Meshing Operation"/><TaskType="AssignAttribute"Title="Assign Attribute"/><TaskType="ExportSimulation"Title="Export Simulation"/></Tasks></Workflow></SMTK_AttributeManager>
Surface Water Workflow
Lets assume that a user have the following set of Tasks that constitute a workflow:
Model 2D Domain
Load in a reference image
Model Simulation Information
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
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
The above workflow works well when starting from scratch but lets assume someone already had created a geometric model and wants to share it - If Task 1 had an option to load in a model then the user would simply load in the geometry and select task completed. Another potential sub-use case concerns Task 2. Say that in order to start the process of defining the simulation the user needed to specify the number of parameters being solved for (the Proteus Hydro code is structured this way) - so the Task when initially opened would prompt the user for this information and then initialize the attribute system appropriately.
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.
Tasks and Task Templates
Analogous to SMTK 1.0 a Task Template is used to generate a Task while a Task is represents the state of the instantiated Task. Tasks can be saved out and loaded back in again in order to allow the user to pick up where he/she left off.