This issue has been known since the day the rust reimplementation of KCZ was added. I always assumed there was an easy fix, but after trying to fix it, I've realized it's quite difficult to fix.
I'm creating this issue simply to document why it's stuck like this for the time being, so that I hopefully don't waste my time trying to fix it again.
Why LAMMPS' kc-z and kc-full automatically include REBO:
Basically, LAMMPS' potentials do not compose. Sometimes different information must be encoded in different ways and there's nothing you can do about it. Consider:
- In
pair_style hybrid/overlay rebo kolmogorov/crespi/full, REBO must assign the atom types in order to differentiate between Carbon and Hydrogen.
- In
pair_style hybrid/overlay rebo kolmogorov/crespi/z, Kolmogorov/Crespi must assign the atom types, because it uses them as layers. (Hydrogen simply isn't supported).
(theoretically in this case you can try to encode both element type AND layers in atom type, but... I don't see how well this scales to other cases)
One could say, "well, just take a list of potentials and then hardcode the behavior for accepted combinations." This is possible, but (a) good heavens is it tedious, and (b) even then there's several nasty details that will need to be ironed out. For instance, currently, you can write:
potential:
rebo:
omp: true
and this selects the pair_style rebo/omp. But, (a) rebo/omp requires hybrid/overlay/omp, and (b) there are no omp versions of the kolmogorov/crespi potentials, making this ultimately incompatible with kc-z. To fix this, omp might need to be moved to the lammps heading. It's just too much to deal with right now for too little gain.
Why kc-z-new and rebo-new are separate:
Separate is the way they should be, and it's hard for me to picture taking a good thing and ruining it just to be consistent with the LAMMPS potentials.
Quite honestly, code dealing with the KCZ potential has no business worrying about REBO, and this is the solution that best scales towards having more potentials added in the future. For instance, this currently enables the Rust KCZ to be used together with the LAMMPS REBO (e.g. in case we wanted both C(1) continuity in KCZ, and reactivity in REBO).
This issue has been known since the day the rust reimplementation of KCZ was added. I always assumed there was an easy fix, but after trying to fix it, I've realized it's quite difficult to fix.
I'm creating this issue simply to document why it's stuck like this for the time being, so that I hopefully don't waste my time trying to fix it again.
Why LAMMPS'
kc-zandkc-fullautomatically include REBO:Basically, LAMMPS' potentials do not compose. Sometimes different information must be encoded in different ways and there's nothing you can do about it. Consider:
pair_style hybrid/overlay rebo kolmogorov/crespi/full, REBO must assign the atom types in order to differentiate between Carbon and Hydrogen.pair_style hybrid/overlay rebo kolmogorov/crespi/z, Kolmogorov/Crespi must assign the atom types, because it uses them as layers. (Hydrogen simply isn't supported).(theoretically in this case you can try to encode both element type AND layers in atom type, but... I don't see how well this scales to other cases)
One could say, "well, just take a list of potentials and then hardcode the behavior for accepted combinations." This is possible, but (a) good heavens is it tedious, and (b) even then there's several nasty details that will need to be ironed out. For instance, currently, you can write:
and this selects the
pair_style rebo/omp. But, (a)rebo/omprequireshybrid/overlay/omp, and (b) there are noompversions of the kolmogorov/crespi potentials, making this ultimately incompatible withkc-z. To fix this,ompmight need to be moved to thelammpsheading. It's just too much to deal with right now for too little gain.Why
kc-z-newandrebo-neware separate:Separate is the way they should be, and it's hard for me to picture taking a good thing and ruining it just to be consistent with the LAMMPS potentials.
Quite honestly, code dealing with the KCZ potential has no business worrying about REBO, and this is the solution that best scales towards having more potentials added in the future. For instance, this currently enables the Rust KCZ to be used together with the LAMMPS REBO (e.g. in case we wanted both C(1) continuity in KCZ, and reactivity in REBO).