On 6/11/13 10:55 AM, Dr. Vitaly Chaban wrote:
On Tue, Jun 11, 2013 at 3:52 PM, Justin Lemkul <jalem...@vt.edu
<mailto:jalem...@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
========================================
--
gmx-users mailing list gmx-users@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 the
www interface or send it to gmx-users-requ...@gromacs.org.
* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
