[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