<p>From GROMACS documentation about <a href="https://manual.gromacs.org/current/user-guide/managing-simulations.html#reproducibility" rel="nofollow noreferrer">reproducibility</a>:</p>
<blockquote>
<p>The following factors affect the reproducibility of a simulation, and
thus its output:</p>
<ul>
<li>Precision (mixed / double) with double giving “better” reproducibility.
Number of cores, due to different order in which forces are accumulated. For instance (a+b)+c is not necessarily binary identical
to a+(b+c) in floating-point arithmetic.</li>
<li>Type of processors. Even within the same processor family there can be slight differences.</li>
<li>Optimization level when compiling.</li>
<li>Optimizations at run time: e.g. the FFTW library that is typically used for fast Fourier transforms determines at startup which version
of their algorithms is fastest, and uses that for the remainder of the
calculations. Since the speed estimate is not deterministic, the
results may vary from run to run.</li>
<li>Dynamic linking to different versions of shared libraries (e.g. for FFTs)</li>
<li>Dynamic load balancing, since particles are redistributed to processors based on elapsed wallclock time, which will lead to (a+b)+c
!= a+(b+c) issues as above</li>
<li>Number of PME-only ranks (for parallel PME simulations)</li>
<li>MPI reductions typically do not guarantee the order of the operations, and so the absence of associativity for floating-point
arithmetic means the result of a reduction depends on the order
actually chosen</li>
<li>On GPUs, the reduction of e.g. non-bonded forces has a non-deterministic summation order, so any fast implementation is
non-reprodudible by design.</li>
</ul>
</blockquote>
<p>I would add that in your case of hard coding everything by hand you may have to look a bit into your barostat and thermostat (although their influence should be found on speed of the atoms). Maybe a sample code with coordinates and speed of 4 atoms would help to give a more precise answer.</p>
<p>You can also try having a look at <a href="https://github.com/gromacs/gromacs" rel="nofollow noreferrer">gromacs source code</a>. I believe <a href="https://github.com/openmm/openmm" rel="nofollow noreferrer">OpenMM</a> provides a bit more control and clarity on each step, if for some unfathomable reason you are not doing this only for curiosity sake but because you actually have to make a code that reproduces these results.</p>

CC BY-SA 4.0
2021-04-29T10:04:16.103Z
2021-04-29T13:46:45.113Z
2021-04-29T13:46:45.113Z
O.Laprevote
<p>I am using GROMACS to perform MD simulations of proteins. So, I tried to record the simulation results <code>nstxout</code>, <code>nstvout</code>, and <code>nstfout</code> with the same step size (<code>nstxout 1, nstvout 1, nstfout 1</code>). Then, I calculated the coordinate (step n) of an arbitrary step of the trajectory (step n) from the velocity of step n - 1, step n, and calculated the velocity of n - 1/2, and used that velocity to calculate the coordinate (n-1) of step n using the velocity of n - 1/2. LeapFrog was used in the simulation.</p>
<p>How can I get the coordinates, velocity, and force to be consistent?</p>

<simulated-data><gromacs>
GROMACS Coordinates and velocity and force trajectories do not match accuracy
# GROMACS Coordinates and velocity and force trajectories do not match accuracy

(Asked by: username_0 on 2021-04-24)

I am using GROMACS to perform MD simulations of proteins. So, I tried to record the simulation results `nstxout`, `nstvout`, and `nstfout` with the same step size (`nstxout 1, nstvout 1, nstfout 1`). Then, I calculated the coordinate (step n) of an arbitrary step of the trajectory (step n) from the velocity of step n - 1, step n, and calculated the velocity of n - 1/2, and used that velocity to calculate the coordinate (n-1) of step n using the velocity of n - 1/2. LeapFrog was used in the simulation.

How can I get the coordinates, velocity, and force to be consistent?

**Tags:** simulated-data, gromacs

---

## 1 answers

### Answer by username_1 on 2021-04-29. Score: 4 | Accepted answer

From GROMACS documentation about [reproducibility](https://manual.gromacs.org/current/user-guide/managing-simulations.html#reproducibility):

> The following factors affect the reproducibility of a simulation, and
> thus its output:
>
> * Precision (mixed / double) with double giving “better” reproducibility.
>   Number of cores, due to different order in which forces are accumulated. For instance (a+b)+c is not necessarily binary identical
>   to a+(b+c) in floating-point arithmetic.
> * Type of processors. Even within the same processor family there can be slight differences.
> * Optimization level when compiling.
> * Optimizations at run time: e.g. the FFTW library that is typically used for fast Fourier transforms determines at startup which version
>   of their algorithms is fastest, and uses that for the remainder of the
>   calculations. Since the speed estimate is not deterministic, the
>   results may vary from run to run.
> * Dynamic linking to different versions of shared libraries (e.g. for FFTs)
> * Dynamic load balancing, since particles are redistributed to processors based on elapsed wallclock time, which will lead to (a+b)+c
>   != a+(b+c) issues as above
> * Number of PME-only ranks (for parallel PME simulations)
> * MPI reductions typically do not guarantee the order of the operations, and so the absence of associativity for floating-point
>   arithmetic means the result of a reduction depends on the order
>   actually chosen
> * On GPUs, the reduction of e.g. non-bonded forces has a non-deterministic summation order, so any fast implementation is
>   non-reprodudible by design.

I would add that in your case of hard coding everything by hand you may have to look a bit into your barostat and thermostat (although their influence should be found on speed of the atoms). Maybe a sample code with coordinates and speed of 4 atoms would help to give a more precise answer.

You can also try having a look at [gromacs source code](https://github.com/gromacs/gromacs). I believe [OpenMM](https://github.com/openmm/openmm) provides a bit more control and clarity on each step, if for some unfathomable reason you are not doing this only for curiosity sake but because you actually have to make a code that reproduces these results.


---

