Updating the Potentials class

[srmnitc]

As discussed in the pyiron meeting on 02.05.2022, I am planning to update the Potentials class.

The motivation from my side was this, and I need to ability to store more than one potential to hdf. However, this might be a good time to suggest more changes or features you have in mind so that we can incorporate these suggestions.

[pmrv]

Would probably a good time to move away from GenericParameters. ;)

[sudarsan-surendralal]

I'd like to bring up a couple of issues which we couldn't fully solve related to potentials for DFT which could merit the development of a more flexible generic potential class:

1. https://github.com/pyiron/pyiron_atomistics/issues/37
2. https://github.com/pyiron/pyiron_atomistics/issues/126

[pmrv]

Is there any reason VASP and Lammps potentials should share code? Except for some basic logic of locating files from the resources there seems to be no overlap in functionality to me.

[sudarsan-surendralal]

Is there any reason VASP and Lammps potentials should share code? Except for some basic logic of locating files from the resources there seems to be no overlap in functionality to me.

They don't have to share code, but the potential class for DFT jobs needs to do more than locating the files. For many applications you have to use different pseudopotentials for different atoms of the same species, modify the individual or overall charge etc. So a flexible potential class will be beneficial.

[pmrv]

I agree, but my impression was that these additional feature will be different between Lammps and Vasp though, so I'm not sure whether a common abstraction will help.