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.