I have several pair_styles I would like to contribute which share the
same code (at least 300 lines).
Time permitting, I may also contribute a dihedral_style and an
improper style which share a great deal of code (about 1000 lines).
I would like to contribute these styles to LAMMPS. My question is:
Should I make an effort to put the common elements of these classes in
separate source files (using inheritance when possible)? If so, would
I need to set it up as a library with a separate makefile?
based on my personal experience. i would recommend to use
inheritance only if, the derived style adds systematically functionality
to the previous one. there is currently *so* much redundancy in
the various styles in LAMMPS, a little more doesn't hurt. if we
want to get rid of that, we will have to pull it out at the core,
which is not trivial, since it also has to be done in way that doesn't
impact performance.
to give an example, in the first generation of the USER-CG-CMM
package, i tried to maximize code re-use but the consequence was
that the resulting code was near unmaintainable, and for the next
generation i unbundled it, but also restricted the features to be used
(these days, there is little benefit to multi-cutoff r-RESPA and
it is a major PITA to tweak it to give correct results). there still is
some code sharing, but that is very limited and using an include
file with a separate namespace. this is mainly to keep constants
consistent across multiple modules.
in case you have a lot of utility code that is shared between
multiple classes, it might be worth looking into putting all of
that into a separate class and then use multiple inheritance.
this is what i am using in the USER-OMP package to augment
pair styles with special, thread compatible versions of APIs
that are otherwise provided by the base interface class
(e.g. pair). in this case it is very important to avoid namespace
clashes and avoid "circular" inheritance. check out
src/USER-OMP/thr_omp.h
Or should I simply have independent styles with redundant code?
(I'd prefer to do this in a way which increases the likelihood that
some of this code may eventually be accepted and distributed with
LAMMPS.)
if the code is clean and well documented, it doesn't make a
difference, although it is usually easier to write clean code
with separate copies and more work to maintain it.
so you have to pick your poison. the barrier to get stuff
added to USER-MISC is (deliberately) low.
of course the final word is always with steve,
the LAMMPS BDFL.
cheers,
axel.