Merging/increasing compatibility with ParmEd

[ctk3b]

@swails, @mrshirts I wanted to revive some of the discussion we'd had about merging and/or increasing compatibility with ParmEd, layout some basic TODOs and get some opinions on several items.

Merge vs. standalone

The options I see are

1. Build everything into ParmEd
2. Create standalone tool built around structure
3. Create standalone tool using InterMol's system/moleculetype
4. Create standalone tool with a different purpose built structure

InterMol's adoption of the moleculetype concept is somewhat elegant and reduces some of the information stored. On the flip-side it also presents an additional layer of complexity and reduces flexibility a little bit.

I personally like option 2, in theory. It would be a nice way to provide a standalone converter and cleanly segregate the maintenance burden while still leveraging all the flexibility features of structure. @swails do you think it's feasible to completely sever the portions of ParmEd that read into or write from a structure?

Conversion testing

I don't think there were really many disagreements on this front. A robust testing infrastructure will make everyone happy and open the door to do more complex comparisons that also involve simulator settings in the future.

Measuring the energies reported by the individual simulators is the ultimate test for conversions. Doing this entirely on Travis may be tricky due to licensing so this might have to happen on our own Jenkins server.

I took a stab at re-organizing the current InterMol tests to properly leverage the py.test tools https://github.com/ctk3b/validate It's fairly sleek so far but it's built around a ParmEd structure centric converter.

Force objects

I think we all agreed that we want to move towards a flexible way to define new mathematical forms and the associated units and that we should be canonicalizing force objects. I believe InterMol has a nice prototype for both of these functionalities that we can build off of to create a more polished and robust set of autogenerated force objects with a consistent API.

In InterMol, new forces can be fairly readily created by making an addition here but the full process is somewhat brittle and needs to be automated and cleaned up a bit. Perhaps a .yml file would make for simpler user entry?

Big picture TODOs:

• [ ] Decide on merge strategy
  • [ ] Which data structure do we build this around?
  • [ ] Do we split into 2 separate packages?
• [ ] Testing
  • [ ] Refined testing framework
  • [ ] Setup CI with all simulators installed
• [ ] Tackle forces, pending merge strategy decision
  • [ ] Define force objects API
  • [ ] Refine user entry mechanism
  • [ ] Cleanup autogeneration code
  • [ ] Implement canonicalization functions

[hainm]

+1 for option 2. (I end up rewriting pdb4amber that use ParmEd's Structure)

[swails]

One plug for building around Structure is that anything that it opens up OpenMM as an available simulation engine (as well as the nglview webgl-based visualization toolkit). But Structure is better for some things and worse for others compared to InterMol's data structures. It's easier to do modifications (like add a dummy atoms, shuffle around atom ordering, etc.) since it stores every atom.

On the other hand, InterMol is probably quite a bit faster for big systems, since it doesn't store the redundant terms. Which is fine for conversions, but makes some of the things I wanted to do with ParmEd more difficult just from a bookkeeping perspective.