Our development team is a collaboration between two labs at ASU- the Beckstein lab and Heyden lab. We updated this protocol to meet a need for high-time resolution analysis without producing prohibitively large trajectory files. As a bonus, the protocol allows monitoring a simulation with arbitrary Python code as it runs.
The IMDv2 protocol is currently implemented in ‘fix_imd.cpp’, but this earlier version of the protocol doesn’t include box dimensions, velocities, or force information useful for analysis and monitoring like our new version does.
We have a working implementation of IMDv3 in a LAMMPS fork which we build into a container and run regression tests on against the MDAnalysis client for IMDv3, ensuring data that comes through the socket via IMD exactly aligns with DCD trajectory output and that our new packets work as they are intended.
One principle we’ve adhered to in making our changes is that the original IMDv2 code should be changed as little as possible and that IMDv2 should be the default for users (meaning IMDv3 is opt-in with a keyword argument to the fix) so that existing ‘.in’ files can be run with VMD and IMDv2 exactly as they have been before, and users can opt-in to new functionality for use with MDAnalysis if they choose.
We’d be happy to take ownership over this fix in the future- our regression tests will be configured to build against the develop branch of LAMMPS and alert us to any issues as our code and LAMMPS evolves. For context, we are currently finalizing an MR to add IMDv3 to NAMD 3.1 (if you have dev access, the MR is here) for which we run similar regression/integration tests against a containerized build of the simulation engine in our imdclient repo.
Lastly, thank you Axel for attending our workshop on December 4- we are especially interested to hear your thoughts about integrating this feature into LAMMPS.
Not sure if this is the right place to do this. The vast majority of posts here are from people with LAMMPS questions and the corresponding responses are from a rather small number of people that volunteer their time to help people. You may be better off submitting a pull request directly on GitHub.
Our general approach for such kinds of changes would be to implement the modified features in a separate class, typically derived from the original class, i.e. as fix imd/v3 for example.
That would not be necessary with the implementation path of having a derived or modified copy of the class. The effort is definitely appreciated, though. I have looked at your implementation and can confirm that it appears to be fully backward compatible, so it is well done and it is not necessary to have a separate class/command for your new variant.
That is also much appreciated. Unless you have many new features in your mind, this will be a very small effort. Fix imd hasn’t seen many functional changes since its inception quite some time ago except for the odd bugfix.
There are two main thoughts that went through my head.
Have you had a look at the MolSSI MDI library (also supported in LAMMPS as MDI package)? This includes very similar functionality to your IMDv3 protocol.
By first completing the implementation and already having a tutorial before your changes are accepted into the hosting MD codes, you are making the situation of merging your code more difficult: either your changes have to be accepted “as is”, or any suggestions for changes from the hosting code developers may lead to incompatibilities and breakages. The LAMMPS developers encourage folks to submit early implementations as draft pull requests, so that you can feedback and may produce a better version of modifications.
Point 2. is (unfortunately) a common path and quite often also the code is published somewhere but otherwise not supported and what is even more annoying is when people claim “our feature is available in LAMMPS”, when indeed it is only available in their own fork. Technically speaking, there is no problem in having a modified version, but it must not be called LAMMPS but clearly identifiable as a modified version (e.g. LAMMPS-IMDv3).
I don’t expect any such problems with your modifications that are local and well done, be we had to reject contributions because of excessive external dependencies, lack of support for MPI parallelization and low implementation quality (i.e. bugs and bad programming practices or breakage of existing features), so any big announcements of having the code as part of LAMMPS are sometimes overly optimistic. In the last 5-6 years the LAMMPS developers have invested a lot of manpower in improving code quality and consistency across the implementation (despite most code being written by many different external contributors) and we are thus far more careful with contributed features now than, say, 10 years ago (we are still ironing out some problems inherited from such legacy contributions).
This was something we looked at early on, but we decided to go the route of IMD for a few reasons. First, IMDv2 is already implemented in GROMACS (which is what our lab uses), while afaik MolSSI MDI isn’t already available- having code that was 80% of what we needed in 3 major simulation engines was a major draw factor. Second, IMD is an extremely simple protocol for primarily one-way communication that allows our lab to get a working implementation for the analyses that build on top of it very quickly (and in the future, other people can easily implement it in new places without much time or development experience).
That’s not to say MolSSI MDI in MDAnalysis (or GROMACS and NAMD) wouldn’t be useful, and ultimately I think interoperability is a selling point of MDAnalysis, so this is something that someone could push for in the future if they needed it for their own use.
Apologies for approaching this on the wrong medium and in the wrong order. I’m still happy to be flexible with the implementation of the new protocol and we expected to have to make changes to get this up to the LAMMPS standard, but our hope was that we could be a bit more convincing that this was a good idea to include in the first place with something that fully worked.