how to best save ligand parametrisation

[dprovasi]

I'm working on a large ligand and the parametrisation, which I run with
sage.create_openmm_system(topology) or Interchange.from_smirnoff(force_field=sage, topology=topology) takes a while to complete.
I was wondering what is the best way to save the parametrisation so that it's easier to reinitialise an interchange or a openmm system from it.
I noticed also that after I run the parametrisation once in a given session (I'm working on colab machines for this specific project), subsequent calls to create_openmm_system or from_smirnoff with the same molecule are much faster. Are the parameters saved somewhere?
Thank you for your time

[mattwthompson]

Hi @dprovasi, great questions

There are a few options for serialization

• If you're keeping things in OpenMM world, you can readily serialize and deserialize openmm.System to and from disk: http://docs.openmm.org/development/api-python/generated/openmm.openmm.XmlSerializer.html#openmm.openmm.XmlSerializer.serialize
• Interchange objects can be serialized out to JSON with the .json() method and then loaded back with Interchange.parse_raw. Under the hood this uses Pydantic, with a little bit of custom behavior to handle unit-bearing quantities. (This uses dict representations, so there are probably ways to use other file formats, but we haven't really explored this since it's not been requested.) I've had at least one bug reported recently, so there might still be sharp edges; it'd be worth double-checking results and, if something looks off, please report it to us and I'll try to fix as soon as I can.

The slowest part of parameterization is probably partial charge assignment (for large molecules, everything else is dwarfed by AM1-BCC's roughly cubic scaling with molecule size). Interchange caches the result of charge assignment; roughly speaking, the full calculation is done the first time a molecule is seen by a Python thread and the result is stored, then the second, third, etc. time charges are requested the result is looked up from the cache and returned immediately. This sounds like what you're seeing from the same Jupyter kernel; re-running a cell with either of those method calls in it should be quicker the second time.

Charge caching did lead to a critical-if-esoteric bug that has since been patched - we strongly recommend using version 0.3.18 or newer to avoid this, especially in applications that use multiple threads/processes.