Repository navigation
Gromacs and Lammps and CP2K support #312
Description
I just learned that in the group of Titus they are also working on PathSampling schemes and they seem to have a useable Python interface for Gromaces 5.1 which will be available soon.
Also they have a wrapper for CP2K.
Lammps apparently has a Python interface to access it directly.
Sosupporting all of these platforms should be almost as easy as supporting OpenMM. That should increase our audience a lot.
Activity
franknoe commentedon Sep 18, 2015
+1 for Gromacs support - that would be a gamechanger. Lammps would be
useful for people like Chris Dellago, but I wonder if it's necessary for
us to implement that and have it in the core package or if we can
provide a general plugin mechanism that allows any simulation package to
be included after wrapping it in an appropriate interface. That could be
done dynamically, i.e. after a OPS object has been created.
Am 18/09/15 um 16:54 schrieb Jan-Hendrik Prinz:
Prof. Dr. Frank Noe
Head of Computational Molecular Biology group
Freie Universitaet Berlin
Phone: (+49) (0)30 838 75354
Web: research.franknoe.de
Mail: Arnimallee 6, 14195 Berlin, Germany
jchodera commentedon Sep 18, 2015
Is the lack of gromacs support really such a problem that it would be a "game changer" to add it? Gromacs input is currently supported through OpenMM. Is it just the need to get super performance on CPU clusters?
I would love to see if there is a way to join forces after OPS 1.0 is out.
franknoe commentedon Sep 18, 2015
It's not necessarily a problem, but Gromacs has a huge community, and
most of these folks are not willing to switch to another simulation
engine, so it would increase our impact by inviting this community to
use OPS. It's a general comment and not related to any specific release.
Am 18/09/15 um 17:15 schrieb John Chodera:
Prof. Dr. Frank Noe
Head of Computational Molecular Biology group
Freie Universitaet Berlin
Phone: (+49) (0)30 838 75354
Web: research.franknoe.de
Mail: Arnimallee 6, 14195 Berlin, Germany
jchodera commentedon Sep 18, 2015
Agreed. I was just wondering if there was a technical impediment that kept people from running what they needed, but this sounds more like a social issue.
franknoe commentedon Sep 18, 2015
I think there are two major driving forces: (1) Habits - most people
have their scripts and environment built around one system and you need
a driving force to drag people over the energy barrier of changing that.
(2) Speed. OpenMM is faster than Gromacs on Multi-GPU machines, but on
machines with 0 or 1 GPUs Gromacs is faster or equal. At this point only
the minority of groups have Multi-GPU machines. That will change in the
future, but it will take a while.
Anyway, one has to balance development and maintainance cost with
potential gain of supporting a MD engine. For Gromacs there's a big
gain. But there's a huge number of MD packages, and it clearly makes no
sense of including many of them in an OPS core package, because this
would be too hard to maintain. Many of these have moving targets, such
that accessing them could be depending on their respective version, and
then maintainance becomes a nightmare. That's why I would suggest that
the OPS core could have a dynamical mechanism for adding an MD package,
such as
ops_obj.add_simulation_engine(gromacs_engine)(perhapsthat's already possible). That way you could have generic support for
anything someone is willing to write a wrapper for, without having us to
support that wrapper.
Am 18/09/15 um 17:24 schrieb John Chodera:
Prof. Dr. Frank Noe
Head of Computational Molecular Biology group
Freie Universitaet Berlin
Phone: (+49) (0)30 838 75354
Web: research.franknoe.de
Mail: Arnimallee 6, 14195 Berlin, Germany
dwhswenson commentedon Sep 18, 2015
(Forgive terseness -- I'm writing this from my phone in an airport, not to mention the very little sleep I got last night)
First, OPS _is_ designed to handle multiple engines, with interfaces developed by contributors. Other engines would be supported through the same mechanisms as the core engines; we just choose to include some in core because we are willing to support them.
No registration process is needed. Instead, we do (to within some discussion of whether there are arguments other than the option dictionary):
That engine can be used the same as an OpenMMEngine. The implementer just needs to inherit from our class and implement something like 5 functions. Importantly, all features of OPS (arbitrary path ensembles) are available. Not sure how that would work if mixing with Titus's work.
We're still evolving the exact interface for that, but the basic approach was implemented in #48.
Gromacs, to my knowledge, doesn't have a direct Python API the way OpenMM and LAMMPS do. Therefore, I began developing a general way to use any external engine. See #144.
We decided that version 1.0 only needed OpenMM (and toy engine) support; everything else could come later. But to me, one of our goals is to completely decouple path sampling as a tool for studying time series data, from the way the time series is generated. (No reason you couldn't use OPS for rare events in systems biology, or for economic modeling -- the toolkit remains independent of the underlying differential equations.)
Also note discussions in, e.g., #311 about what this means for our snapshot definitions. I think we're still figuring that part out.
Anyway, I agree with the points @franknoe makes, but I think we've set that as second priority after competing v1.0.
jchodera commentedon Sep 19, 2015
Is the general way to use external engines ready to use? If so, perhaps there are enough gromacs experts in Frank's group to develop and test that independently? This way, it would not distract your or JHP's time from 1.0 goals while still providing some tests as to whether the general interface has everything needed for connecting other codes?
franknoe commentedon Sep 19, 2015
We can look into this. I guess you should go ahead with your release
independent of this point
Am 19/09/15 um 11:29 schrieb John Chodera:
Prof. Dr. Frank Noe
Head of Computational Molecular Biology group
Freie Universitaet Berlin
Phone: (+49) (0)30 838 75354
Web: research.franknoe.de
Mail: Arnimallee 6, 14195 Berlin, Germany
dwhswenson commentedon Sep 20, 2015
A couple thoughts on what is needed for Gromacs support: we'd put a lot of thought into this (generic engine support was driven by me wanting to eventually support Gromacs in particular), so let me summarize what I recall of that.
There are three ways we could support external engines (Gromacs or others).
DynamicsEnginesubclass. (This is how we do OpenMM and my ToyDynamics, and how we will do LAMMPS.)In order of preference, that's 1, then 3, then 2.
The challenge in in the variable path length implementation: we need to stop a trajectory once some condition is met. This is a major efficiency point for methods like TIS. And that brings us to "direct control" vs. "indirect control." By "direct control," I mean that we can say to the engine "run the trajectory until the next saved frame" without the overhead of restarting an entire calculation. That's option 1 above. Codes with Python APIs, like OpenMM and LAMMPS, can almost always do this. To my knowledge, there exists no such direct control mechanism in Gromacs.
The alternative is "indirect control," which reads in the trajectory being generated by the engine (running as a separate process) and then kills the engine's process when the stopping point is reached. That's been the approach used before by Tsjerk Wassenaar while in @bolhuis's group, and I assume that's what Titus is doing. Other people's approaches are typically tied to very specific stopping criteria, which may make it harder to adapt them into OPS. But PR #144 will provide a generic API for indirect control.
Both 2 and 3 above are examples of indirect control, but the question is how to manage storage. In 2, we take the easier implementation, but at the cost of doubling storage (we use both the engine's native storage, as well as OPS's internal storage). In 3, we have to change the storage so that OPS knows to read in the external trajectory files, instead of looking for the positions/momenta in our own storage. This is something that @jhprinz and I have discussed several times, probably mostly in person since I can't find GitHub issues on it. Storage is JHP's territory, so he can give you an idea how hard it would be to do this.
To @jchodera's question of how close external engines are to ready: I think that #144 is actually very close to working. If I recall correctly, I used a little C program that did
printf("0.0\n")per "frame", with variable sleep times between frames, so we could check cases where the dynamics ran faster than the Python checks, and where the dynamics ran slower. So far, I've only checked it withLengthEnsembles, although in principle the nature of the ensemble being checked shouldn't matter.The main issue is that we'll need to test how it behaves with certain edge cases (see discussion in that PR). In particular, we need to make sure that our Gromacs file reader behaves correctly if the file is read while it is also being written. If MDTraj handles that cleanly, then there's no reason to use anything else.
All that seems to work so far, with the caveat that I think I've only checked it on a Mac (although I think everything I did was only dependent on POSIX). So I think the main of it works, it just needs a lot more thorough testing.
See also: start to some documentation on adding to engines; part of the external engine PR: https://github.com/dwhswenson/openpathsampling/blob/external_engine/docs/dynamics_engines_api.md
Marcello-Sega commentedon Oct 11, 2017
Dear all,
I see this thread is pretty old, but I wonder if there have been step forward towards using gromacs as an external engine. Recently Oliver Beckstein has published a python wrapper for the gromacs system calls that might be useful to this end... I would be interested in having OPS driving a gromacs-based engine, maybe I could provide some help if there is interest from the OPS community in this.
dwhswenson commentedon Oct 11, 2017
@Marcello-Sega : Gromacs support is mostly done, but delayed due to too-many-tasks-not-enough-time. I did a proof-of-principle that it works, benchmarked to show that our overhead is negligible, including trying it in a computing environment where it was using 2 GPUs and 16 CPU cores for one trajectory (actually, I think I gave it 4 GPU/32 CPU, but the system was too small to speed up at that point!)
So far, I can run trajectories and use our arbitrary stop criteria to stop them. To get it to work with the path sampling code, I need to adjust some stuff about the file naming decisions I originally made. Unfortunately, I'm pretty swamped with other responsibilities for now. But Gromacs support is the number one request we're getting from (potential) users, so I plan to finish it as soon as I can.
However, even once it works, the Gromacs engine won't go into the 1.0 release (which should be coming very soon!) These external engines are pretty experimental, and we'd like to try them in a few different computing environments before we make too much fanfare about them. That said, if you'd be willing to beta test it once it is ready, that would be really helpful!
Also, if you're interested in getting familiar with OPS, you should know that OpenMM (which is fully supported) makes it very easy to start from Gromacs input files. Customizing the parameters for the dynamics (i.e., equivalent of Gromacs mdp) can be done with the online script builder tool, and many additional integrators are available via openmmtools. If you're planning to work on a GPU workstation, I would recommend trying that (OpenMM GPU performance is very good).
If you want to play with the Gromacs engine as it stands now, you're also welcome to do that. It is in my fork, in a branch called
gromacs_engine. I haven't made a PR simply because I'm trying to create some better tests (more correctly, I'm trying to get a trr file that is small and creates a certain expected read failure -- I seem to only get that on larger files!) If you do play with that, note that it requires MDTraj 1.9 (specifically, mdtraj/mdtraj#1271 / mdtraj/mdtraj#1294). If you're interested in any of the scripts I used in the benchmarking, I'd be happy to pass them along.EnricoRiccardi commentedon Oct 12, 2018
@Marcello-Sega Since we have been mentioned at the beginning of the post (Titus group), Pyretis is fully supporting Gromacs and Cp2k, via a direct interface and via mdtraj too. We have working towards release number two, where we will probably include LAMMPS too. We are going to present our repository to a Lorentz Center workshop next year (March 2019), if you (or any of you) are interested. please write me a note.