Dear Axel Kohlmeyer:
The word in your replay to the mail "Neighbor list warnings show up on
LAMMPS (26 Jan20 2014) but not on LAMMPS (22 Feb 2013)" surprised me! The
word is "in the 2013 version they were likely silently ignored".(Date: Fri,
30 Jan 2015 10:50:05 -0500)
Since ALL my job is done through LAMMPS, I must make sure my simulation is
correct without artifical falsity. From your replay, I know that even though
there are no warrings and errors, the result may be polluted by SOFTWARE's
silent issues.
I want to know whether there is some way to judge whether LAMMPS work as my
wish or not. This is a rough quetion. Would you give some helpful advice
when debug one's LAMMPS scripts.
first of all, LAMMPS as such doesn't care what you wish, it executes
what you tell it to do (that is not always the same) and it will do so
within the limitations of the algorithms and models that have been
implemented, within the numerical accuracy possible by the
implementation and within the errors of the model parameters you feed
it. the latter part is particularly important. MD (and thus LAMMPS)
follows the GI-GO principle (garbage in -> garbage out).
for most codes, potentially problematic conditions and parameters are
*completely* ignored and the program will just produce numbers as
instructed and the authors consider it the responsibility of the user
to verify that reasonable parameters are chosen. LAMMPS tries to be
more helpful and print warnings and errors when potentially
problematic or inconsistent settings and parameters are encountered.
however, there are limitations to that and - more importantly - one
has to know about this. if the person implementing a feature always
uses very reasonable parameters and carefully tested settings, there
is no need to put in warnings and the program will work as expected.
there are certain ways how you can check for the correct behavior, if
choices are outside of the reasonable or unusual conditions happen.
but often people use a feature in unexpected ways, and it is
practically impossible to anticipate what an how many unexpected ways
this would be. this means certain warnings can only be added to the
code, when people encounter problems or inconsistencies in their
simulations. and in addition to that, there has to be a way to
reliably detect such a bad choice. many times, that simply isn't
possible. there are loads of conditions where people make bad choices
and LAMMPS cannot know, because those would be good choices under
different conditions. so much for the mystery of silently ignoring bad
conditions or not. i hope you see, this is not deliberate, but a
consequence of the nature of the problem.
now how to test for correctness of simulations there are a load of
different errors to be considered. you can start with time integration
(there are loads of papers discussing the errors of solving
differential equations through discretizing them (and only to second
order at that). as mentioned before, energy conservation can be a
qualifier, reproducing results from other calculations, sensitivity
tests against parameter choices, comparison of different models or
different implementations. in short, there is next to no certainty,
but you can get close, if you observe and evaluate all your results
critically and validate all settings and choices that determine the
(systematical and statistical) error of your results. this is far to
general and voluminous a topic to discuss here. good books on MD and
statistical mechanics and thermodynamics should have discussions on
that and talking to a knowledgeable experienced person if often
providing a lot of insight. it is all about not simply accepting
results in an unreflected manner. of course, this is independent of
the MD code, though it helps to have some insights into the inner
workings of the code to be aware of potential pitfalls.
HTH,
axel.