OpenMM-Colvars Interface

[fhh2626]

Hi,

I would like to bring our OpenMM–Colvars implementation to your attention:

https://github.com/fhh2626/OpenMM-Colvars

This project provides an interface between OpenMM and Colvars and also includes an implementation of NAMD-style FEP calculations.

I would be very interested to hear your thoughts on the project.

Best,
Haohao

[jhenin]

Thank you Haohao! This is a very interesting interface. I am testing it and will post comments in your repo.

[jhenin]

Something that does not fit as an issue in the plugin's repository: the plugin adds a standalone PDB file parser, which would ideally be contributed upstream to the colvarproxy base class. We avoided adding one so far because the PDB format is tricky and un-standardized, so any parser is likely to choke on strange edge cases.

Nevertheless, I think having a default parser would be beneficial, and we can keep overloading it with the back-end's (in practice NAMD and VMD) integrated PDB parsers for robustness.

[HanatoK]

@fhh2626 Hi! I am curious about how to make Colvars compatible with the Monte-Carlo barostat. Colvars does not implement a separate function to "query" the biasing force from methods like ABF without adding a new sample (see #747). Let's say if you run an NANMA(alanine dipeptide) NPT eABF simulation in OpenMM with the Monte-Carlo barostat and this interface for 1000 steps, would you see more than 1000 samples in the .count file?

[fhh2626]

Hi @HanatoK, good point. I thought that the writeback of lambda-ABF and TABF would cause this issue, so I did something to avoid it. I wasn’t aware that the MC barostat can cause the same issue. It seems this needs to be fixed on the Colvars side?

[HanatoK]

It seems this needs to be fixed on the Colvars side?

Yeah. I think so. In PLUMED, a PLMD::Action can have calculate and update. calculate means only calculating the PLUMED forces applied to the MD engine, which should be idempotent, and therefore, does not update internal states like the histogram used in ABF or MetaD. update is used for updating the internal states, writing to files, and other side effects. Then in the MD engine interfaces, PLUMED provides performCalcNoUpdate and update. performCalcNoUpdate calls only calculate functions of the PLUMED actions. These two functions are used in the OpenMM-PLUMED interface:
https://github.com/openmm/openmm-plumed/blob/a3e935bc88ed8771f17f6f4d60588b81789b9c89/openmmapi/src/PlumedForceImpl.cpp#L143-L148

As for the time being, Colvars does not provide such functionality. From the MD engine interface side, Colvars provides only a single calc() function in the colvarmodule, and it would definitely update the internal states like the ABF histogram and extended Lagrangian variables regardless of the step number in the MD engines. The MD engines have no way to just query the biasing forces with a given set of atoms without any other side effects (internal states of biases, file I/O and probably more). In my opinion the overall structure of Colvars should be overhauled.