OpenMM parsers

[dotsdl]

In line with the overall API proposal, we want to have parsers for each of the major MD engines, and eventually have coverage for all of those in use. Since there are essentially two types of estimators (TI and FEP), each packages needs a parser for:

1. Extracting reduced potentials u_nk from output files (for FEP).
2. Extracting derivatives DHdl from output files (for TI).

This issue is the nexus for discussion for such parsers for the OpenMM package. If you have existing parsing code for this package, comment below and we can begin adapting it into the parsers outlined above in a PR.

[davidlmobley]

I'm not sure that framing this as OpenMM in general is really the right way, as OpenMM doesn't have free energy calculations built into it as I understand it. These have been implemented in a couple of different efforts that I'm aware of -- particularly, Sire and Yank. Relevant people might be @jchodera , @lnaden, @jmichel80, and probably someone else in Julien Michel's group -- @steboss or @ppxasjsm maybe? @andrizzi on the Yank end may also have interest.

[jmichel80]

To add to that, we use a number of tools in the group to do free energy estimation. There is analyse_freenrg written by @chryswoods which does TI, FEP, BAR by reading in sire containers that hold potential energies or gradients (http://siremol.org/pages/apps/analyse_freenrg.html). This has nothing to do with what the OpenMM interface to Sire does.

There is an MBAR/TI variant written by @ppxasjsm that reads in an ascii file (custom format) that contains reduced potentials and gradients.

https://github.com/michellab/Sire/blob/devel/wrapper/python/scripts/analyse_freenrg_mbar.py

These are computed by OpenMM at the moment. The code is essentially an interface to pymbar. Earlier versions were called analyse_freenrg_mbar. We are in the process of merging the two tools so there is a consistent way to do free energy estimation from the data sampled by the various simulation tools within the Sire suite.

[davidlmobley]

@jmichel80 - perhaps your process of merging the two tools could produce parsers to be included here? Basically, alchemlyb IS what you're describing only broader: It's intended as a library and interface to pymbar which will provide "a consistent way of doing free energy estimation from the data sampled by the various simulation tools", but in this case, not just tools within the Sire suite but across all the "standard" free energy codes.

The goal is that, potentially, the community could maintain just a single library for doing this analysis rather than everyone having their own independent tools which are supposed to (but may or may not) be doing the same thing.

[jmichel80]

@davidlmobley yes it would be good if we could load our energies easily into another tool to make sure the same decisions are applied to the raw data. Will keep this in mind, but I'm not convinced we have yet a sufficiently stable file format, and a sufficiently broad user community, for a parser in a third party tools to be useful yet.

[davidlmobley]

@jmichel80 - just to be completely clear, though, this really could just be as simple as maintaining a copy of whatever parsers you do already have on here, with minor tweaks so that they output things in the way alchemlyb requires.

[jmichel80]

Ah yes ok said that way that sounds easy.

Sent from my iPhone

On 9 Feb 2017, at 16:59, David L. Mobley notifications@github.com wrote:

@jmichel80 - just to be completely clear, though, this really could just be as simple as maintaining a copy of whatever parsers you do already have on here, with minor tweaks so that they output things in the way alchemlyb requires.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dotsdl]

@jmichel80 alchemlyb as a project will try to track changes in each package it maintains parsers for to ensure they keep working, so even if, say, Sire doesn't have a standard format for outputting gradients or potentials quite yet, we can still include parsers for what it is you currently do. We can clearly point out in the docs for the Sire parsers the state of the format, and the parsers can be written to try and do strict checks so they fail loudly when they can't be expected to properly read what they're given.

See my comment on the CHARMM parsers, since the situation might be a bit similar. For us right now I think something is better than nothing, since that gives us something to iterate forward on.

[ppxasjsm]

@jmichel80 and @davidlmobley I suppose the 'parser' we currently have with the somewhat suboptimal fileformat can be incorporated here. I'll try and see what the easiest way to do so would be with minimal effort.