[lammps-users] PPPM for a box with large void

Dear Developers and Users,

Recently I'm trying to study a charged nanostructure system using LAMMPS. To do that, I constructed a large void box and put the desired structure in it. To account for electrostatic interactions within the structure, I used boundary condition p p p. When I used kspace_style ewald 1e-6, everything worked well besides the low speed. However, when I tried kspace_style pppm 1e-6, the computation exited immediately with error "Out of range atoms - cannot compute PPPM". By following former discussions in the mailing-list, I tried to shorten the timestep, tune the precision criteria, and used kspace_modify mesh 15 15 15, but didn't help. So I'm wondering is that because PPPM can only be used for a periodic solid? If yes, what other option can I have within LAMMPS to account for electrostatics in my system? Thanks a lot!

Bo

Dear Developers and Users,

Recently I'm trying to study a charged nanostructure system using
LAMMPS. To do that, I constructed a large void box and put the desired
structure in it. To account for electrostatic interactions within the
structure, I used boundary condition p p p. When I used kspace_style

that is a strange argument. if you have an isolated nanostructure
with coulomb interactions, you _don't_ want periodicity, but you
can actually account for all coulomb interactions explicitly by using
a very long cutoff. how large is your object? in principle you just
need to use a cutoff that is a little bit larger than the largest extent
of your object and you have them covered _exactly_.
non-bonded interactions parallelize very well (unlike k-space).

when using ewald or pppm, you have artificial interactions between
the periodic images of your nano-object that may be undesirable.

ewald 1e-6, everything worked well besides the low speed. However, when
I tried kspace_style pppm 1e-6, the computation exited immediately with
error "Out of range atoms - cannot compute PPPM". By following former
discussions in the mailing-list, I tried to shorten the timestep, tune
the precision criteria, and used kspace_modify mesh 15 15 15, but didn't
help. So I'm wondering is that because PPPM can only be used for a
periodic solid? If yes, what other option can I have within LAMMPS to
account for electrostatics in my system? Thanks a lot!

it is impossible to discuss details of parameters without having
a usable input example made available somewhere that easily(!)
reproduces the issue.

cheers,
    axel.

The only difference between PPPM and Ewald (other than efficiency)
is that PPPM has additional error checks to make sure your atoms
do not move to far relative to a processor's grid, such that the computation
cannot be performed. The out of range error commonly means that
you have a bad model where atoms are moving too far, too fast
and you are not recreating the neighbor list often enough.

If your system is setup correctly you should get the same answer
with Ewald and PPPM.

Steve

Dear all,

I'm sorry but I still got a few more questions about this problem. I agree the model I use might be bad that would lead to unstable structure. However, I noticed the calculation exited at the very first time step:

Step Temp E_pair E_mol TotEng Press
0 28.375334 nan 0 nan nan
ERROR: Out of range atoms - cannot compute PPPM

I used single processor only, so no atoms should fly out of processor boundary, and I enforced frequent recreation of neighborlist:

neighbor 2.0 nsq
neigh_modify delay 0 every 1 check yes

I don't know why the E_pair is nan, I checked the input coordinates, no atoms are sitting on each other, and a run using Ewald summation showed pretty stable trajectory. I tried to think about this but could not come up with an answer, could you please shed some light on the possible reasons? Thanks a lot!

Here is the potential specification part:
kspace_style pppm 1e-4
pair_style hybrid/overlay morse 16.0 coul/long 20.0
pair_coeff 1 3 morse 0.97450084 1.2846 3.08858 4.0
pair_coeff 2 3 morse 0.58162366 1.2566 3.25062 4.0
pair_coeff 1 1 morse 0.075832 1.6752 3.64207 5.0
pair_coeff 3 3 morse 0.085009536 2.2124 4.20311 5.5
pair_coeff 2 2 morse 0.066001579 2.8757 4.31169 5.0
pair_coeff 1 2 morse 0.80737118 0.73124 4.49714 5.5
pair_coeff * * coul/long

Thanks,
Bo

Steve Plimpton wrote:

I don't know why the E_pair is nan, I checked the input coordinates, no
atoms are sitting on each other, and a run using Ewald summation showed
pretty stable trajectory. I tried to think about this but could not come
up with an answer, could you please shed some light on the possible
reasons? Thanks a lot!

nobody can tell w/o having a full set of your input files.
just some input script fragments don't suffice.
most likely your input is marginal for ewald.

axel.

If you have NAN energies, your system is blowing up, so
atoms could go anywhere. LAMMPS can't track them
and gives up.

Steve

Dear Axel,

Below is the input file that I have:

data.bi2te3 (20.5 KB)

that input works fine for me.

axel.

Dear Axel,

So you didn't get the "ERROR: Out of range atoms - cannot compute PPPM" ? May I know which version of LAMMPS you are using?
Because recently I tried to use fix ave/spatial for another problem where I got segmentation fault with June 2010 version, while July 2009 version worked just fine. Thanks for the help!

Bo

Axel Kohlmeyer wrote:

Dear Axel,

So you didn't get the "ERROR: Out of range atoms - cannot compute PPPM" ?

no. the input runs fine.

May I know which version of LAMMPS you are using?

both, the latest fully patched lammps version (off the svn)
and my personal lammps-icms branch (which includes all
of the mainline lammps).

i suggest you try running inputs from the examples directory
to validate the correctness of your compilation.

Because recently I tried to use fix ave/spatial for another problem where I
got segmentation fault with June 2010 version, while July 2009 version
worked just fine. Thanks for the help!

please provide example input files that reproduce the segfault
and people like steve or others can look into it and correct potential
problems or confirm that you have a broken executable.

axel.

Dear Axel,

I tried a new makefile and now it works! Thanks for the help!

Bo

Axel Kohlmeyer wrote: