6.3(?) features

[peastman]

With 6.2 almost done, I'm starting to work on features for the next release. We discussed this in the OpenMM meeting a couple of weeks ago, and the feature that came out as the top priority is triclinic boxes. But since not everyone was at the meeting, I'd like to also open the discussion here. What do you see as being the highest priority features you would most like to see in the next release?

[leeping]

We talked about a CustomManyParticleGBForce that would allow reactive angle and dihedral potentials to be specified (i.e. those that depend on bond order). It would be good to at least discuss how crazy this would be.

[jchodera]

Some previously-discussed features that would be very useful for us:

_Deterministic energy computation._ AMBER already has this. It would be very helpful for the computed potential energies to be deterministic.

_Arbitrary spacegroup PME._ This would be very useful for simulating proteins in their crystallographic environments, as well as small molecule crystal simulations.

I'll survey the group to see what other features may be useful.

[VijayPande]

I agree. Peter is working on #2 and #1 should be “easy”, so we have to put it in as an option.

Thanks, Vijay

Sent from my Phone. Sorry for the brevity or unusual tone.

On Dec 2, 2014, at 9:51 AM, John Chodera notifications@github.com wrote:

Some previously-discussed features that would be very useful for us:

Deterministic energy computation. AMBER already has this. It would be very helpful for the computed potential energies to be deterministic.

Arbitrary spacegroup PME. This would be very useful for simulating proteins in their crystallographic environments, as well as small molecule crystal simulations.

I'll survey the group to see what other features may be useful.

— Reply to this email directly or view it on GitHub https://github.com/pandegroup/openmm/issues/745#issuecomment-65273019.

[jchodera]

_Improved Topology class._ It would be great if we could unify the various Topology classes floating around, or at least ensure that the OpenMM version can be a base class we can all extend.

[kyleabeauchamp]

I think the topology stuff will require more discussion. We dont know exactly what we want yet. On Dec 2, 2014 1:20 PM, "John Chodera" notifications@github.com wrote:

Improved Topology class. It would be great if we could unify the various Topology classes floating around, or at least ensure that the OpenMM version can be a base class we can all extend.

— Reply to this email directly or view it on GitHub https://github.com/pandegroup/openmm/issues/745#issuecomment-65277600.

[jchodera]

I think the topology stuff will require more discussion. We dont know exactly what we want yet.

I suggest we open a new thread about this topic. I think it's clear we need something like this ASAP. We just need to flesh out the details.

[jlmaccal]

I would like to suggest an API for modifying System objects. Currently, one can add Forces and change their parameters, but it is impossible to remove a force or replace one force with another.

The current solutions are to either: (1) serialize/munge xml/deserialize, or (2) create a new system and loop over the forces, copying the ones that you don't want to change. This approach works, but the resulting code can be verbose and a bit hard to read.

It would be nice if there was some sort of SystemTransformer class or function that could eliminate some of the boiler plate and make the intention of the code clearer.

I'm envisioning something like this using the visitor pattern (or alternatively callback functions):

class MyTransformer : public SystemTransformer {
    Force * transformForce(Force * force) {
        // do stuff here
        // we can just return the force if we don't want to change it
        // we can return null if we want to delete it
        // we can create a new force using whatever logic we want and return that instead
        return potentiallyModifiedForce;
    }
};

MyTransfomer t();
System newSystem = t.transform(oldSystem);

The transform method would create a new system and populate it with atoms. Then it would loop over each force, making a copy, and passing it to transformForce. It would then add whatever is returned to the system, finally returning a new system at the end.

I think this would be easy to implement in python (and we could just use callbacks instead). It should also be doable in C++, although it might involve dynamic_casting.

It could also be nice to chain the transformers together through composition.

[jchodera]

I also agree that it would be nice to allow simpler patterns to modify System and Force objects. I know we've discussed adding removeForce() and removeParticle() methods before, but it could be useful to revisit this discussion if it was possible without requiring enormous implementation changes.

[jchodera]

Does the LocalEnergyMinimizer run fully on the GPUs? If not, maybe an all-GPU minimizer would be faster, and might be a neat feature for 6.3?

[peastman]

No. It does force and energy computations on the GPU, but the rest of the algorithm runs on the CPU. Doing everything on the GPU would have the potential to speed it up, assuming it used an equally efficient algorithm. (It currently uses L-BFGS.)

[rmcgibbo]

I had some preliminary work using Nesterov's accelerated gradient descent, which can run on the GPU as a custom force.

[jchodera]

We can probably close this issue, since 6.3 is in beta.

Feature ideas that didn't make it into 6.3 can be created as separate issues and discussed separately.