Openff-toolkit: Make simple usage examples for various simulation packages

[davidlmobley]

Once the big RDKit changes are in place, we should make some simple examples of starting from common inputs and taking full systems into various simulation packages, including GROMACS. I've fielded two different requests in the last 24 hours asking how to set up systems for use in GROMACS. It's doable (but will be easier once we get symmetrization issues dealt with more effectively) but we'll want some examples.

[j-wags]

@andrrizzi is currently working on an AMBER-export example. We can check into getting a GROMACS one online as well.

[andrrizzi]

I've basically already implemented both AMBER and GROMACS export in the same ipython notebook.

[j-wags]

Awesome. I'm going to add this to the in-progress column on the project board.

[jchodera]

Are we planning on having create_amber_system() and create_gromacs_system() in our ForceField API in this release, or are we going to drag people through the parmed.Structure route (forcing them to learn a whole new API)?

[andrrizzi]

We have a create_amber_system() in openforcefield.tests.utils, but right now I believe users will have to learn the parmed.Structure API anyway if they want to mix SMIRNOFF with a protein force field.

[andrrizzi]

if they want to mix SMIRNOFF with a protein force field.

And also to export prmtop/inpcrd or top/gro files or similar.

[jchodera]

but right now I believe users will have to learn the parmed.Structure API anyway if they want to mix SMIRNOFF with a protein force field.

Excellent point.

[andrrizzi]

We have a create_amber_system() in openforcefield.tests.utils

Whoops, sorry, I think I misunderstood. We have a function to create an OpenMM system from AMBER files, not to create AMBER files from an OpenMM system. We can absolutely create it. We talked about possible loss of information by ParmEd during the conversion from System to Structure so I guess one advantage of just using ParmEd is that it makes it clearer that we're not directly supporting that feature and directly responsible for fixing eventual bugs (although we can certainly help).

[j-wags]

Our previous functions to write out to AMBER and GROMACS are here.

one advantage of just using ParmEd is that it makes it clearer that we're not directly supporting that feature and directly responsible for fixing eventual bugs

I'm kinda with Andrea about being cautious here. Once something is in our API, we're sort of endorsing its correctness and/or committing to maintain it. That might be a choice that we make, but this is a new area for me, and so I don't know how to weigh the costs/risks.

@jchodera would it be acceptable to leave this out of the initial release? If it ends up being low-risk and high-demand, we could always add it later.

[jchodera]

The main issue here---which @andrrizzi points out---is that users will need to use the ParmEd + operator to merge their systems anyway, so adding create_{amber,gromacs}_system() to the API now wouldn't help anyway. So let's definitely punt on that and focus on create_parmed_structure().

[davidlmobley]

And the other important point here -- which Andrea made but just to reiterate -- is that if people use ParmEd, we can't necessarily prevent them from doing stupid things since ParmEd has its OWN createSystem which they can use the way they want. So, it's best to EXPOSE that part of the process to them so they know they're doing it and we're not responsible for it.

[jchodera]

So, it's best to EXPOSE that part of the process to them so they know they're doing it and we're not responsible for it.

I do think we'll be on the hook to support ParmEd until we can migrate away from it is a primary means for supporting multiple packages.