Implementing script to generate Bayly's preferred AM1-BCC charges

[jchodera]

This is a WIP to use a script to implement Christopher Bayly's preferred scheme of a multiconformer expansion with Omega followed by AM1-BCC charging using AM1BCCSym.

[jchodera]

(Not ready to merge yet.)

[davidlmobley]

Sorry, a “WIP”?

David Mobley
dmobley@gmail.com
949-385-2436

On Thu, Oct 30, 2014 at 3:54 PM, John Chodera notifications@github.com
wrote:

This is a WIP to use a script to implement Christopher Bayly's preferred scheme of a multiconformer expansion with Omega followed by AM1-BCC charging using AM1BCCSym.
You can merge this Pull Request by running:
git pull https://github.com/jchodera/FreeSolv improve-am1bcc
Or you can view, comment on it, or merge it online at:
#11
-- Commit Summary --

• Removed immutable PDF of v0.31 docs, since these have been moved to mutable README.md.
  -- File Changes --
  D v0.31_docs.pdf (0)
  -- Patch Links --
  https://github.com/choderalab/FreeSolv/pull/11.patch
  https://github.com/choderalab/FreeSolv/pull/11.diff

  Reply to this email directly or view it on GitHub:
  Implementing script to generate Bayly's preferred AM1-BCC charges #11

[kyleabeauchamp]

So what's the plan in terms of avoiding code duplication between gaff2xml and the current repo? E.g.

https://github.com/choderalab/gaff2xml/blob/master/gaff2xml/openeye.py

[kyleabeauchamp]

I agree that the stuff in gaff2xml is incomplete, but I think it's useful for us to try to avoid going back to the days where we had 10 copies of each code blurb and zero tests.

[jchodera]

For the short term, the plan is to make sure that FreeSolv contains all the code for generating the derived data from its primary data (excluding things we have no control over, like OpenEye tools, etc.).

This is because the primary goal is to make sure FreeSolv has a fully self-documented, fully reproducible scheme for explaining the origin of every piece of derived data, and ensuring that all derived files are produced uniformly.

Once gaff2xml is stable, we can eliminate the duplicate code and use that. But I don't think that introducing it as a dependency doesn't make sense right now. It's OK if that means that the FreeSolv scripts and the gaff2xml scripts get out of sync, since they have different requirements and different pressures on them for now. We will eventually want to use gaff2xml once Best Practices have been standardized.

The primary form of tests will be ensuring that we can get the same computed free energies with the multiple codes for which downstream files are produced (gromacs, OpenMM, AMBER). This is actually going to be a pretty strict test, though we'll have to automate it through a scheme other than travis.

[davidlmobley]

I agree with all this.

Though, on the last part - reproducibility of computed free energies across codes - I should mention that Julien Michel and I are working on a “reproducibility” project right now involving several codes (GROMACS, Sire (OpenMM-based), and AMBER) with the thought of bringing CHARMM on board also (Benoit Roux has signed on). We are starting with some density calculations and relative hydration free energies, but the plan is to extend to binding affinities as well. So if you’re thinking of reproducibilities across codes we should talk and/or combine efforts.

[jchodera]

This sounds great!

We essentially have to test reproducibility of either computed energies or computed hydration free energies between codes, since there is no other way to test that we have produced the correct output. If you already have a way to automate the testing of inputs for multiple codes to make sure they yield the same computed properties, that would greatly simplify this.

[davidlmobley]

Just to make sure I’m clear - what do you mean by “produced the correct output”? 

Julien has been working on a preparation tool which handles preparing inputs (topologies and coordinates, essentially) for free energy calculations in the different packages I mentioned. In theory these should be able to yield the same free energies and other properties, so that’s what we plan to test. 

David

David Mobley
dmobley@gmail.com
949-385-2436

On Thu, Oct 30, 2014 at 4:32 PM, John Chodera notifications@github.com
wrote:

This sounds great!

We essentially have to test reproducibility of either computed energies or computed hydration free energies between codes, since there is no other way to test that we have produced the correct output. If you already have a way to automate the testing of inputs for multiple codes to make sure they yield the same computed properties, that would greatly simplify this.

Reply to this email directly or view it on GitHub:
#11 (comment)

[davidlmobley]

So, er, still figuring out GitHub here - it gives me an option to merge this pull request, but if I understand correctly it's not ready to be merged yet?

Thanks.

[jchodera]

I believe this is ready to merge.