New modelbuilder plugin for projects

Computational Model Builder (CMB)
1

Now that I have started using CMB 6, I think we need to provide naive users more help with building simulation inputs. I propose to do this by adding a “project plugin” to handle most of the resource and other data management activities. A strawman/summary of the project plugin functionality follows; your feedback is welcome. I hope this effort will provide a starting point for the CMB workflow management capabilities.

When loaded, the project plugin adds a top-level “Project” menu to modelbuilder, with 5 items:

  • New Project…
  • Save Project
  • Close Project
  • Load Project…
  • Export Project…

The most interactive of these menu items is “New Project”. When selected:

1. The User is presented a UI panel to input a number of specifications:

  • Which simulation to use (ACE3P, AdH, Albany, etc.)
  • A new/empty directory on the local filesystem for storing project resources.
  • A name for the project (maybe the project directory name?)
  • The input model file. (Later versions of the project plugin should support multiple models.)

2. In response, modelbuilder loads the specified model file and simulation template, and saves both resources to the project directory. It probably also closes any other resources currently loaded, and perhaps closes all views except the attribute editor, render view, and resource panel.

For the other project menu items, the plugin should eliminate many of the manual steps that are currently needed. For example, the “Export Project” function would not require the user to locate the export script, nor assign the attribute and model items, nor create the output folder.

I am hopeful the plugin can also let us bypass the ParaView panel that asks the user to select the reader for opening model files.

When a project is loaded, it might be prudent to disable most/all of the File menu, in order to minimize user confusion.

Current thinking is that the first implementation of the plugin will support only 1 project loaded at a time, mostly to keep things simple to the user.

The first implementation will likely be tested with ACE3P and Truchas because they use mesh files (exodus) as their starting input, allowing us to defer mesh generation for now. We should also work with RGG models early, with workflow management being a big part of the NEAMS project.

2

@johnt I would like to avoid as many new menu items as possible. The “Open project…” menu item: instead just using “open” on the project file or directory (PV can now open directories as if they were files) should serve that purpose. Similarly, I hope we can use “Save all” instead of a separate “Save projects…” menu/action and a more generic “Save as…” or “Export…” rather than a project-specific export menu/action.

I like the “New project” idea, though. Plugins could register project types.

We could also have a plugin that enforces a “one simulation attribute at a time” rule by popping up a dialog to save/cancel whenever 2 attributes appear in the resource manager and the older is modified (operation attribute resources are not managed by the same resource manager as models and simulation attributes). If the user cancels, then the new resource is closed (keeping the old, modified resource). If the user clicks save, then the older attribute is saved and closed. If a project is active, we could use the same trick to force a single project at a time.