This is part 3 of 3 in the series on updating SMTK projects for multiple simulation sequences. Part 1 discussed UI updates to be implemented in the project plugin module. Part 2 described proposed changes to SMTK core for supporting the multiple-simulation use case, primarily via the addition of an smtk::project::Job class. Part 3 now discusses how the project and simulation plugins should be updated to support the underlying goal of carrying out loosely-coupled simulation sequences.
The main requirements are:
-
Provide a UI for users to select which simulation(s) to run.
-
Generate the simulation inputs. (Perhaps a minor point, but verify that all inputs can be generated before submitting the any jobs, so that local errors are detected before starting computations.)
-
Submit the jobs to the target computing resource, with each simulation run as a separate job.
For now, the strawman design presumes the same target machine for all jobs.
Export User Interface
In terms of what the UI should look like, I think the export dialog for projects should include an AnalysisView for the user to select which simulations to run. This screen shot is a preliminary mockup example for ACE3P projects.
-
The top level view is a GroupView, with an “Analyses” tab plus a separate tab for each simulation/job.
-
In the “Analysis” tab is an InstancedView (labeled “Select”) where the user can select which simulations to export and optionally submit.
-
Some internal logic is needed to address dependencies among the analyses, but I won’t go into those details here.
-
If the option to submit the analyses is enabled (“Submit job to NERSC”), then additional items are displayed to set options that are common across all of the simulation jobs (the “NERSC” GroupItem in this example).
The other tabs are used to specify options for the individual simulations. The next screenshot is a strawman for one ACE3P simulation.
-
In practice, the “Model”, “Attributes”, and “Filename prefix” items should be set by the project based on its configuration, and should be read-only to the user.
-
The rest of the options configure the computing resources.
Not shown in either screenshot are “Submit” and “Cancel” buttons.
Implementation Considerations
In terms of how to implement this UI and functionality:
-
The UI will need to be created dynamically, based on the number of simulations that have been configured by the user.
-
My current thinking is that the simulation plugin would register itself with the project plugin, and when the project export action is invoked, the project plugin would call a method on the simulation plugin to build and execute the UI. As the simulation plugin carries out the export and job-submit logic, the simulation plugin would make calls to create/add job instances to the SMTK project.
When you add in the girder/cumulus server and NERSC/NEWT interactions, there are alot of moving parts where things can go wrong. Perhaps the first step in developing this is to come up with a detailed logging capability and/or other visibility and test features. It is also important the we come up with an intuitive file organization for projects, for forensic reasons if nothing else.