Extending Projects: User Interface

Simulation Modeling Toolkit (SMTK) Design
1

I am looking at extending the SMTK Project Manager capabilities to support multiple interdependent simulations. I foresee this requiring development in three main areas:

  1. Update the project plugin to provide a user interface for configuring projects with multiple attribute resources. (The current plugin is limited to one attribute resource.)

  2. Update the SMTK core project to store and manage simulation job data.

  3. Update the plugin to extend export operators for multiple simulation jobs.

This post discusses item 1, a user interface for project configuration. Depending on the response/feedback, I hope to follow these with posts discussing the other items.

Basic Approach

The proposed revisions will implement a limited subset of the planned workflow modeling capabilities from the SMTK roadmap. The plan is to use separate attribute resources to specify multiple simulations within a project. This will be more general and flexible than modeling multiple simulations in a single attribute resource, and is expected to be easier to implement as well.

With the proposed changes, each time a simulation job is submitted, job status and other metadata are saved in the project, including the filesystem location of the results on the remote system. This will allow the project manager to combine simulations specified by their attribute resource in the project.

For the first implementation, the plan is to integrate the new functionality as an advanced feature accessed from the project menu, and leave the current project functionality as-is.

UI Requirements and Mockup

For the new project configuration view, the basic user requirement is to specify one or more analyses, each modeled by an attribute resource and one or more geometric models. For the baseline use case, analyses are carried out by long-duration computing processes typically on HPC or other remote computing systems.

A mockup of the proposed UI panel shows two parts for configuring analyses and models, respectively.

ProjectView
ProjectView704×542 39.9 KB

Analyses Table

The upper part of the view is a table for analysis specifications, with each row representing one attribute resource.

  • The “Project Id” column contains a string used to identify each attribute resource. This might be the resource name, but it will also be used as part of the folder name for storing analysis and job data on both desktop and remote systems. (We might, for example, display the resource name and internally use a slugified version.)

  • I included an “Info” column with tool button as a way for users to store some descriptive information, in a tooltip and/or popup window.

  • The “ACE3P Code” column is premature to include right now, because it would require some TBD interaction between the simulation plugin and the project plugin. It would nonetheless be handy to know what simulation code is specified by each attribute resource.

  • The “Primary Model” displays a combo box for selecting one of the model resources in the project. Minor point: the name that is displayed is the native model (not the resource name).

  • The “Secondary Model” is also a combo box. Note that no secondary model is selected in the first row of the table. Both models are optional, though you cannot assign a secondary model unless a primary model has been assigned.

  • The “Move” column has tool buttons to move rows up and down in the list. The order in the table implies the order of execution if/when multiple simulations are submitted together. This is analogous to a workflow sequential task.

  • The “Delete” column is for removing attribute resources from the project. Probably includes a confirmation dialog (“are you sure?”).

  • The “Edit” column has a toolbar to assign the attribute resource to the Attribute View tab. This is equivalent to selecting the attribute resource in the resource panel then raising the attribute editor to the front.

  • The “Status” column is still a work in progress. The baseline is to indicate the status of the current/latest simulation job; it might evolve into the more generate workflow “task state”. For jobs that are complete, an icon would/should be provided to begin visualization.

Models Table

As for the list of models, we might add a description field for some user-defined notes. Not shown in the mockup is a column for removing models from the project.

Additional Background

We have been using the project plugin at SLAC and LANL for over a year to model simulation problems computed by ACE3P and Truchas. In terms of user interface, the current plugin only presents a menu and a couple pop-up dialogs for configuring new projects and export. Each project contains a single attribute resource and up to two model resources. That is sufficient for many use cases, but at SLAC, there are a number of analyses where two simulations are loosely coupled, typically with an electromagnetic simulation supplying input data to an elastic/thermal simulation. There is an analogous use case with Truchas, which is used in conjunction with a view factor analysis code called Genre. To support these relatively simple, multiple-simulation projects, I want to begin implementing parts of the SMTK workflow modeling features that have been discussed in the past. This post begins documenting one approach toward that end.

2

@johnt I have a few suggestions for the mockup:

  • Instead of the “Move” column, just set the movement property of the QListView to allow users to reorder.
  • Instead of the “Delete” column, users should be able to select rows and hit the Delete key (or a “minus” button beneath the list view, next to the button for adding rows).
  • Change the “Add Analysis” button to a “plus” button with a tooltip describing what will be added.
  • Consider double-clicking and/or a single editor button (using the icon you already use in the Edit column) instead of the Edit column.
  • Make the status column narrow; it should only hold an icon.
  • With all the above, you should have enough space to make the “Info” column wide enough to allow in-place editing. If the info is longer than the column allows, Qt should automatically show the text as a tooltip.
  • The primary and secondary model columns seem a little odd. Shouldn’t those be marked up elsewhere in the workflow (like when they are added)? Won’t it be possible (based on attribute associations, etc) which model fulfills which role on each attribute resource?
3

I was under the impression that the design of a “primary” and “secondary” model was temporary. What is the plan for its continued support?

4

Thanks, David. My reasoning behind the icons, and visible/explicit UI features in general, is based on a feeling that ACE3P users aren’t familiar with how these tables work. I might not be giving them enough credit, so I’ll reconsider.

Regarding your last note about assigning the model columns elsewhere (“like when they are assigned”):

  • Such assignment would be part of the response when a user clicks the “Add Model” button.
  • Your comment makes me realize that the UI needs an “unlock” feature of some kind. Changing most anything in a project’s configuration can be quite impactful, and therefore should not be trivial to do. Instead, the user should be required to explicitly go into some kind of editing mode before changes are permitted.
  • So yes, the model columns should be plain text instead of combo boxes.
5

The temporary part is that the current smtk::project::Project can only be used in practice to store (i) one attribute resource, (ii) one primary model, and (iii) one secondary model.

The plan is to remove this limitation so that applications can use Project to store any number of attribute and model resources, and users can construct any number of simulation models with those resources. My current thinking is that each simulation would still comprise one attribute resource and up to 2 model resources, because I don’t have use cases that need more than that, but we can consider generalizing this to N models (in for a penny…)

6

My thinking is still evolving on how projects should organize model resources, but I certainly agree that the “primary” and “secondary” designation is too simplistic. Following are some revisions to the original strawman.

1. Each resource in a project can be assigned a label (string) to indicate its use. For example:

  • Truchas might have model resources labeled “heat transfer mesh”, “induction heating mesh”, and “fluid mesh”.
  • Hydrology simulations might have a “domain mesh” and one or more “surface mesh” model resource.
  • One ACE3P use case would have a “cavity” and “structure” model resources.

2. The resource labeling can be done through the project UI, but (I presume) would/could be implemented internally with a resource property.

3. The smtk project classes wouldn’t impose any uniqueness requirement on labels, but solver-specific code would typically do so (can only be one “heat transfer” mesh, for example).

3. In the attribute templates, we can then use this project label to constrain each reference item to one specific model(s). However,

  • Designating a property filter on reference items would essentially hard-code that attribute template to the project environment.
  • To use an attribute template outside of a project, we could need a script or something to delete all of the project-specific filters from the attribute definitions. Not very elegant, but that’s all I can think of for now.
7

Presumably this could be done with an operation outside the project UI as well. The simulation plugin could provide a list of labels and their restrictions. Then, while it might also happen in the project UI, it could occur outside of projects if needed. That would eliminate your last concern.