sharing code between force-field styles

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?

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.)

Cheers
Andrew

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. :wink:
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.

Should I make an effort to put the common elements of these classes in
separate source files (using inheritance when possible)?
Or should I simply have independent styles with redundant code?

to the previous one. there is currently *so* much redundancy in
the various styles in LAMMPS, a little more doesn't hurt
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
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. :wink:
so you have to pick your poison.

Thank Axel for your thoughtful answer!

I did not think of using multiple inheritance as you suggested, but it
seems like it might work, especially for sharing code between dihedral
and improper styles.
I may or may not have the stamina to do things in the nice and elegant
way, but I'll try.

of course the final word is always with steve,
the LAMMPS BDFL.

True.

the barrier to get stuff
added to USER-MISC is (deliberately) low.

There's hope.
:slight_smile:

Thanks again.

Andrew

You won't be able to directly inherit a dihedral class from
an improper class or vice versa. Rather than multiple
inheritance I suggest just creating an independent class
with the methods you need, and have both your dihedral
and improper class create an instance of it. It would be fine
in USER-MISC to have a 3rd class file that 2 other ones
use.

Steve

You won't be able to directly inherit a dihedral class from
an improper class or vice versa. Rather than multiple
inheritance I suggest just creating an independent class
with the methods you need, and have both your dihedral
and improper class create an instance of it. It would be fine
in USER-MISC to have a 3rd class file that 2 other ones
use.

For now I'll work on the pair styles, and I'll try to do it in a way
which minimises work for you guys.
I really appreciate both of your replies. Thanks!

Andrew