[gmx-users] A charge group moved too far between two domain decomposition steps

[Justin Lemkul]

On 6/11/13 10:55 AM, Dr. Vitaly Chaban wrote:
>
>
>
> On Tue, Jun 11, 2013 at 3:52 PM, Justin Lemkul <jalemkul at vt.edu
> <mailto:jalemkul at vt.edu>> wrote:
>
>
>
>     On 6/11/13 9:27 AM, Dr. Vitaly Chaban wrote:
>
>         This problem indeed happens from time to time. With versions 4.5+ it is
>         more frequent than with versions up to 4.0.7. It is not always connected to
>         blowing up in the sense of bad contacts, positive potential energy, etc.
>         The more cores you use per job, the more likely this error to appear. The
>         larger *spatially) system you simulate, the more likely it to appear.
>
>
>     People generally reported more crashes in 4.5.x than in 4.0.x that we
>     determined arise from nsttcouple and nstpcouple being set incorrectly.
>       There's a thread somewhere about it, but in general, the same principles
>     are always true - adequate equilibration and sensible .mdp settings should
>     lead to stable integration later on.
>
>
>
> I can send you a couple of systems, which spontaneously crash. Not at the
> beginning and not at the end, just unpredictably every few dozens of
> nanoseconds. The systems are not strictly in the thermodynamic equilibrium
> state, but they are not exploding in the common sense of this term. Another
> coordinate files, executed with the same MDP file, never crash, however. I do
> not really know the reason, but it is not as simple as good or bad set of MD
> parameters. Maybe, something is connected with (deprecated) versions of external
> libraries, since at my workstation, where I control everything, crashes occur
> more rarely than at the cluster.
>

If there is a viable test case in one of those systems, upload a bug report to 
redmine.gromacs.org.  That's the only way the development team will know if 
anything needs to be fixed.  There were a lot of claims of instability early in 
the 4.5 development cycle, some bugs and others not, but since then there has 
been relative silence on the topic, so it was assumed all was well.  If it's 
not, we need to know, especially if version 4.6.2 still produces the problem 
(since 4.5.x is pretty much over with in terms of active development).

>
>
>         The simple advice is to reduce the time-step, but it is not to be
>         understood as a universal treatment.
>
>         Of course, you can reinitialize your charge groups, as this is better
>         connected with the below error message.
>
>
>     What does this mean?  Charge groups are a fixed element of the force field;
>     how would you propose adjusting them to make the error go away?
>
>
>
>
> Really? How many force fields can you enumerate, where the developers say how we
> should distribute atoms among the charge groups?
>

Nearly all of them.  AMBER and CHARMM obviously don't use charge groups (in the 
sense of a "group" being multiple atoms) and thus each atom is a "group."  The 
GROMOS parameter sets have defined charge groups that originate in the GROMOS 
software and distributed files, as all the parameters came from model compounds 
with definable (and transferable) functional groups.

-Justin

-- 
========================================

Justin A. Lemkul, Ph.D.
Research Scientist
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin

========================================