Switch to using QCElemental or Pint for units

[j-wags]

This would offer nicer serialization support. However, we are tied to OpenMM for system construction for the time being, so we would need interconversion functions between whatever we use internally and simtk units.

[j-wags]

This is an unfortunate choice to get stuck with, but, short of rewriting much of our unit-handling code (and then converting them to simtk anyway units during system creation), there is no way to do this.

[jchodera]

Are the simtk.unit human-readable units compatible with pint or QCElemental human-readable units? If so, we could standardize on that for the SMIRNOFF spec and change what is under the hood later.

One possibility for a future evolution of OpenMM is to switch from simtk.unit to one of those other systems.

[jchodera]

My understanding is that the string representation from pint is identical to the string representation from simtk.unit, so if we standardize on this manner of writing units in the SMIRNOFF XML spec, we can switch to pint / QCElemental in future and not change the XML spec.

[j-wags]

So, this isn't exactly a response to your comments, but one thing I'm thinking about with regard to serialization -- these packages can all write unit-bearing quantities to string, but can they read(initialize) from string? I hadn't found the simtk.unit functionality for that, but I could check again.

Currently simtk.unit.Quantitys are serialized as a list of tuples ( eg. [(unit1, exponent1), (unit2, exponent2)...]), and then the units are getattr'd when deserializing. Not pretty, but I was having trouble finding a cleaner way.
Serliazation code: https://github.com/openforcefield/openforcefield/blob/topology/openforcefield/utils/utils.py#L126

[j-wags]

That said, I do agree that identical string representations from different packages would help a lot. Like you say, it would let us come back and implement a different unit package later without changing our serialized representations.

[andrrizzi]

Not sure it helps, but I wrote a small (and safe) parser for arbitrary mathematical expression to basically solve this problem. Me and @Lnaden used it in YANK to turn an arbitrary strings into a Quantity object. The code is now here: mathematical expression parser and quantity_from_string function (which makes use of the parser).

[jchodera]

I was just going to point out @andrrizzi's solution to this problem.

[j-wags]

Simon+Andrea+Jeff meeting notes about this topic (reposted from slack)

Topic 1: Units
We will eventually need a way to both reliably serialize and deserialize unit-bearing quantities (which Pint can do), and also hand them to OpenMM during system creation (where they'll need to be in simtk units).

• We decided that writing our own serializer/deserializer just adds yet another standard into the field, and leaves us on the hook for maintenance.
• We looked at Andrea's code from openmmtools, but it doesn't have the functionality we need (it doesn't solve the spaces-to-underscores problem (eg "elementary charge" --> "elementary_charge", where the former is the result of returning the unit as a string, and the latter is the string we need to pass to getattr(simtk.unit, unit_name) to retrieve the unit) ).
• We realized that, inevitably, we will need a dict of {X : simtk unit}. In the current topology branch, X is a string (and we use the above, ugly getattr trick to deserialize). Probably the best thing for X to be in the long run is Pint units.
• So we need to decide where in our code the conversion from simtk.units to Pint units will happen. If we choose to have our internal data structures use simtk units, then the conversion to QCE/Pint will happen during serialization or deserialization. On the other hand, if our internal representation is QCE/Pint, then we have to convert when we pass force constants and such during openmm system creation.
  Discussion continued on slack: https://openforcefieldgroup.slack.com/archives/C8NE3J96U/p1547588803213400

[j-wags]

Important note from Slack: https://openforcefieldgroup.slack.com/archives/C8NE3J96U/p1547593277259300

John Chodera [15:01]
In my mind, if we standardize on pint, we're just looking for a way to easily get the data into OpenMM when creating a system.
Here's the simplest thing to do right now:
pint can define unit systems: https://pint.readthedocs.io/en/0.7.2/systems.html

OpenMM has a natural unit system: http://docs.openmm.org/latest/userguide/library.html#units
(It's defined in code a little more clearly)
We can define a unit system that matches OpenMM's within pint.
Then we just need a function that takes every unit-bearing quantity, checks the dimensions are as expected, and converts it into the OpenMM unit system, stripping units.
Something like
get_quantity_in_openmm_unit_system(quantity, dimensions)
Where dimensions is the pint dimensions we want to validate against.
That allows us to do strict dimension compatibility checking and convert into a format we can stuff into OpenMM.
And dodge writing a wrapper or large converter.
Without even using simtk.unit

[j-wags]

For future reference, Simon had a problem where simtk Quantities whose units are reduced to dimensionless are just converted into floats, which was breaking parts of his code where he'd sometimes have unitless Quantities come through and try to ask about their units. Pint doesn't seem like it would have this problem.

from simtk import unit
print((8.0*unit.angstrom / unit.angstrom) - 5)

3

import pint
ureg = pint.UnitRegistry()
print((8*ureg.angstrom / ureg.angstrom) - 5)

3.0 dimensionless

[jchodera]

cc: openmm/openmm#2247

[mattwthompson]

#1142 moves to using openff-units, which is based on Pint. This will be included in v0.11.0.