[gmx-users] A charge group moved too far between two domain decomposition steps
jalemkul at vt.edu
Tue Jun 11 19:15:10 CEST 2013
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 A. Lemkul, Ph.D.
Department of Biochemistry
jalemkul[at]vt.edu | (540) 231-9080
More information about the gromacs.org_gmx-users