Open jan-janssen opened 11 months ago
I was thinking a bit about this today, especially in the light of the discussion by @pmrv around the VASP parser from the morning (well, my morning, your yesterday). Even energy_pot
and energy_tot
are not really going to be truly cross-code, because classical codes have only ionic energy while for DFT codes there is electronic energy. I can see that energy_pot
is equivalent between the two, but it's not immediately clear to me whether energy_tot
for DFT codes should include finite-T electronic energy...
For the sake of this issue I would be happy if just lammps consistently applied terminology -- especially since then we could leverage inheritance to get class LammpsMDOutput(LammpsStaticOutput)
inheritance going. But it might be convenient to discuss the broader implications here as well.
So far it looks to me like the quantity we call energy
is the one that is integral of the forces (i.e. derivative of energy should be the forces). If we stick to this definition, it makes sense to use energy_pot
for LAMMPS, and the free energy including the electronic part for DFT.
Per the meeting discussion, I was supposed to open an issue on getting consistent nomenclature for the output. Since we already started the discussion here I'm just hijacking this one instead.
Now that the output data is centralized in the shared dataclasses, we should think about the following questions:
energy
and energy_pot/energy_tot
between static and MD are extremely closely relatedOutputMolecularDynamics(OutputStatic)
In https://github.com/pyiron/atomistics/pull/123 the LAMMPS output for calc_static() defines the output energy as
energy
. This equals the potential energy calculated by calc_md(). We should address this inconsistency and make sure it is still consistent with the other simulation code interfaces.