[gmx-developers] Question about restarting
Joseph Coffland
joseph at cauldrondevelopment.com
Thu Oct 10 06:35:15 CEST 2019
Hello Gromacs devs,
It sounds like we need to create a new upgraded Folding at home Gromacs core
ASAP. v5.0.4 was not so old when our code was developed but no one has
touched it in years. Unfortunately, I need a short term solution before I
can consider a new version.
The good news is I believe I've tracked it down. After trying to
reproduce the problem in Linux I found it only occurred in Windows. This
led me to a problem in our override of truncate() (gmx_wintruncate() in
checkpoint.c) on Windows. Fortunately, it's an easy fix.
Thanks for the pointers. I'll talk to Peter Kasson about the new GMX API
when we get to creating the next core and pass on the urgent
recommendation that we upgrade soon. Thanks for all your hard work.
Regards,
Joseph
On Tue, October 8, 2019 11:25 pm, Berk Hess wrote:
> <div dir='auto'>Hi,<div dir="auto"><br></div><div dir="auto">I can add
> that the latest versions of GROMACS never write trr frames with all
> nstx/v/fout options set to zero. But many years ago we always wrote a
> frame at mdrun termination. My memory is not that good that I recall at
> which version we removed this "feature", but is seems like 5.0 is affected
> by this.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div
> dir="auto"><br></div><div dir="auto">Berk</div></div><div
> class="gmail_extra"><br><div class="gmail_quote">On Oct 9, 2019 08:15,
> Erik Lindahl <erik.lindahl at gmail.com> wrote:<br type="attribution"
> /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
> solid;padding-left:1ex"><p dir="ltr">Hi Joseph,</p>
> <p dir="ltr">If this happens in a released version of Gromacs that's
> supported (last version or two, depending on severity), it's something
> we'll look into if there's a redmine filed with examples of how to
> reproduce it. If you can't reproduce it with a normal recent Gromacs
> release, it should only be a matter of tracking down the differences.</p>
> <p dir="ltr">In general there is NO reason to ever use full-precision TRR
> trajectories for any modern simulations given that we have exact restarts
> - it's just massive data bloat. I also hope you realize that it's a
> remarkably bad idea to use a 5-year-old version (and not even the latest
> patch of that release) that hasn't been supported for years for scientific
> work.</p>
> <p dir="ltr">In principle we're also quite open to provide support both
> for old code versions, development outside the Gromacs source tree or even
> private versions, but that would typically involve a consulting
> contract.</p>
> <p dir="ltr">Cheers,</p>
> <p dir="ltr">Erik </p>
> <p dir="ltr">--<br>
> Erik Lindahl <erik.lindahl at scilifelab.se><br>
> Professor of Biophysics<br>
> Science for Life Laboratory<br>
> Stockholm University & KTH<br>
> Office (SciLifeLab): +46 8 524 81567<br>
> Cell (Sweden): +46 73 4618050 <br>
> Cell (US): 1 267 307 8746<br></p>
> <p dir="ltr">> On Oct 9, 2019, at 02:33, Joseph Coffland
> <joseph at cauldrondevelopment.com> wrote:<br>
> > <br>
> > Hello,<br>
> > <br>
> > I'm the lead developer at Folding at home. We've recently
> discovered a<br>
> > problem with our Gromacs folding core. We are currently using
> Gromacs<br>
> > v5.0.4.<br>
> > <br>
> > The problem we are having is that each time we stop a simulation
> and<br>
> > restart it the .trr files grow. Some machines are configured to
> on run<br>
> > when idle. This can lead to many start and stops which results
> in huge<br>
> > .trr files that are difficult to return to our servers. I
> assume Gromacs<br>
> > is writing a final frame.<br>
> > <br>
> > Our code calls gmx_mdrun() and then gmx_set_stop_condition(2) to
> break out<br>
> > of the simulation. We then start again from the last checkpoint
> using<br>
> > -cpt.<br>
> > <br>
> > Any advice on how to avoid this extra .trr data or remove it when we
> restart?<br>
> > <br>
> > Thanks,<br>
> > <br>
> > Joseph<br>
> > <br>
> > -- <br>
> > Cauldron Development LLC<br>
> > http://www.cauldrondevelopment.com/<br>
> > Cell: 208-409-9128<br>
> > <br>
> > -- <br>
> > Gromacs Developers mailing list<br>
> > <br>
> > * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!<br>
> > <br>
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists<br>
> > <br>
> > * For (un)subscribe requests visit<br>
> >
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.<br>
> -- <br>
> Gromacs Developers mailing list</p>
> <p dir="ltr">* Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!</p>
> <p dir="ltr">* Can't post? Read
> http://www.gromacs.org/Support/Mailing_Lists</p>
> <p dir="ltr">* For (un)subscribe requests visit<br>
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.</p>
> </blockquote></div><br></div>--
> 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.
--
Cauldron Development LLC
http://www.cauldrondevelopment.com/
Cell: 208-409-9128
More information about the gromacs.org_gmx-developers
mailing list