Implement ForceField.create_parmed_structure()

[jchodera]

Our examples can be simplified if we implement Topology.to_openmm() and ForceField.create_parmed_structure().

[andrrizzi]

I think we've already this opened and scheduled for 0.3.0 (see #240).

[j-wags]

Reopening this to keep track of thoughts on create_parmed_structure which was not implemented in #240 (which added Topology.to_openmm()):

John Chodera [10:43] I've quickly checked how the latest parmed release handles conversion from an OpenMM System to a parmed.Structure object and how the + operator works on Structure objects (which represent parameterized systems).

Here is the ParmEd code for how the + operator adds two parmed.Structure objects: https://github.com/ParmEd/ParmEd/blob/master/parmed/structure.py#L3354

For adding nonbonded forces, it looks like it just appends a list of Atom objects, which carry their partial charges and vdW parameters: https://github.com/ParmEd/ParmEd/blob/master/parmed/structure.py#L3374-L3377

Atom properties are here: https://github.com/ParmEd/ParmEd/blob/master/parmed/topologyobjects.py#L239-L427

This would indicate the + operator ignores anything to do with nonbonded treatment and simply pulls partial charges and LJ parameters from the atoms. That means it might also regenerate exceptions/exclusions when exporting. So we might lose a lot of information, like other scale factors applied to 12, 13, 14, 15 interactions

The method that converts from an OpenMM System object to a Structure is here: https://github.com/ParmEd/ParmEd/blob/master/parmed/openmm/topsystem.py#L30 Processing of NonbondedForce is handled here: https://github.com/ParmEd/ParmEd/blob/master/parmed/openmm/topsystem.py#L375

Notably:

• The parmed.Structure object is very AMBER-centric. If AMBER has a representation for this in a prmtop object, it's present, but if AMBER relegates this to an mdin input setting, it won't be there. Other codes have concepts that are also not well-handled by Structure. • Requires exceptions follow the normal AMBER pattern of scale12 = scale13 = 0, but will autodetect scale14 as long as it is a constant applied everywhere. • There cannot be any 1-5 exceptions at all. If they are detected, a warning will be thrown and they will silently be dropped. So we should raise an exception if we have scale15 != 1, and we should likely skip generation of 1-5 exceptions if scale15 = 1 • The NonbondedMethod and all other parameters (PME tolerance, alpha, cutoff, etc.) are all ignored.

https://openforcefieldgroup.slack.com/archives/C8NE3J96U/p1553881413021900

[j-wags]

Concrete steps to closing this issue are:

• Agree on logic for carrying through selected settings from OpenMM systems to Parmed structures
• Identify which configurations can not be converted and when to throw exceptions
• Add a warning system explaining which information is always lost and whether it's expected to significantly change simulation results.

[mattwthompson]

I think we've (once again) moved away from an intent of implementing this feature.