Hi guys, I really would like to use lammps but I seem to be running into
a problem. I've been doing a 10,000 atom TIP4P water simulation and the
pressure has been varying wildly from -500 atm to 500 atm. I'm doing a
minimization, an NVT heating, and NPT with damping (I've tried
increasing damping up to 10). I've attached my input file and log file.
You'll also notice various commented out things I've tried. The strange
thing is that if I remove the "hybrid" argument from the pair_style
lj/cut/coul/long/tip4p then I get an "ERROR: Out of range atoms - cannot
compute PPPM" right after minimization and the program crashes. I've
found a similar problem from a while back on the mailing list, found
here
http://sourceforge.net/mailarchive/message.php?msg_name=20080624222119.0lpjr9h0asokwwo8%40wm3.web.pacific.net.sg
I used the input files given in that thread as comparison, to make sure
there wasn't something wrong with my data file. I got the same problem
as with my input and water data files. In that thread the problem was
with the box dimensions, whereas my box dimensions are very steady. I'm
able to replicate the example files that come with lammps and I've run
these simulations on 1, 4, and 8 CPUs. There was also a recent posting
on this mailing list about the PPPM error with TIP4P that was
unresolved. Any help would be greatly appreciated.
Thanks,
Andrew
in.water (1.29 KB)
log.water (14 KB)
2009/3/24 Andrew White <whitead@…551…>
Hi guys, I really would like to use lammps but I seem to be running into
a problem. I’ve been doing a 10,000 atom TIP4P water simulation and the
pressure has been varying wildly from -500 atm to 500 atm. I’m doing a
minimization, an NVT heating, and NPT with damping (I’ve tried
increasing damping up to 10). I’ve attached my input file and log file.
You’ll also notice various commented out things I’ve tried. The strange
thing is that if I remove the “hybrid” argument from the pair_style
lj/cut/coul/long/tip4p then I get an “ERROR: Out of range atoms - cannot
compute PPPM” right after minimization and the program crashes. I’ve
found a similar problem from a while back on the mailing list, found
here
http://sourceforge.net/mailarchive/message.php?msg_name=20080624222119.0lpjr9h0asokwwo8%40wm3.web.pacific.net.sg
I used the input files given in that thread as comparison, to make sure
there wasn’t something wrong with my data file. I got the same problem
as with my input and water data files. In that thread the problem was
with the box dimensions, whereas my box dimensions are very steady. I’m
able to replicate the example files that come with lammps and I’ve run
these simulations on 1, 4, and 8 CPUs. There was also a recent posting
on this mailing list about the PPPM error with TIP4P that was
unresolved. Any help would be greatly appreciated.
Hi, Andrew:
Could you send me a copy of your data.water file, as well as the output file you got? I am trying to reproduce what you’re seeing, and so far I’m not getting those errors. (Are you using the latest version? That should take care of the PPPM errors.)
–AEI
Ok, I've attached two sets of files. The "small" is 300 atoms and a log
file, which may be easier to work with than the 10,000 atom system,
which is called "large." I also attached data.snwt, which is from that
thread I referred to earlier which has been giving me the same problems.
I'm using openmpi and a Jan 09 release, which I believe is the most
recent. Thanks for the prompt response! Note: to satisfy the 200k
sourceforge limit I cut down the large data.water file, but I'll send
you the full file in a separate e-mail.
~Andrew
waterFiles.zip (56.8 KB)
I'll let Ahmed look at the pressure fluctuations, though I'll note that
large pressure fluctutations are not abnormal for many systems.
I don't know of any outstanding issue with PPPM and TIP4P.
Can you send me the data.water file for this example - I'll look
at the difference between hybrid and non-hybrid.
Steve
Dear Steve,
It seemed I got the similar problem with TIP4P potential even in a simpler case. I just did the equilibrium with the initial input configuration. As you suggested to me yesterday, I check with the thermodynamic info with only 96 input atoms. Still after 72500 steps run, I got ERROR: Out of range atoms - cannot compute PPPM. I checked the configuration with VMD. There is no dramatic jumps of the atoms. It’s also strange that the atoms seem to be frozen, because the temperature is changed close to zero by the code(please see the log file) while I use NVT with 300K. That’s abnormal.
I attached my input files and log file here. Any help would be most appreicated.
Best
Yajie
in.equil (1.55 KB)
log.lammps (45.5 KB)
tip4p.dat (11 KB)
Try changing this to delay 0:
neigh_modify delay 2 every 1 check yes
If you let LAMMPS re-neighbor as often as it thinks
it needs to, you should generally not get the Out of Range
PPPM error, unless atoms get blown far away.
Steve
I just ran your in.water/data.water on my box on 4 CPUs and see
none of the issues you mention. Note that I always run the most
current (fully-patched) version. The message you reference was
nearly a year old - I think that bug has been fixed.
I slightly modified your input script to run more quickly, and just ran
through the NVT section. I'll let Ahmed comment on NPT w/ TIP4P
and fluctuations, which as I said before may be normal.
I see no difference when using hybrid vs pure TIP4P. The printed-out
thermo is identical (as it should be). I get no out-of-range error. I will
say that you are using the default neigh_modify settings, which
can attempt to re-neighbor too infrequently for PPPM. If you
use
neigh_modify delay 0 every 1 check yes
then you should not get this error, assuming your system is well behaved.
From doc/Section_errors.html:
Out of range atoms - cannot compute PPPM
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
"neighbor skin distance"_neighbor.html without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
"neigh_modify"_neigh_modify command. Second, it may mean that an atom
has moved far outside a processor's sub-domain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
Attached is my slightly modified input script and log file, which you can
compare your runs to.
Steve
in.bug (1.47 KB)
log.lammps (20 KB)
I just ran your in.water/data.water on my box on 4 CPUs and see
none of the issues you mention. Note that I always run the most
current (fully-patched) version.
I slightly modified your input script to run more quickly, and just ran
through the NVT section. I'll let Ahmed comment on NPT w/ TIP4P
and fluctuations, which as I said before may be normal.
I see no difference when using hybrid vs pure TIP4P. The printed-out
thermo is identical (as it should be). I get no out-of-range error. I will
say that you are using the default neigh_modify settings, which
can attempt to re-neighbor too infrequently for PPPM. If you
use
neigh_modify delay 0 every 1 check yes
then you should not get this error, assuming your system is well behaved.
From doc/Section_errors.html:
Out of range atoms - cannot compute PPPM
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
"neighbor skin distance"_neighbor.html without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
"neigh_modify"_neigh_modify command. Second, it may mean that an atom
has moved far outside a processor's sub-domain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc.
Attached is my slightly modified input script and log file, which you can
compare your runs to.
Steve
After comparing our input files I saw that you changed these lines:
pair_coeff 1 1 0.16275 3.16435
pair_coeff 1 2 0.0 0.0
pair_coeff 2 2 0.0 0.0
#pair_coeff 1 1 lj/cut/coul/long/tip4p 0.16275 3.16435
#pair_coeff 1 2 lj/cut/coul/long/tip4p 0.0 0.0
#pair_coeff 2 2 lj/cut/coul/long/tip4p 0.0 0.0
Isn't the second set, what you commented out, required for a hybrid run?
The "Out of range atoms - cannot compute PPPM" did not occur with your
change. I was able to replicate your results with and without the
"hybrid" argument to the "pair_style" command. But, if I understand the
"pair_coeff" command correctly, I would not actually be able to run a
hybrid simulation without specifying the potential type. Is there
something I'm missing? I also applied all the patches since the 9Jan09
release and I'm still getting all the errors. The pressure fluctuations
I referred to earlier were also present with your input file on my
system. Thanks for looking into this so quickly and I appreciate you
using your time for this!
~Andrew
Your original email said you were getting different answers
with and without hybrid, which shouldn't occur. So I used
the same input script to run both cases (commenting in/out).
I got the same answers in both cases, so I'm not seeing
your problem.
Your email below says you replicate my results (no problems),
but then you patched the 9Jan09 version and are still
having the problems. I don't understand what you mean.
You can run the script I sent and have no problems with
the most current version or you can't ?
The pressure fluctuations are a different question.
Steve
Sorry about the confusion, I got it figured out now. My problem was that
I wasn't changing the pair_coeff command when removing "hybrid" from the
pair_style command. I was using hybrid style pair_coeff syntax with
non-hybrid pair_style. Lammps was continuing all the way through
minimization and the initialization steps. It wasn't crashing until the
first NVT step when it calls the particle_map() function in
pppm_tip4p.cpp . This meant I was seeing the "ERROR: Out of range atoms
- cannot compute PPPM" for a syntax error. Maybe if there was a way to
catch the syntax problem so that PPPM wouldn't get blamed? Guess I
should have RTFM in the first place. Here is the offending code for your
reference:
pair_style lj/cut/coul/long/tip4p 1 2 1 1 0.125 12
pair_coeff 1 1 lj/cut/coul/long/tip4p 0.16275 3.16435
pair_coeff 1 2 lj/cut/coul/long/tip4p 0.0 0.0
pair_coeff 2 2 lj/cut/coul/long/tip4p 0.0 0.0
Hope the pressure fluctuations are as easy to fix! Thanks again for your
help.
~Andrew
You got bit b/c the pair_coeff command for this pair style
can take 2,3, or 4 args. So it read "lj/cut/coul/long/tip4p"
as a number and probably assigned a value of 0.0.
I suppose LAMMPS could check that when it expects a numeric
value, the user hasn't specified a non-numeric string, but the
reading of input args happens a zillion places in the code, so
not an easy error check. So I'd chalk this one up to user error,
sorry.
Steve