Dear Steve, Paul and All,
I have been using version 9Jan09 of Lammps without much problems. Thank you for providing a wonderful simulation tool.
My problem started when I downloaded the most recent version of Lammps 3Feb10 last week. I was interested in using several of its new features.
First, Lammps could not read my old molecular data file. It gave an error message of "Expected integer parameter in input script or data file". Then I generated a restart data file from a previous restart file, Lammps
read this file , but it died with error message of "Neighbor list overflow". I suspect that something was not reading correctly.
The data format for atom_style full doesn't seem to change much since 9Jan09.
I have also checked the syntax of the Lammps comments, even commented out the special_bonds comment. But so far nothing works.
I would really appreciate any suggestions of possible causes.
Thank you very much,
Christine
example of comments in the input file
First, Lammps could not read my old molecular data file. It gave an
error message of "Expected integer parameter in input script or data
file".
This is a new error message in LAMMPS that means you have
specified some parameter in your data file as a floating point
number when LAMMPS expects an integer. This could give
unexpected results so LAMMPS is telling you to fix it.
Dihedral coeffs are a common place this occurs.
For a year-old version of LAMMPS, I can't guarantee you
can read those restart files with the current version. The
safer thing to do is run your old restart2data on your old
restart file to generate a data file. Then read that into
the current LAMMPS. If you fix errors like the integer/floating
point issue above, then current LAMMPS should work fine
on your old data. You shouldn't strange neigh_modify settings
unless you needed them before.
Steve
Hi Steve,
Thank you very much for your reply and suggestions. Generating a data file from restart2data is exactly the first thing I tried. It indeed reads my old data,
but then it gave the neighbor list overflow problem.
Interestingly, if I modify the cutoff of the pair function from 20.0A to 17.0A (see below),
pair_style lj/cut/coul/long 20.0 20.0 --> pair_style lj/cut/coul/long 17.0 17.0
then, the new version will run and gave the same result as that of the older version. However, a slightly larger
cutoff of 20A will produce a neighbor overflow for the new version, while the order version runs without any problem.
Any suggestions?
Thanks,
Christine
Steve Plimpton wrote:
Well, 20 Angs is a long cutoff, so it is possible
your neigh list is overflowing the default settings. I can't recall
if any of the defaults changed in the last year vs the older version.
If you look at the neigh stata printed at the end of a run
you should be able to tell if you are close to some of the
limits, e.g. based on neighbors/atom. If the code is telling
you, that you need to boost the default settings, then you do
that, then it is giving reasonable answers, then you are fine.
If the new settings are much larger than they need to be,
e.g. one is 10x larger than the ave # of neighs/atom then
that might indicate something is corrupted in your data
file, e.g. the atoms are way too close together. But you wouldn't
get good thermo output in that case.
Steve
Well, 20 Angs is a long cutoff, so it is possible
your neigh list is overflowing the default settings. I can't recall
if any of the defaults changed in the last year vs the older version.
how about the changes to special_bonds?
i didn't see it use in the quoted input, but
perhaps setting it explicitly to
special_bonds lj/coul 0.0 ....
might make a difference in memory requirements.
this is what i noticed in some of my older inputs.
cheers,
axel.
If you look at the neigh stata printed at the end of a run
you should be able to tell if you are close to some of the
limits, e.g. based on neighbors/atom. If the code is telling
you, that you need to boost the default settings, then you do
that, then it is giving reasonable answers, then you are fine.
[...]