NCMCEngine API

[pgrinaway]

In #44, we talked about various choices of integrator for the NCMCEngine, including GHMC and VV. I think it would be convenient to have an API for deciding which integrator to use. I'm starting this thread to brainstorm that API.

• Perhaps the user can specify a set of CustomIntegrator-syntax strings for the propagation bits
• Or can we actually combine integrators as mixins? I seem to remember Kyle doing something like this, though I'm not sure what actually happened.

[jchodera]

Perhaps the user can specify a set of CustomIntegrator-syntax strings for the propagation bits

It would be hard to engineer something that allows the user to specify a CustomIntegrator-like syntax that also automagically computes the NCMC logP. Instead, it might be easier to have a base NCMCEngine class and subclasses that fill in a switching function that returns new positions and the logP for the switching step.

Alternatively, since we might want to have NCMCEngine variants that do dual-topology relative transformations instead of atom insert/delete transformations, we might have an NCMCIntegrator base class where subclasses do this, and call them VelocityVerletNCMCIntegrator, GHMCNCMCIntegrator, etc.

Or we could just maintain one NCMCEngine class and have a string option 'integration that can select a function implemented in the class, like velocity verlet, GHMC, etc.

[jchodera]

I strongly think we should stick to velocity Verlet for NCMC now. It is very likely the most efficient choice without going to extremely complex integrators that are designed to maximize acceptance rates, e.g. methods that Suri has developed.

The only situation I can think of where we need to get fancier is if we find we run into NaNs very frequently and find GHMC would be a superior choice because its ability to reject NaNs on a per-step basis rather than a per-trajectory basis.

We can still discuss what the API would look like in the meantime, but I think we have many other things to optimize that should take priority.