[gmx-users] periodic boundary issue
pwhitfor at ctbp.ucsd.edu
Fri Dec 12 02:26:20 CET 2008
My apologies for not providing the appropriate subject line before. You
can delete the last post, to keep the archive more organized.
I am extending the run with tpbconv and a trajectory file. I also get this
error if I change the number of steps in the tpr by using tpbconv and then
using a checkpoint to start the next run. I get this error in both serial
I used this same procedure for a system that did not cross a boundary and I
had no problems. I can provide you with the first tpr and the extended tpr
if that would help.
I added the flag -pforce 1000000 and I get the following output
199999992 steps, 100000.0 ps (continuing from step 100000000, 50000.0 ps).
step 100000000 atom 1444 x 13.886 25.151 4.660 force
step 100000000 atom 1687 x 9.419 20.258 13.016 force
This is on the first step of the simulation. What is very odd is that
these two atoms do not have a bond connecting them and they are not close to
one another. Since the forces are very close, gromacs may be calculating
an interaction between them.
Here is another weird feature: if I look at the gro file that corresponds to
the last frame of the previous run, these atoms coordinates are
1444 13.886 8.231 4.660
1687 9.419 3.338 13.016
and my pbc size is
16.92 16.92 16.92
It appears that the y positions are being shifted out of the box, even
though they are not close to the y boundaries. Perhaps this is connected to
This system has ligands that are included as the same molecule substrate (in
the .top file they are all 1 big molecule), so perhaps gromacs thinks this
is a periodic molecule because atoms are crossing different boundaries.
About a year ago I had an issue with pdb=xyz versus full. I had to use full
to get these systems to not explode when crossing a boundary. My
understanding is that full is now been absorbed by xyz, so I should just use
xyz. Also, there is no problem crossing boundaries during the initial
simulation. It only has trouble on the first frame of the extended run.
> Date: Thu, 11 Dec 2008 10:12:01 +0100
> From: Berk Hess <gmx3 at hotmail.com>
> Subject: RE: [gmx-users] periodic boundary issue
> To: Discussion list for GROMACS users <gmx-users at gromacs.org>
> Message-ID: <BLU134-W4425B057F0648B0E8D6C8E8EF80 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
> I have not heard before about such problems.
> What did you do exactly?
> Did you continue your simulation the old fashioned way:
> tpbconv with a trajectory file?
> In 4.0 there are checkpoint files which can be read by mdrun -cpi,
> so you only need tpbconv to increase the number of steps in your tpr file.
> But the old fashioned way should still work.
> If there would be a pbc error I would expect the problems you describe
> to occur at step 0.
> Are you running in parallel?
> Date: Wed, 10 Dec 2008 19:32:18 -0800
> From: pwhitfor at ctbp.ucsd.edu
> To: gmx-users at gromacs.org
> Subject: [gmx-users] periodic boundary issue
> I am having the following issue with Gromacs 4.0.2:
> I run a simulation with pbc=xyz. By the end of the simulation my molecule
> is split by the boundary (half of the molecule appears on one side and the
> other half on the opposite side). This is not a problem. The problem
> occurs when I use tpbconv to extend my run. Then, within the first few
> steps (<100 steps) of the extended run I get messages like
> Warning: 1-4 interaction between 1251 and 962 at distance 69.927 which is
> larger than the 1-4 table size 51.500 nm
> These are ignored for the rest of the simulation
> This usually means your system is exploding,
> if not, you should increase table-extension in your mdp file
> or with user tables increase the table size
> Program mdrun, VERSION 4.0
> Source code file: nsgrid.c, line: 357
> Range checking error:
> Explanation: During neighborsearching, we assign each particle to a grid
> based on its coordinates. If your system contains collisions or parameter
> errors that give particles very high velocities you might end up with some
> coordinates being +-Infinity or NaN (not-a-number). Obviously, we cannot
> put these on a grid, so this is usually where we detect those errors.
> Make sure your system is properly energy-minimized and that the potential
> energy seems reasonable before trying again.
> Variable ci has value -2147483648. It should have been within [ 0 .. 1331 ]
> What appears to be happening is that when the run is extended, the pbc is
> not imposed correctly, and the system explodes from all of the covalent
> bonds being stretched across the length of the box. This also occurs if I
> take the final gro structure from the previous run and use grompp instead of
> tpbconv. This occured in 20 different trajectories, all of which had run
> successfully with no issues for millions of time steps immediately before.
> Any ideas what is going on? I did not have this issue with the cvs
> version, but once 4.0 was released I started having this trouble.
> Thanks in advance
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> gmx-users mailing list
> gmx-users at gromacs.org
> Please search the archive at http://www.gromacs.org/search before posting!
> End of gmx-users Digest, Vol 56, Issue 32
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-users