Project

General

Profile

Feature #3285

Feature #3283: Support for the string method with swarms of trajectories in GROMACS

Run simulations from the same tpr file with different random seeds

Added by Oliver Fleetwood 9 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
mdrun
Target version:
Difficulty:
hard
Close

Description

In e.g. the swarms of trajectories methods (see https://redmine.gromacs.org/issues/3283) one wants to start many short simulations from the same initial tpr file. Unless you use mdrun with the '-multi' option this is not possible and you need to create one tpr file per short trajectory, which is unnecessary.
A nice solution would be to reseed via a flag to mdrun.


Subtasks

Task #3356: Expose setting of random seed to APINew

Related issues

Related to GROMACS - Feature #3295: Expand gmxapi.modify_input use cases.New
Related to GROMACS - Feature #3379: C++ API for simulation input and outputNew

History

#1 Updated by Mark Abraham 9 months ago

  • Parent task set to #3283

#2 Updated by Eric Irrgang 9 months ago

It is increasingly beyond the scope of mdrun functionality to alter simulation inputs in the same command. It would seem reasonable to expand convert-tpr to edit additional trivial properties, like random number seeds. This is also the purpose of the gmxapi.modify_input operation. However, neither of these options currently avoids the need to write a new TPR file. I think that an API abstraction for the simulation input will be a high priority for near term development.

#3 Updated by Eric Irrgang 9 months ago

Oliver Fleetwood wrote:

A nice solution would be to reseed via a flag to mdrun.

There are several places where random number seeds can appear in a GROMACS simulation work flow, and the (re)use of explicit or automatically generated seeds can drift over time...

Can you please clarify which random process(es) you would like to reseed?

#4 Updated by Eric Irrgang 9 months ago

  • Related to Feature #3295: Expand gmxapi.modify_input use cases. added

#5 Updated by Paul Bauer 8 months ago

The new feature here would likely be mostly useful for re-seeding the velocity generation to be able to generate the trajectory swarms with different initial conditions.

I think this would be a prime example of using the API to create input diversity without having to generate different input files, or having to use an unrelated feature (multisim) to get the same result.

#6 Updated by Eric Irrgang 8 months ago

Paul Bauer wrote:

The new feature here would likely be mostly useful for re-seeding the velocity generation to be able to generate the trajectory swarms with different initial conditions.

If this is correct, then I suggest updating the issue title to be more explicit. E.g. "with differently seeded random initial velocities"

#7 Updated by Erik Lindahl 7 months ago

  • Status changed from New to Resolved
  • Target version changed from 2021 to future
  • Difficulty hard added
  • Difficulty deleted (simple)

I will resolve this with a "WONTFIX" for now.

While it might seem simple and straightforward to just add another command line option, there is a VERY clear track record of those extra options consistently requiring a number of extra checks that both make the code unreadable and lead to bugs later.

Just as the number of simulation steps, this is a property that was already specified by the user. In fact, the random seeds is even more complex since the velocity generation has already happened at grompp time, so this would then require an optional complete regeneration of velocities in mdrun. Then we also need to consider whether we should regenerate velocities if that option is present, even if the user originally did not ask to generate velocities.

Hopefully you all see the complications :-)

The solution to this is to make the general input more flexible, and in particular make it possible to (1) start simulations directly from input without always writing a TPR file, and (2) make sure that processing finishes in 0.1s, not 10-20s.

#8 Updated by Eric Irrgang 7 months ago

  • Related to Feature #3379: C++ API for simulation input and output added

Also available in: Atom PDF