Sorry for my poor describing
(I use red color for my problem)
sorry, but using a red font is not such a good idea.
that makes the text really hard to read with html
formatting enabled, and it doesn't show up for
people using a text-mode mail program.
[...]
if I put ./lmp_linux and ./input(a executable file of Fortran) in the qsub
for setting specific number of processors, for LAMMPS is parallel and
FORTRAN program is serial, but I make a BASH Shell script and it OK with
this method, for example
#!/bin/sh
number=0
while (test $number -lt 1000)
do
./input # run with one processor
/home/xie/lmp/mpich2/bin/mpirun -np 8 ./lmp_linux < in.graphene # run
with 8 processors
number=`expr $number + 1`
echo "$number"
done
echo
ok. that sounds reasonable.
This shell repeatedly read data and run LAMMPS, if at some time one atom
exceed the boundary of the system, the LAMMPS can not read the data from
data file, So I have to enlarge the boundary to insure that all the atom in
the last run will be read in the next run.
correct.
In order to prevent that the rejected atom do not exceed the boundary, I set
the box in z direction very large, when Lammps run with this range and the
error arise "lost atom", So is there a method to solve this problem?
lost atoms can happen for a lot of reasons.
most of the time, this is a result of bad
contacts or bad physics.
since you don't provide any example,
i would have to guess. do you by any
chance use "shrinkwrap" boundary
conditions in z direction?
Yes, I choose the "shrinkwarp" in z direction, but it can be work in one
lammps running, but for me when I deposit 10 atoms in 2000 steps, the work
of LAMMPS end. After using the Fortran porgram change the files for LAMMPS,
it restart again. but my "lost atom" arise at the place that if I use 8
processors to run a system while the boundary of this system is
shrinkwrap is the problem. just use "m" instead of "s".
i had this happen to me a while ago. what happens is
that atoms are first distributed according to domains
based on the original box size from you input, but
then at a later point, the box is adjusted to fit the
min/max of your atom positions. with shrinkwrap
that may be result in a _lot_ of shrinkage, which
will indirectly cause the "lost atoms" error. this
of course only happens in parallel runs. there are
two ways to deal with this. you can enforce using
only one processor in that direction through the
command: processors * * 1
or by choosing "m" boundary conditions, which
is like shrinkwrap, but with a minimum size,
that minimum size definition will avoid the
large shrink. you probably want to use both,
since using only 1 processor in z-direction
should give better parallel performance through
better load balancing (otherwise you may
have some processors with only few atoms
in their domain).
"-20.000000 20.000000 xlo xhi
-20.000000 20.000000 ylo yhi
-900000.0000 900000.0000 zlo zhi"
this error arise with lost 1/3 atoms in the system.
yup. exactly.
I am a little bit crazy to this work,
I should try to study C/C++ and
adding code in LAMMPS itself.
as a person that learned programming in
fortran long before c and c++, i can assure
you, that LAMMPS is written in a very
readable style. the biggest problem is
to get into the "lammps programming
mind", the difference in the programming
language is rather minor.
cheers and good luck,
axel.