SMTK tasks and modelbuilder

Simulation Modeling Toolkit (SMTK) Design
1

With the “first-task” branch now merged into smtk, I would like to propose that the next development step be directed toward adding an initial smtk::task capability to the baseline modelbuilder application. I think we need more clarity (I certainly do) with regard to how this new feature works for end users before we can fully definitize and prioritize the software requirements from here. A candidate strawman:

  • For general reference, the current modelbuilder has a menu item to create smtk project instances, and includes a hard-coded “basic” project type for general purpose use.
  • The proposed strawman implements a new operation to add a “basic task” to a project instance. This “basic task” is for creating simulation input in a relatively generic way. (Maybe it should be called something more descriptive like “create simulation” or “do preprocessing”.)
  • The operation is associated to a project instance and has 3 main parameters corresponding to the “basic task” inputs (aka “dependencies”):
    1. A simulation template file (.sbt), from which the operation would create an attribute resource.
    2. A model from one of several possible sources: an existing model resource in the project, a graph resource in the project that represents a geometric model, or a native model file that gets imported and added to the project.
    3. An optional mesh. The mesh, which would be used by an export operator, is optional because some smtk model resources provide the discrete geometry (Genesis files).
  • The “basic task” has one output (aka “asset”): either a simulation input file, or a directory of files, generated by an export operation. In addition to requiring code to represent task assets, this also requires some coordination between the export operation and the task software. It might be sensible to defer this feature until the rest of the functionality is working.
  • I guess there should also be an operation to assign individual task dependencies, but I am inclined to defer that for now and do everything in the “basic task” operation above.
  • One thing I had not realized before now – If we create task instances via smtk operations, this suggests that the smtk::task::Task class needs to be a subclass of smtk::resource::PersistentObject, so that task instances can be referenced in the operation’s Result attribute.
  • We still need to add serial I/O for tasks, of course, and update smtk::project::Project I/O to store task files in the project directory.
  • We also should update the current “project browser” code to include a minimal display (list) of tasks in addition to the current resource list. Presumably selecting a task in the project browser will put it in the “active” state.

When done, modelbuilder users should be able to create project instances, add tasks to them with assigned inputs, and generate input files/decks for each task.

2

There is more work on the basic task class (requirements and assets) that needs to happen first.

Tasks do not need to inherit PersistentObject to be created by operations. Instead, (some) operations need to be passed the application’s smtk::common::Managers instance so the operation can acess the task manager.

3

I’ll wait to see what’s next, but I can foresee a desire to associate an operation with a task. Most notably, we currently have export operations where the operation parameter (attribute) gets associated to a project instance. I was thinking we could add an association rule to accept either tasks or project instances, but it sounds like we’ll have to do something less direct or outside of the attribute system for tasks.