Hi Lammps Users,
I am running an OPLS-AA simulation of a hydrocarbon with graphene. I have run a minimization step and NVE at ~300K for about 10K timesteps and the system runs with no complaints but when I try to switch over to NPT the system gives me an “Out of range atoms - cannot compute PPPM” error. This seems to be a pretty common error and I have tried the suggested fixes, specifically setting neigh_modify to delay 0 every 1 check yes and decreasing the time and that doesn’t seem to work.
I have also tried setting the initial pressure to something closer to the final pressure from the NVE step. This does not give an error but it doesn’t calculate anything either. It’s just stalls after the initial energy dump and never runs, which seems odd.
Is there anything else I might try?
One other note is that I am seeing “WARNING: Inconsistent image flags (…/domain.cpp:678)” I believe this is because the graphene in my system is periodic and I have bonds specified that span the boundaries. So this may or may not be related.
Finally my lammps build is from 29 July 2014.
Thanks!
Dave
hi dave,
Hi Lammps Users,
I am running an OPLS-AA simulation of a hydrocarbon with graphene. I have
run a minimization step and NVE at ~300K for about 10K timesteps and the
system runs with no complaints but when I try to switch over to NPT the
system gives me an "Out of range atoms - cannot compute PPPM" error. This
seems to be a pretty common error and I have tried the suggested fixes,
specifically setting neigh_modify to delay 0 every 1 check yes and
decreasing the time and that doesn't seem to work.
does the error happen immediately or after some time steps? it would
be helpful to at least see some thermo output or better an example
input.
if it continues for some steps, try visualizing and see, if there is
something strange happening with the structure.
if you run with constant volume and have a periodic system, you may
just force the system into a meta-stable state, that it can leave when
you allow the box to vary.
I have also tried setting the initial pressure to something closer to the
final pressure from the NVE step. This does not give an error but it doesn't
calculate anything either. It's just stalls after the initial energy dump
and never runs, which seems odd.
it may be a different manifestation of the same issue. the out of
range error happens when either the atoms are indeed lost, but also
when your forces become too large and you get NaNs in the kspace
calculation. whatever you set as pressure for the NPT command is not
very relevant. if you don't want to do a pressure ramp, just set it to
the desired target pressure. what *does* matter is the length of the
time constant. it should not be too small and if you are far from
equilibrium, you may also set a substantial drag value, to dampen too
large box fluctuations. graphene is quite stiff after all. 
Is there anything else I might try?
difficult to say with so little definite information.
One other note is that I am seeing "WARNING: Inconsistent image flags
(../domain.cpp:678)" I believe this is because the graphene in my system is
periodic and I have bonds specified that span the boundaries. So this may or
may not be related.
no. if those bonds span the correct atom pairs it should work fine and
the warning can be ignored. it has to appear for your setup.
axel.
This error happens b/c the PPPM stencil for allocating charge
to the PPPM mesh extends too far for a processor to
know about. Typically it is b/c an atom is too far outside
a proc’s sub-domain. What is your skin distance, cutoff,
and PPPM stencil size? Can you post a data file and script
that starts from the offending timestep and gives the error?
Steve
This error happens b/c the PPPM stencil for allocating charge
to the PPPM mesh extends too far for a processor to
know about. Typically it is b/c an atom is too far outside
a proc's sub-domain. What is your skin distance, cutoff,
steve,
i have to disagree on this. from the many cases that we have seen on
this list, i would say the majority were cases when an atom position
had become NaN due to invalid forces as a consequence of some
numerical issue during or after the FFTs in the PPPM calculation. it
may be warranted to see, if this check is at a time critical location,
otherwise it might be beneficial to insert a test using isfinite() or
isnan() and flag those separately.
axel.