In the current code, the name Integrator is used for the class of the object owning the family of functions running some type of simulations, i.e.
do_mimic. It is named after the mdp-option
integrator. There are two problems with this naming:
- Most of these functions don't actually do any integration, and as new methods are implemented (e.g. Monte Carlo or MC/MD-hybrid methods), this is not improving.
- There is potential for confusion between the current concept of Integrator as the complete description of a simulation run and the actual propagation of the micro-state (e.g. leap-frog integrator, velocity-verlet integrator, ...)
Based on discussions with several developers, I would therefore suggest to rename the current
Integrator class and the corresponding mdp-option, as well as to stop using integrator for any current or future implementations of the micro-state propagator.
For the propagation of the micro-state, the term propagator seems appropriate, and allows to also accommodate non-dynamical ways of propagating the system (e.g. minimization, MC steps, ...). Besides the propagation of positions and velocities (including constraining), this should probably also include functions to calculate forces, energies, virial, as their placement in the instruction flow is dependent on the propagation method chosen.The prescription of the simulation (formerly known as
Integrator) is a bit harder to rename. It contains the components of the propagator, but also plenty of plumbing for propagator stages, parallelization, I/O, ... Candidates include Simulation (as any run of GROMACS can probably be classified as (molecular) simulation), Program, Prescription, Driver, or a combination of these (e.g. SimulationPrescription).
Some thoughts on this (credit to Mark for this):
- Schedule is currently being used for the set of work within the force calculation plus its reduction, but Prashanth (or Mark?) also suggested recipe - something about schedule was not good, probably on gerrit somewhere
- Module is already used for MDModule like ElectricField, gmx command-line module like gmx grompp, and source-code unit like src/gromacs/swap, so avoid that
- The task graph that implements the do_md level thing has the components of the Propagator as part of it, but also plenty of plumbing for propagator stages and I/O
- Runner is currently used for the thing that coordinates setting up for and dispatching the do_md level thing, probably best to leave that alone
- Context, Session, Workflow are all used by gmxapi, probably best avoided
- Context, program, driver, and command also have a GPU-related meaning, probably best avoided
- Pipeline is too linear
This leaves something like Simulation, Simulator, SimulationPrescription as most likely candidates. I'd be happy to hear other suggestions and opinions!
#3 Updated by Eric Irrgang 13 days ago
gmxapi use of the term "Session" is more consistent with the role of MdRunner. MMPropagator or MicrostatePropagator seem plausible, but perhaps too limited. Is there anything wrong with just "Propagator?" Examined another way, what is the data that is owned by objects of this type? And what is the fundamental change in program state before and after these objects have acted? I think it is pretty broad, and "gmx::Updater" does not seem inappropriate as a base class name.
#5 Updated by Mark Abraham 13 days ago
The brains trust met in the dev telco today. The high level thing we will call Simulator, the microstate level thing we will call Integrator.
We need to change the .mdp option called integrator, but that's a trickier question. Someone needs to have a concrete proposal or two to debate.