pyiron_atomistics
pyiron_atomistics copied to clipboard
pyiron
LAMMPS job scripts require a date attached to them
LAMMPS job scripts require a date attached to them in the filename; this is problematic for users trying to configure their own executables.
The resolution: We agreed to purge the code supporting old versions of lammps (<2016 is 7 years ago) and put in a fail message that clearly states that parsing/running the stuff is unsupported, or at least document it somewhere.
### Tasks
- [ ] Purge the code that supports versions older than 2016
- [ ] (website) Document the fact that we only support LAMMPS>v2016
- [ ] raise an error when it tries to read stuff from those old versions
When calling the lammps executable, its release date is always printed to the command line. Can't we use this to check the version?
When calling the lammps executable, its release date is always printed to the command line. Can't we use this to check the version?
The difficulty I see is that we would have to execute the LAMMPS command. Depending how the run_lammps_*.sh script is written - maybe it uses srun - this is not possible on the login node. So I am not sure how easy it is to leverage the version number of the executable.
When calling the lammps executable, its release date is always printed to the command line. Can't we use this to check the version?
The difficulty I see is that we would have to execute the LAMMPS command. Depending how the
run_lammps_*.shscript is written - maybe it usessrun- this is not possible on the login node. So I am not sure how easy it is to leverage the version number of the executable.
In addition, this is even worse when submitting to a remote HPC, where both versions might differ! However, I would really like to parse the real version of the executable in all cases ;) This version would then also be available for the post processing.
In addition, this is even worse when submitting to a remote HPC, where both versions might differ! However, I would really like to parse the real version of the executable in all cases ;) This version would then also be available for the post processing.
We could do something like this as part of the installation tests. These should basically be consistency checks, if pyiron is configured correctly. I started with a first implementation in https://github.com/pyiron/pyiron_base/pull/1131 .