[gmx-developers] FW: [gmx-users] GROMACS 4.5.4 keep crashing all the time

Shirts, Michael (mrs5pt) mrs5pt at eservices.virginia.edu
Thu Sep 1 17:21:02 CEST 2011


Things like this make me wonder if we should group up a bunch of options,
like nstcalcenergy, nstpcouple, nsttcouple and so forth into a "high scaling
performance" options.  We don't want to make people think too much, but
having overall sets of defaults might be useful; for example, a "should
always work" and a "best for parallelizing over more than one core", which
can be selected by md option.  Something to think about!

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821

------ Forwarded Message
> From: Michael Shirts <mrshirts at gmail.com>
> Date: Thu, 1 Sep 2011 09:08:40 -0600
> To: Michael Shirts <michael.shirts at virginia.edu>
> Subject: Fwd: [gmx-users] GROMACS 4.5.4 keep crashing all the time
> 
> ---------- Forwarded message ----------
> From:  <chris.neale at utoronto.ca>
> Date: Thu, Sep 1, 2011 at 8:59 AM
> Subject: [gmx-users] GROMACS 4.5.4 keep crashing all the time
> To: gmx-users at gromacs.org
> 
> 
> That all makes sense Tsjerk.
> 
> I wonder if mdrun terminations based on LINCS warnings should come
> with an additional message to explain that one may try running for a
> while with nstpcouple=1.
> 
> Also, I'm still a little curious about a question that Itamar asked a
> few posts ago:
> 
> "If this is the case, why 5 ns simulations done with 4.0.7 crashed
> when extended it using 4.5.4?"
> 
> Mark provided a good explanation about how this could be possible, but
> I've never seen lincs warnings or systems blowing up after 5 ns of
> equilibration. I fully realize that it may take even us of simulation
> to properly equilibrate statistical properties, but in my experience
> it is far outside of ordinary to require >5 ns of equilibration to
> avoid systems blowing up.
> 
> Chris.
> 
> -- original message --
> 
> Hi Chris,
> 
> I can imagine that the pressure scaling has a more profound effect on
> the 'visible' surroundings if a cut-off is used, while this will not
> be the case when using PME. So the shock for an atom when the
> coordinates are adjusted can be expected to be greater with cut-off
> based methods, rendering such simulations less stable. As for SD,
> probably that causes sufficient damping of jitter introduced due to
> pressure coupling for it not to propagate and cause problems.
> But those are just my two cents (about 2.8 dollar cents with current rates
> :p).
> 
> Cheers,
> 
> Tsjerk
> 
> On Thu, Sep 1, 2011 at 2:41 PM,  <chris.neale at utoronto.ca> wrote:
>> 
>> I am glad that the pressure coupling intervals have been identified as a
>> source of instability for poorly equilibrated systems as I was unaware of
>> that. Still, the fact that the SD integrator also solves the problem also
>> suggests that this is simply a poorly equilibrated system. I am not sure why
>> PME would run fine and reaction field would give lincs warnings, but then
>> again I have no experience with using a reaction field.
>> 
>> Chris.
>> 
>> On 1/09/2011 6:32 PM, Itamar Kass wrote:
>>> 
>>> Hi Tsjerk,
>>> 
>>> Thanks for the help, it actually worked. When nstpcouple is set to 1m the
>>> system can be equilibrated (NPT) without LINCS error. I hadn't thought about
>>> it as I never use NVT (unless doing FE calculations).
>> 
>> Equilibrating with NVT before NPT can be wise when the system starts far
>> from equilibrium.
>> 
>>> 
>>> 
>>> Is this mean the 4.5.4 is more sensitive the 4.0.7? Is this effect the
>>> data collected till now? If this is the case, why 5 ns simulations done with
>>> 4.0.7 crashed when extended it using 4.5.4?
>> 
>> IIRC 4.0.x and 4.5.x have different mechanisms for deciding how often to
>> do global communication for things like T and P coupling. Mostly you can
>> get away with the same kind of approximation one uses with twin-range
>> neighbour lists, periodic neighbour list updates, RESPA, etc. where
>> slowly-varying quantities don't have to be recalculated every step.
>> However during equilibration (and that includes the transition from
>> 4.0.x to 4.5.x) those assumptions need not be valid. So tuning the
>> update frequency to be high during transitions is a good idea. Then
>> relax them and see how you go.
>> 
>> Mark
>> 
>>> 
>>> Also, is this mean I can do my productive run using 4.5.4 with the default
>>> value of nstpcouple, it seems that setting it to 1 greatly increases the
>>> computational time. To the best of my knowledge, in prior version nstpcouple
>>> was set to 1 by default.
>>> 
>>> Cheers,
>>> Itamar
>>> 
>>> 
>>> On 01/09/2011, at 4:47 PM, Tsjerk Wassenaar wrote:
>>> 
>>>> Hi Itamar,
>>>> 
>>>> I haven't really followed the discussion and I'm a bit too lazy to
>>>> look it all up now ;) But have you tried setting the nst parameters to
>>>> 1  (except for output). Especially nstpcouple. Note that nstpcouple=1
>>>> requires nstlist=1 and nstcalcenergy=1. If that solves the problem,
>>>> you may need to extend your equilibration a bit, first relaxing NVT,
>>>> followed by NPT with nstpcouple=1, thereafter equilibrating using
>>>> productions conditions. It it solves it, maybe the option should be
>>>> renamed nstptrouble :p
>>>> 
>>>> Hope it helps,
>>>> 
>>>> Tsjerk
>>>> 
>> 
>> 
>> 
>> --
>> gmx-users mailing list    gmx-users at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> Please don't post (un)subscribe requests to the list. Use thewww interface
>> or send it to gmx-users-request aGROMACS 4.5.4 keep crashing all the time
> 
> Tsjerk Wassenaar tsjerkw at gmail.com
> Thu Sep 1 15:48:40 CEST 2011
> 
>    * Previous message: [gmx-users] GROMACS 4.5.4 keep crashing all the time
>    * Next message: [gmx-users] Non-zero total charge
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
> Hi Chris,
> 
> I can imagine that the pressure scaling has a more profound effect on
> the 'visible' surroundings if a cut-off is used, while this will not
> be the case when using PME. So the shock for an atom when the
> coordinates are adjusted can be expected to be greater with cut-off
> based methods, rendering such simulations less stable. As for SD,
> probably that causes sufficient damping of jitter introduced due to
> pressure coupling for it not to propagate and cause problems.
> But those are just my two cents (about 2.8 dollar cents with current rates
> :p).
> 
> Cheers,
> 
> Tsjerk
> 
> On Thu, Sep 1, 2011 at 2:41 PM,  <chris.neale at utoronto.ca> wrote:
>> 
>> I am glad that the pressure coupling intervals have been identified as a
>> source of instability for poorly equilibrated systems as I was unaware of
>> that. Still, the fact that the SD integrator also solves the problem also
>> suggests that this is simply a poorly equilibrated system. I am not sure why
>> PME would run fine and reaction field would give lincs warnings, but then
>> again I have no experience with using a reaction field.
>> 
>> Chris.
>> 
>> On 1/09/2011 6:32 PM, Itamar Kass wrote:
>>> 
>>> Hi Tsjerk,
>>> 
>>> Thanks for the help, it actually worked. When nstpcouple is set to 1m the
>>> system can be equilibrated (NPT) without LINCS error. I hadn't thought about
>>> it as I never use NVT (unless doing FE calculations).
>> 
>> Equilibrating with NVT before NPT can be wise when the system starts far
>> from equilibrium.
>> 
>>> 
>>> 
>>> Is this mean the 4.5.4 is more sensitive the 4.0.7? Is this effect the
>>> data collected till now? If this is the case, why 5 ns simulations done with
>>> 4.0.7 crashed when extended it using 4.5.4?
>> 
>> IIRC 4.0.x and 4.5.x have different mechanisms for deciding how often to
>> do global communication for things like T and P coupling. Mostly you can
>> get away with the same kind of approximation one uses with twin-range
>> neighbour lists, periodic neighbour list updates, RESPA, etc. where
>> slowly-varying quantities don't have to be recalculated every step.
>> However during equilibration (and that includes the transition from
>> 4.0.x to 4.5.x) those assumptions need not be valid. So tuning the
>> update frequency to be high during transitions is a good idea. Then
>> relax them and see how you go.
>> 
>> Mark
>> 
>>> 
>>> Also, is this mean I can do my productive run using 4.5.4 with the default
>>> value of nstpcouple, it seems that setting it to 1 greatly increases the
>>> computational time. To the best of my knowledge, in prior version nstpcouple
>>> was set to 1 by default.
>>> 
>>> Cheers,
>>> Itamar
>>> 
>>> 
>>> On 01/09/2011, at 4:47 PM, Tsjerk Wassenaar wrote:
>>> 
>>>> Hi Itamar,
>>>> 
>>>> I haven't really followed the discussion and I'm a bit too lazy to
>>>> look it all up now ;) But have you tried setting the nst parameters to
>>>> 1  (except for output). Especially nstpcouple. Note that nstpcouple=1
>>>> requires nstlist=1 and nstcalcenergy=1. If that solves the problem,
>>>> you may need to extend your equilibration a bit, first relaxing NVT,
>>>> followed by NPT with nstpcouple=1, thereafter equilibrating using
>>>> productions conditions. It it solves it, maybe the option should be
>>>> renamed nstptrouble :p
>>>> 
>>>> Hope it helps,
>>>> 
>>>> Tsjerk
>>>> 
>> 
>> 
>> 
>> --
>> gmx-users mailing list    gmx-users at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> Please don't post (un)subscribe requests to the list. Use thewww interface
>> or send it to gmx-users-request at gromacs.org.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
> 
> 
> 
> --
> Tsjerk A. Wassenaar, Ph.D.
> 
> t gromacs.org.
>> 
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
> 
> 
> 
> --
> Tsjerk A. Wassenaar, Ph.D.
> 
> 
> 
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use thewww
> interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

------ End of Forwarded Message




More information about the gromacs.org_gmx-developers mailing list