Skip to content
Snippets Groups Projects

modeling tasks discussion

Last edited by Bob Obara

Task/Activity Modeling in CMB

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?
  • Which mesh(es)?
  • 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
  • Model Construction
  • In the multi-scale workflow there are a bunch of model construction tasks
  • Post-processing

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
  • Extract boundaries
  • Using DEMs or
  • Using Imagery
  • Fix up Boundaries
  • Create domain(s)
  • Generate Mesh
  • Specify Meshing Parameters
  • Run Mesher
  • Define a Simulation
  • Assign Material Properties to parts of the domain
  • Assign Boundary Conditions
  • Specify Numerical Information for Solver
  • Run Analysis

Task Design

  • 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
  • Sub-Tasks
  • 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: New_Mockup_2

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. Questions

  1. Which parts of a task is declative (defined by attributes?) vs. procedural (Python?) ?
  2. Where does REMUS, Molequeue and Cumulus fit in ?

Comments 06-Jul-2016 (john)

Context

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...).

Workflow datastore

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.

External tasks

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.

from Yumin

workflow/task 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_5.13.01_PM 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)
  1. 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
  1. Generate Mesh(es)
  2. Export/Submit Simulation
  3. 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 Options/Initialization

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.

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.

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.

Comments

    Please register or sign in to add a comment.