Porting potentials

Empirical kernels live in rgpot. eOn does not grow an in-tree NewPot. A kernel that belongs next to LJ, Morse, or the Fortran pots is added in rgpot, then selected from eOn.

Kernel

  1. Add the potential under rgpot (CppCore/rgpot/<Name>/) and link it into the single librgpot SONAME. Fortran kernels use the Fortran 2018 layout already in that tree and keep their symbols hidden.

  2. Expose a C++ face (force / energy) and a small config struct. Neighbour finding goes through rgpot’s vesin cache, not a private pair loop.

  3. Pin a reference energy and force in an rgpot test.

eOn arm

  1. Map a potential token to that type in makePotential (client/Potential.cpp) with makeRgpot or makeRgpotDefault.

  2. Add the token to the parameter schema ([Potential] / the pot’s own section) and to PotType.

  3. If the kernel has a proven Hessian range, specialize eonc::HessianRangeOf as described in Hessian range. A config().cutoff field does not do this. The primary template leaves coloring off, which is the right default for a many-body, water, or message-passing kernel until the range is exact.

  4. Keep subprocess and file engines (VASP, LAMMPS, ASE, AMS, socket NWChem) in eOn. They are not kernels.

Direct NWChem, CPMD, metatomic, and xTB engines stay dlopen plugins behind potential type RGPOT. Non-Windows builds always link that arm. There is no -Dwith_rgpot switch.

EON_POTENTIALS_PATH and [Potential] potentials_path still name directories searched for those engine plugins. They are not a way to register a new empirical kernel.