Multiple input trajectories for driver with multi-simulation environment

[ollyfutur]

Currently using the driver together with the --multi flag allows to emulate a multi simulation context, but a common trajectory is provided to all simulations.

However one might be tempted, for analysis or testing purposes, something like:

mpirun -n 4 plumed driver --plumed plumed.dat --mf_xtc traj0.xtc traj1.xtc traj2.xtc traj3.xtc --multi 4

and have each trajectory dispatch to the corresponding MPI rank.

Is there a technical limitation against implementing this, or are the use cases deemed too exceptional to be worth the complexity?

Edit: My bad, I see this is in fact possible by specifying a generic traj.xtc and having the trajectories in the same directory with the correct suffixes traj.0.xtc, traj.1.xtc, … I maintain the issue because this is impractical when working with separate directories for each simulation (e.g. Gromacs -multidir). As I understand it the CL parser only supports one argument per keyword, but maybe a workaround could be a comma-separated list (dir0/traj.xtc,dir1/traj.xtc, …) and parse as a vector? In any case I would suggest to improve the documentation of driver for people like me… (I can do it)

[GiovanniBussi]

Hi @ollyfutur I think this is already possible.

As for all (or most) plumed input file, when running in a "multi replica" context, plumed will first look for the file with the replica suffix and revert to the original file name if that file is not found. Hence, you should be able to simply do something like:

mpirun -n 4 plumed driver --plumed plumed.dat --mf_xtc traj.xtc --multi 4

Plumed will look for traj.0.xtc, traj.1.xtc etc.

Please notice that the --ixtc option for reading is more robust than the VMD molfile plugin (--mf_xtc). Specifically:

• it supports reading the time step
• it reads also "rotated boxes" (e.g. xtc saves after doing an alignment
• in general, it is the "official" gromacs plugin, and not its reimplementation done in VMD

The possibility to read separate trajectories should be independent of the way you read the file, but I would anyway recommend using the --ixtc option.

Giovanni

[ollyfutur]

Thanks for the answer Giovanni, I just figured this out myself today by reading the source code… I think this should be explained in the driver doc, may I open a pull request with a section about this behavior?

(Idk why I’ve always been using --mf_xtc instead of --ixtc, but we learn something every day…)

Best