System Boundaries Changing Nonisotropically in NPT Simulation

375 atoms


fix 1 all rigid/npt molecule temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0

Just a comment:
It looks like your original system had only 80 atoms.
Even a system with 375 atoms is so tiny that I'm guessing the volume
fluctuations would be pretty large, and 1 bar of pressure is pretty
hard to distinguish from zero.

Either way, the boundary should remain cubic however. I'm running
your test case now to check that.

As you pointed out, this bug does not seem to be present with recent
versions of LAMMPS. (I'm the using 5 Apr 2014 version). The box
fluctuates a lot as the waters start nucleating, but it remains

I am inclined to say not to worry about any strange behaviour you saw
with 6-month-old versions of LAMMPS, as it could be a bug which was
silently fixed recently. (It happens sometimes. I think once quietly
submitted a minor bug-fix to dihedral_table.cpp. It does not always
end up in the bug log, -which in that case was okay.)

-21.0962 121.096
-21.0962 121.096
-21.0962 121.096

Thanks for verifying Andrew. Yes, in an effort to simplify the code such that others could see the error, I actually ended up adding more atoms. My original simulation actually had 80 molecules, with much more than 80 atoms, but I was only dumping one atom from each molecule.

It would be nice to be able to run this input on the July 2013 version of LAMMPS on a different cluster than Hopper so that I could verify that it’s the LAMMPS version, rather than something cluster-specific, that’s causing the error. Unfortunately, I don’t see a way to download that version from the LAMMPS website. If there’s a way to get the old source code, I could do that quick check.

Thanks for moltemplate by the way.

The download page has a link to a listing of old versions

that can be downloaded.


The download page has a link to a listing of old versions
that can be downloaded.

​...and through the svn and git repositories, one can track changes to the
sources down to the individual commits.​

Ah, sorry I missed it. I just built the July 2013 version on my local computer and ran the “simplified” input that I had sent out earlier. The error did not appear. It seems that the bug must lie in one of the linked libraries that NERSC used to build LAMMPS (guessing the FFT one). I’ve notified NERSC about the bug; for now, people using LAMMPS on NERSC might want to be a bit careful, and perhaps compile their own executable to run LAMMPS off of rather than use the default version.

Efrem, thanks for the update.

The differences in fix rigid/npt (and in fix_rigid_nh.cpp) between the 1Jul13 version and the 18Apr14 version are unlikely related to the issue you reported:

fix_rigid_npt.cpp: (a change in a member variable’s name)
< box_change = 1;


That’s a smart way to check the FFT library. I just reran the simplified input, changing only the pair_style in the manner you mentioned, using a cutoff of 12.0 (while getting rid of the “kspace_style” line and changing the “pair_coeff” line to reflect the pair_style change). Interestingly, the box bounds still changed in a non-isotropic manner, meaning it must be a different library than the FFT one. I’m not sure what it could be in that case…We’ve ruled out that it could be the LAMMPS version or the FFT library.