[gmx-developers] reproducability of md sims
Mark Abraham
mark.j.abraham at gmail.com
Sun Nov 30 12:40:36 CET 2014
On Sun, Nov 30, 2014 at 12:03 PM, Carsten Kutzner <ckutzne at gwdg.de> wrote:
> Hi,
>
> On 30 Nov 2014, at 11:17, Berk Hess <hess at kth.se> wrote:
>
> > Hi,
> >
> > There is documentation on this somewhere.
> > Even when running with MPI and/or OpenMP simulations should be
> reproducible when ran on an identical run
> But reductions of several summands into a sum do not yield a bit-identical
> result across runs.
> Therefore I think at least with MPI and/or OpenMP we will never get
> bit-identical
> trajectories unless the order of summation is fixed somehow for such
> operations.
>
True, but not the whole story. You can leave the order free if you
pre-round the operands such that the result is provably insensitive to the
order of the operations. See
http://htor.inf.ethz.ch/publications/img/arteaga-fuhrer-hoefler-reproducible-apps-ipdps14.pdf.
So one can have fully deterministic forces in MD by simply paying a couple
of flops per force component in each inner loop.
Mark
Best,
> Carsten
>
>
> > setup. The only things that usually matter, and which -reprod should
> turn off, are dynamic load balancing and FFTW kernel choice by timing.
> > You can mail me your tpr and I can have a look.
> >
> > Cheers,
> >
> > BerkOn Nov 30, 2014 9:05 AM, David van der Spoel <spoel at xray.bmc.uu.se>
> wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to test reproducibility of simulations of liquids. The
> >> simulation systems are flexible (no constraints) and run with the
> >> -reprod flag, starting from the same tpr, on a single core. However
> >> after a few hundred fs the energy starts to diverge.
> >>
> >> Are there factors impacting the reproducibility that are not controlled
> >> by the -reprod flag?
> >>
> >> --
> >> David van der Spoel, Ph.D., Professor of Biology
> >> Dept. of Cell & Molec. Biol., Uppsala University.
> >> Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.
> >> spoel at xray.bmc.uu.se http://folding.bmc.uu.se
> >> --
> >> Gromacs Developers mailing list
> >>
> >> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
> >>
> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>
> >> * For (un)subscribe requests visit
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
> > --
> > Gromacs Developers mailing list
> >
> > * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20141130/f166bd6b/attachment.html>
More information about the gromacs.org_gmx-developers
mailing list