[lammps-users] suggestions for documentation

LAMMPS LAMMPS Mailing List Mirror
1

Hi, LAMMPS developers,

Based on my recent experience with LAMMPS, I would like to give you
the following suggestion/comment:

1. It is very nice to have an error & warning messages in the
document. However, I think it is might be nicer if this section also
gives hints to fix the error besides the explanation of error
messages. For example, I recently got the error message "Bond atoms
3499 3500 missing on proc 0 at step 174669". If the link
http://lammps.sandia.gov/doc/communicate.html is given at the end of
the explanation of error message

"Bond atoms %d %d missing on proc %d at step %d One or both of 2 atoms
needed to compute a particular bond are missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away. "

I believe it will help users fix the error quickly without searching
the whole document.

2. According to lammps website, the default setting for command
"communicate" is:

Default:

The default settings are style = single, group = all, cutoff = 0.0,
ghost = no. The cutoff default of 0.0 means that ghost cutoff =
neighbor cutoff = pairwise force cutoff + neighbor skin.

However, there is no keyword "ghost" for command "communicate". I
guess that "ghost=no" should be "vel=no".

3. The example for fix nvt at http://lammps.sandia.gov/doc/fix.html
is given as:

fix 3 all nvt 300.0 300.0 0.01

This would give an error, and should be changed to "fix 3 all nvt temp
300.0 300.0 0.01" according to
http://lammps.sandia.gov/doc/fix_nh.html

Thank you.

Dongsheng

2

I fixed your points 2,3 - thanks

Re: more complete error messages in Section 9.2 and 9.3 of
the manual. There are over 1000 error messages and brief
explanations listed in Section 9. If you (or anyone else)
has time to annotate them more fully, be my guest. I don't
have time to do it. For the example you give, there are many
reasons why you could lose an atom in a bond, which could
involve any of several commands (pair_coeff, bad timestep, overlapping
atoms due to create_atoms or read_data, etc. etc). The communicate
command and its cutoff setting is far down the list, and just
setting the comm cutoff big would be inefficient and mask the
real problem which is almost always a bad user model.

Steve