Jennifer Williams wrote:
Hello,
One of my simulations just crashed after 660,000 steps with the
following message:
Step 660560:
The charge group starting at atom 4100 moved than the distance allowed
by the domain decomposition (1.500000) in direction X
distance out of cell 2.356293
Old coordinates: 1.752 0.447 0.751
New coordinates: 3.593 1.532 0.674
Old cell boundaries in direction X: 0.000 2.116
New cell boundaries in direction X: 0.000 2.122
-------------------------------------------------------
Program mdrun, VERSION 4.0.5
Source code file: domdec.c, line: 3651
Fatal error:
A charge group moved too far between two domain decomposition steps
This usually means that your system is not well equilibrated
-------------------------------------------------------
"Why Weren't You at My Funeral ?" (G. Groenhof)
Error on node 0, will try to stop all the nodes
Halting parallel program mdrun on CPU 0 out of 8
I am modelling flexible alkyl chains which are anchored to a frozen
silica wall. This particular atom (4100) is at the edge of the periodic
boundary condition so I am guessing that what happens is that while the
anchored side stays where it is, the other free end wanders into the
next cell and this perhaps triggers the error message? If this is indeed
the problem, is there some way to stop the program stopping with an
error message when this happens?
The old and new coordinates reported aren't consistent with that, and
the error message isn't "this bond is too long", it's "this group of
atoms moved way too much last integration".
I did do an energy minimisation before starting and my structure looks
OK. It seems strange that it would crash only after 660000 steps.
Indeed.
Also what is meant by the following? I am using NVT so my simulation
cell should not change.
Old cell boundaries in direction X: 0.000 2.116
New cell boundaries in direction X: 0.000 2.122
My cell is about 4.3 x 4.3 x 7.5 nm
I am using gromacs-4.0.5
I'm mystified, but I know little about interactions with frozen groups.
I don't think Vitaly's suggestion will help in the context of a
simulation that runs for hundreds of thousands of steps.
Whether or not you can reproduce the crash will be useful data. If so,
construct a run that will stop just before it, and then continue on to
the crash with nstxout = 1 so you can see whether these atoms are really
moving lots, or perhaps a bug was provoked.
Mark
--
gmx-users mailing list [email protected]
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [email protected].
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
