The ability of explicitly setting the initial conditions of a simulation can help users to create diversity for running large swarms of simulations.
Currently, most of the diversity can be achieved by changing the initial velocities, which is controlled by the input random seed.
The value for this is decided at TPR creation, but modified e.g. when running a multi-sim.
To move some of the functionality out of multi-sim for simulations that don't need to share information, it is proposed that the API can take control of the random seed setting before launching a new simulation through it.
#2 Updated by Eric Irrgang 25 days ago
I think there are multiple tasks here that are obscured by the description. As I understand it, the TPR contains the simulation input velocities, which are generated according to a random seed when running grompp (or regenerated with multisim). The API use case, then, is to allow simulation input to be prepared with a source of velocities other than the TPR file, while the user interface request is to control the source of velocities by providing a random number seed.I think that means this task should be replaced with multiple tasks to
- provide a simulation input abstraction to decouple Mdrunner initialization from read_tpx_state()
- modularize the velocity generator and connect to the simulation input abstraction (also reference #3295)
- provide a command line option to
mdrunto direct a program flow in which simulation input is composed from TPR file contents and a new call to the velocity generator
The last is a user interface question that can be debated independently of the implementation details.