System Boundaries Changing Nonisotropically in NPT Simulation

Hello,

I’ve run into a peculiar problem; in a nutshell, I’m attempting to run an NPT simulation with rigid molecules, so I use the fix rigid/npt command. The command is:
fix 1 all rigid/npt molecule temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0

At first, the simulation appears to be working normally, but after some time the box boundaries in the x direction diverge from the box boundaries in the y and z direction. The illustrative parts of the dump file are at the bottom of this email, along with the full input file. Since I used the “iso” keyword, I expected the box to stay a perfect cube, which it clearly is not doing.

This simulation was run using the July 2013 version of LAMMPS because it is the default on NERSC’s Hopper computer cluster. When I run the simulation on my local computer or on another cluster, on both of which I’ve installed the most recent version of LAMMPS (build serial), it works fine. This first led me to believe that the problem lay in the parallel usage of LAMMPS, so I attempted to re-run the simulation on NERSC with just 1 MPI task. However, the same error occurred.

I’m currently working on making a parallel build of the latest version of LAMMPS on NERSC to check that the problem stems from a bug that has been corrected since the July 2013 version. However, since I don’t see anything on the “Bug Fixes” or “History” portions of the LAMMPS website, I’m wondering whether this is the case…

I’d be grateful for any good pointers.

Efrem Braun

Graduate Research Assistant
University of California, Berkeley

Selected headers in the dump file follow:

ITEM: TIMESTEP
0
ITEM: NUMBER OF ATOMS
80
ITEM: BOX BOUNDS pp pp pp
0 100
0 100
0 100
…(skip ahead until right before the error first appears)

ITEM: TIMESTEP
12000
ITEM: NUMBER OF ATOMS
80
ITEM: BOX BOUNDS pp pp pp
-8.34825 108.348
-8.34825 108.348

-8.34825 108.348

ITEM: TIMESTEP
13000
ITEM: NUMBER OF ATOMS
80
ITEM: BOX BOUNDS pp pp pp
-8.79957 108.8
-8.79854 108.799
-8.79854 108.799

…(skip ahead to much later to see the error accumulation)

ITEM: TIMESTEP
100000
ITEM: NUMBER OF ATOMS
80
ITEM: BOX BOUNDS pp pp pp

-845.976 945.976
31.9542 68.0458
31.9542 68.0458

The input file follows:

units real
atom_style full
pair_style hybrid lj/charmm/coul/long 9.0 15.0

kspace_style pppm 0.0001
pair_modify mix geometric

pair_coeff 1 1 lj/charmm/coul/long 0.0 1.000
pair_coeff 2 2 lj/charmm/coul/long 0.1553 3.166
pair_coeff 3 3 lj/charmm/coul/long 0.0210 1.580
pair_coeff 4 4 lj/charmm/coul/long 0.2071 3.748

read_data system.data #(I can send this if requested)

velocity all create 300.0 38564
timestep 1.0
thermo 100
group CofMs type 1
neigh_modify delay 0 every 1

fix 1 all rigid/npt molecule temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0
dump 1 CofMs custom 1000 traj_npt_CofMs.dump id mol type x y z ix iy iz
run 100000

My apologies for the quick update, but of course I wasn’t able to create the correct makefile after I had sent the prior email.

After making the latest (build parallel) version of LAMMPS on Hopper, the error went away. There’s either a bug with the July 2013 version of LAMMPS or with one of the libraries that Hopper uses. I’m looking into it now, and I’ll post the solution when I find it.

Hello,

I've run into a peculiar problem; in a nutshell, I'm attempting to run an
NPT simulation with rigid molecules, so I use the fix rigid/npt command. The
command is:
fix 1 all rigid/npt molecule temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0

At first, the simulation appears to be working normally, but after some time
the box boundaries in the x direction diverge from the box boundaries in the
y and z direction. The illustrative parts of the dump file are at the bottom
of this email, along with the full input file. Since I used the "iso"
keyword, I expected the box to stay a perfect cube, which it clearly is not
doing.

This simulation was run using the July 2013 version of LAMMPS because it is
the default on NERSC's Hopper computer cluster. When I run the simulation on
my local computer or on another cluster, on both of which I've installed the
most recent version of LAMMPS (build serial), it works fine. This first led
me to believe that the problem lay in the parallel usage of LAMMPS, so I
attempted to re-run the simulation on NERSC with just 1 MPI task. However,
the same error occurred.

I'm currently working on making a parallel build of the latest version of
LAMMPS on NERSC to check that the problem stems from a bug that has been
corrected since the July 2013 version. However, since I don't see anything
on the "Bug Fixes" or "History" portions of the LAMMPS website, I'm
wondering whether this is the case...

please note that the bugfix might have been of a more generic nature
and not specific to fix rigid. also, there occasionally are subtle
changes to the code, where there is no known problem report, but
somebody just spots a piece of code that is obviously incorrect.
finally, when bugs are fixed for a specific known problem, one usually
looks for similar code constructs within the rest of the code since
bugs are often replicated due to programming habits of programmers or
common misunderstandings of some complex constructs within the code.
to my knowledge there have not been many changes to the various fix
rigid styles except for problems with the image flags and encoding of
64-bit integers for communication, which may very well explain the
issue you are seeing.

i know this doesn't help much, but just this is meant as a reminder
that things may not be as straightforward. it would be helpful, if you
can provide a small test case, that can demonstrate the bad behavior
rapidly, so that it can be used as a test case for future regression
testing.

thanks,
     axel.

Hi Axel,

I’ve been unable to reproduce the bug with a simple LJ particle system, but here’s as simplified a version as I can make (my apologies that it does still take about 5 minutes to run on a 24-CPU node). I used an adapted version of the spce water molecule that’s included in the moltemplate examples. I set the run time to go as short as it needs to go for the error to appear. Files that are below include:
1A. spce.lt
2A. system.lt
3B. system.in
4C. system.in.init
5C. systeym.in.settings
6C. system.data

Files labeled with an “A” are those that I fed into moltemplate, files labeled with a “B” are those that moltemplate returned and which I adjusted, and files labeled with a “C” are those which moltemplate returned and which I didn’t touch (you can generate these yourself if you wish).

Files follow.

1A. spce.lt

file “spce.lt