materialsproject
[WIP] LAMMPS Flows
Summary
This is an effort that picks up from #173 to incorporate workflows to run LAMMPS in atomate2. Quite a bit of the initial code was taken from the atomate2-lammps add-on (here) written by @ml-evs and @gbrunin. The input set generator and templates have been moved to pymatgen.io.lammps, and a concurrent PR has been opened to integrate those into pymatgen. Also tagging in @esoteric-ephemera who helped structure some of the code here, and @davidwaroquiers for their interest in this PR.
- Function to call lammps based on settings provided in the atomate2.yaml config file, including running in parallel with mpi.
- Base Maker that generates inputs, runs lammps, and parses the outputs into a LAMMPS TaskDoc.
- Implemented sets and makers for common MD simulations: NVE/NVT/NPT, and a job to perform geometry minimization under an applied pressure.
- Implemented a flow to melt, then quench, then thermalize a structure, suitable for creating liquids/glasses/general phase transformations.
- Wrote a convertor to parse lammps dump files into ase/pymatgen trajectories (might have to tweak this to match how other workflows do this step)
- Implemented a CustomLammpsMaker that takes in a user written input file (for jobs that aren't a combination of NVT/NPT steps or more complicated lammps simulation) and user specified settings. This maker a port of the lammps implementation in atomate, and I expect this Maker to be the most used by existing LAMMPS users.
- Added mock_lammps and basic tests for the sets, jobs and schemas.
- Added a notebook under tutorials for how to set-up and use the makers.
TODO
- These flows are primarily designed around solids (interfaced through the pymatgen Structure) with forcefields that rely on pair_styles (including MLIPs), and as such all design decisions, units, default values and validation checks are tuned for solids. I'm open to suggestions on how the current implementation can be extended to molecules. (Any changes in this regard will have to make changes to the pymatgen PR as well).
- Dump files (in their entirety) are presently stored as strings in the job store, and are parsed and additionally stored as either an ASE/pymatgen trajectory if specified by the user. This is done to avoid parsing/storing exceedingly large dump files as the heavier trajectory objects, however, it could very well be possible that storing the files as strings also becomes prohibitively expensive (for large classical MD simulations). Any suggestions on how to deal with such problems are appreciated!
- I haven't tested these flows with kokkos/gpu or the other lammps add-ons yet.
@vir-k01 Thank you!
Before I check out the code in more detail, a naive question: I am not an expert user of LAMMPS, but I nevertheless have a question: as far as I know, a python interface to lammps can be compiled. Are there drawbacks of using this interface in contrast to input files?
@JaGeo Yes, that's a very valid question. I personally haven't used the python interface to LAMMPS much, but from what I know of it, it's entirely equivalent to just writing templates since it does not provide actual objects to use (other than the cmd line runner). I'm sure the lammps python interface has its uses, but in the context of this PR though, I think using templated input files offers a lot more flexibility, since anything that's not a simple NVT/NPT MD is difficult to convert into a structured input set. At least this way, the user can prepare their input file using whatever approach they're comfortable with, whether that be the pymatgen interface to lammps, or the native python lammps interface, or the ASE interface, or just directly writing the file out in a text editor; and pipe that input file into the flows here.
@vir-k01 Let us know once you have addressed @gpetretto 's comments. I am happy to help getting this merged as well.