GROMACS

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_md, do_rerun, do_steep, do_cg, do_lbfgs, do_nm, do_tpi, and do_mimic. It is named after the mdp-option integrator. There are two problems with this naming:

1. 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.
2. 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!