So, I got fed up of tables to define potentials, and I am going to create
the potential changing the source files.
With my (very) little c++ knowledge, I guess that with time and patience I
can get it working without the help of a definite Hitchhacker Guide to
LAMMPS, but I was wondering if there is any effort towards making it. I've
seen a lot of websites/documentation about it, but it looks more like a
pot-pourri than a cohesive guide. I don't know if it can be done thoroughly,
but perhaps some guidelines like:
the problem with this kind of tutorial is that the person most
qualified to write something along the lines of what you need is
somebody like you. for more experienced people it is hard to tell
which parts could use more explanation and which less. in the end, the
source code should speak for itself. particularly for simple pairwise
additive potentials, there is not much to it. most of the work is
required for managing the potential parameters. the go-to example is
pair_lj_cut.cpp/.h it has been implemented by almost anybody that is
writing MD code, so there is a lot to compare to. from there on, you
can make your way to lj/cut/opt and/or lj/cut/omp and/or lj/cut/gpu
and/ro lj/cut/cuda.
in the end, the only way to learn a code is to read it. and being able
to read and assess what a code does is a skill that needs practice in
itself and is very difficult to teach. to give a personal example, i -
almost religiously - read through the diffs/commits to the svn/git
repository. this often tell you a lot about what is good and what is
bad. much more than just reading the source, since you have you ask
"why this change?" on top of everything.
a.- Should (LAMMPS best practice wise) I make potentials for cpu if I'm
planning of using it only within GPU computing (either GPU or USER-CUDA)?
everything should start from the CPU version. the GPU and other
versions are usually just derived classes that add or replace part of
the functions.
b.- How can I most easily get my source files to be included "directly" when
I upgrade my LAMMPS version?
if they are in src and do not conflict with any other source file,
they are automatically included when you (re-)compile.
c.- Are there any "most common issues" when doing this? I've read so far
that there was a case of missing the #IFNDEF, if I'm not mistaken.
before just changing things, you need to make sense of things. and if
you understand, logical errors will be rare.
d.- Could there be made/Is there any "template" for two-body interaction, so
it can be changed easily?
lj/cut is the simplest pair styles that implements pretty much all
features. what a specific pair style supports can be set in *_enable
member variables.
I'm sorry if these look like very basic questions, but I think they will be
useful for the newbies on the community.
particularly, if you compile the answers and your own observations
into a suitable "beginner's guide to LAMMPS hacking" document.
ciao,
axel.