materialsproject
[WIP] Better input set generator and sets for io.lammps
Summary
This PR is part of an effort to include workflows for running LAMMPS via atomate2. A concurrent PR will be opened in atomate2 that has the flows, while this PR aims to update the input set generators to match the inputs required there. These changes are based on initial work here: https://github.com/Matgenix/atomate2-lammps done by @ml-evs and @gbrunin. Also tagging in @esoteric-ephemera who helped structure the code in this PR, and @davidwaroquiers. Major changes:
- Updated templates for running NVT/NPT/Minimization jobs with the upcoming flows in atomate2.
- Added in a data class to validate commonly utilized settings (based on the updated templates)
- The new input set generator is written (to the best of my ability) to provide input settings consistent with classical MD run through other codes on solids (matched defaults to ASE MD)
Marked this as a WIP as there might be further updates here dependent on the updates made in the concurrent atomate2 PR.
TODO:
- Add tests
- I've made most of the design decisions here assuming these sets will be used with solids through the Structure object, but one could also argue including support for Molecules. I'm looking for suggestions on how that can be incorporated without varying too much of the logic (ex : for the default inputs, atom styles, force field parameters)
- I'm also looking for suggestions on how to best check/validate user specified force field parameters, which is difficult to do considering the numerous force field formats that exist out there. The existing ForceField object in io.lammps.data is not very intuitive to set-up for a user and does not support lammps integrated MLIPs yet.
@vir-k01 any news about this PR ? Can we provide some help or would you like us to take this on if needed on your side and possible on our side ?
@davidwaroquiers apologies for slacking off on this. After a bit of experimentation, I've added a LammpsData.from_molecule method and added different defaults as per what @gbrunin suggested. Tbh although this supports using molecules, a better way would be for the user to first make the Topology and ForceField objects as they've been currently implemented and use the LammpsData.from_ff_and_topologies method instead. This would preserve information about bonding. I suppose this shouldn't be an issue though for force fields that do not rely on such info.
@mkhorton and @shyuep when you get a chance, would you be able to review this PR? We'd need a new pymatgen release to get @vir-k01's LAMMPS workflows tested on the atomate2 side. Thanks!
@vir-k01's addressed the earlier review comments from community members
