Discuss OpenMM Upgrade Path

[kyleabeauchamp]

Lots of compatability issues to discuss.

[kyleabeauchamp]

Here's a crazy idea: if we could perform automated testing of all public projects using the new and old core, then it should be pretty safe to upgrade.

[kyleabeauchamp]

Something like:

1. Compare energies and forces
2. Integrate a few steps
3. Compare energies and forces again

[jchodera]

Neat idea!

Start a new issue thread to discuss?

[kyleabeauchamp]

This is a new issue thread, right?

[proteneer]

I don't think that's nearly sufficient. Probably to get @peastman involved
on this thread. Peter, we're trying to decide when it's safe to mix OpenMM
version within a single project for F@H.

On Thu, Sep 4, 2014 at 2:42 PM, John Chodera [email protected]
wrote:

Neat idea!

Start a new issue thread to discuss?

—
Reply to this email directly or view it on GitHub
#58 (comment).

Yutong Zhao
Stanford University

www.proteneer.com | simbios.stanford.edu

[kyleabeauchamp]

The other possibility is to maintain multiple OCores simultaneously, which is how classic FAH works.

[jchodera]

Whoops, sorry!

Maintaining multiple ocores shouldn't be too problematic.

We could rig them to be automatically tested against public projects, as
you suggest. We might even be able to do this on travis if we add a
command line option to simply test and exit rather than try to produce
frames.

[kyleabeauchamp]

I guess I'm leaning towards multiple ocores as well based on my hunch of what will be least painful in the long run.

[proteneer]

My original intention is to support multiple ocores, but leave it up to the
project managers to explicitly determine the set of engines allowed. Right
now, when you make a target, you specify:

[ocore_601_opencl, ocore_601_cuda], etc. You can easily update it later to
say:

[ocore_601_opencl, ocore_601_cuda, ocore_610_cuda]

On Thu, Sep 4, 2014 at 3:10 PM, kyleabeauchamp [email protected]
wrote:

I guess I'm leaning towards multiple ocores as well based on my hunch of
what will be least painful in the long run.

—
Reply to this email directly or view it on GitHub
#58 (comment).

Yutong Zhao
www.proteneer.com

[kyleabeauchamp]

Sweet, looks like we're all on the same page

[jchodera]

Should ocores have tokens too?

[proteneer]

What do you mean?

On Thu, Sep 4, 2014 at 3:16 PM, John Chodera [email protected]
wrote:

Should ocores have tokens too?

—
Reply to this email directly or view it on GitHub
#58 (comment).

Yutong Zhao
www.proteneer.com

[jchodera]

Maybe have a separate repo for ocores to make things easier to manage?

Would each ocore version be in a separate directory or a separate branch?

Travis could be set up to automatically test against all current public
targets as you suggest.

I guess I'm leaning towards multiple ocores as well based on my hunch of
what will be least painful in the long run.

—
Reply to this email directly or view it on GitHub
#58 (comment).

[jchodera]

The way you specify allowed engines right now is text, right? Instead of
using names like ocore_CUDA_601_v20 maybe they should be globally unique
tokens where we can keep detailed annotations about them elsewhere?

Or maybe that is unnecessary.

[proteneer]

Right, it wouldn't be hard to make a list of available engines. But I
prefer to just document the list of available engines properly.

On Thu, Sep 4, 2014 at 3:32 PM, John Chodera [email protected]
wrote:

The way you specify allowed engines right now is text, right? Instead of
using names like ocore_CUDA_601_v20 maybe they should be globally unique
tokens where we can keep detailed annotations about them elsewhere?

Or maybe that is unnecessary.

—
Reply to this email directly or view it on GitHub
#58 (comment).

Yutong Zhao
www.proteneer.com

[peastman]

Peter, we're trying to decide when it's safe to mix OpenMM version within a single project for F@H.

That's kind of a tricky question. In principle, a newer version should always give identical results to the older version unless

• The new version fixes a bug in the old version

or

• The new version has a new bug that wasn't in the old version

If the new version fixed a bug, you probably want the fix. But do you want to combine simulations with and without the bug? That's up to you. As for introducing new bugs, obviously we try to avoid that! But you probably want to give each new release a little time before pushing it out to F@H. That way there's opportunity for new bugs to get discovered.

The one way in which releases are generally not compatible is that checkpoints created by one version cannot be loaded with another version. I don't think F@H uses checkpoints, though, just serialized States? Those should be portable.

[proteneer]

Correct. F@h uses serialized states.

On Thu, Sep 4, 2014 at 5:08 PM, peastman [email protected] wrote:

Peter, we're trying to decide when it's safe to mix OpenMM version within
a single project for F@H.

That's kind of a tricky question. In principle, a newer version should
always give identical results to the older version unless

• The new version fixes a bug in the old version

or

• The new version has a new bug that wasn't in the old version

If the new version fixed a bug, you probably want the fix. But do you want
to combine simulations with and without the bug? That's up to you. As for
introducing new bugs, obviously we try to avoid that! But you probably want
to give each new release a little time before pushing it out to F@H. That
way there's opportunity for new bugs to get discovered.

The one way in which releases are generally not compatible is that
checkpoints created by one version cannot be loaded with another version. I
don't think F@H uses checkpoints, though, just serialized States? Those
should be portable.

—
Reply to this email directly or view it on GitHub
#58 (comment).

Yutong Zhao
www.proteneer.com