Why is there distinction between `hdf` and `self._hdf`?

[samwaseda]

https://github.com/pyiron/pyiron_atomistics/blob/212ecf7665bbb0b80f92ebbbe196df5602e3edbd/pyiron_atomistics/lammps/base.py#L976-L988

While to_hdf requires the HDF variable, atomistics jobs use the private variable self._hdf within to_hdf. Is there a particular reason that the function argument hdf should not be used?

[pmrv]

Imo downstream code should use the project_hdf5 attribute consistently, so feel free to change it here.

[samwaseda]

But shouldn't we always use the hdf that's inserted as the function argument in to_hdf? I don't really see why hdf and self.project_hdf5 should coexist.

[jan-janssen]

The idea of the hdf parameter was to simplify the storage of multiple jobs in a single HDF5 file, but this was never completely implemented.

[samwaseda]

ok maybe we can talk about it during the pyiron meeting.

[pmrv]

But shouldn't we always use the hdf that's inserted as the function argument in to_hdf? I don't really see why hdf and self.project_hdf5 should coexist.

I had written very sparingly about how the to_hdf is supposed to behave here. In my head canon the hdf parameter always takes precedence and project_hdf5 is the fallback if it is not given. For the job classes the super().to_hdf(hdf=hdf) is supposed to set the given hdf to project_hdf5 so which the methods afterwards use, doesn't matter. I can see for readability it might be nicer to always explicitly pass it.