LAMMPS improvements trunk

[mattwthompson]

Description

For now, just seeing how out of date this branch is. This may serve as a trunk for developing smaller LAMMPS-related features.

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 3 lines in your changes missing coverage. Please review.

Project coverage is 93.38%. Comparing base (fa7eb4c) to head (b9840d1).
Report is 21 commits behind head on main.

Additional details and impacted files

[mattwthompson]

Here are the open LAMMPS issues: https://github.com/openforcefield/openff-interchange/issues?q=is%3Aissue+label%3Alammps

The diff looks like it handles #806

#897 might already be done?

#955 could use some TLC; all/mostly good ideas that we haven't gotten to yet

I think #998 is done

This is just what's obviously tracked - anything else we should add @timbernat?

[timbernat]

Regarding the tracked changes:

• Let users specify LAMMPS data file path in MDConfig.write_lammps_input #806 remains hard-coded AFAIK (see here), would be good to parameterize name of LAMMPS datafile
• Lammps constraints #897 seems plausible, though it may be worth revisiting how constraints could be applied vs how they currently are. I'll consult with our collaborating LAMMPS expert and circle back to this...
• Improved LAMMPS support. #955 is a really good one, I have a directory of reference files which show desired formats as written by a LAMMPS expert and their Interchange equivalents. This would be a good place to start for these changes, but I haven't gotten the chance to parse these files in details yet
• LAMMPS atom writer makes assigning unique IDs to chemically-identical molecules impossible #998 is now resolved and closed, yes

Some other changes not mentioned above:

• Support writing to file-like objects #1001 we've already marked this, but it would be very nice to support passing of IO-like objects in place of strings/Paths for LAMMPS files in to_lammps(), particularly to streamline unit testing
• Use LAMMPS's Python API in energy driver #903 I wonder if there are other places which can be rewritten to use the Python API for lammps (I don't know off the top of my head)
• A very low-priority change, but one which I think would be nice to have is explicit specification of LAMMPS units styles beyond just "real". I have my own reference implementation of this which could be modified to used pint (rather than OpenMM) units, if the will to include this is there and a good home for this functionality can be found. I suspect the desire for such a change is dependent on peoples' standard use case for LAMMPS.

I'll add others as I think of them!

[mattwthompson]

I think the data file in write_lammps_input is fine on this branch: https://github.com/openforcefield/openff-interchange/blob/lammps-improvements/openff/interchange/components/mdconfig.py#L364

The Python API seems good (a little funky since it's not written in Python) but there are some ambiguities in whether or not importing it makes this package GPL. It'd be wonderful to use LGPL releases, but I suspect they don't actually want to make those.

Are any of these other changes particularly useful for you sooner than later, and are any of them ones you'd like to tackle?

[timbernat]

#955 and #897 are the most important for my purposes, I'm happy to take the helm on those issues once I circle back to them

[j-wags]

@timbernat - Just checking on your plans/status here. This isn't holding up anyone else's work, I've just seen this on our trello board for a few weeks and want to make sure you have what you'd need to move forward here. Happy to offer guidance/schedule a quick screenshare if that'd help!

[timbernat]

@j-wags Sorry for the long turnaround on this! It has been pushed down my TO-DO stack over the last few weeks as other projects have bubbled up.

It'd be really useful for me to get an update on the status/relevance of some of these items, particularly as there's been a lot of related activity on #1027 (and other places that I'm probably not aware of); I want to make sure I can preferentially make contributions for which there is a) higher demand, and b) lower bandwidth from OpenFF core devs. Also, seems like there were some lingering loose ends with #1013 which were similar (but different) to the LAMMPS ID writer issue I PR'ed earlier, I'd be happy to pitch in there as well, if it's warranted.

I'll be out for part of next week, but can set aside time the week of 09/02 to diff between the current Interchange LAMMPS outputs and the examples I have and lay out exactly where/what changes to constraint handling and bond/angle styles are needed. I'd be happy to set up a meeting if I get stuck there, and in either case, please keep me looped in!