Handle physical units

[jonc125]

• Need to parse Model level units
• Need to parse Component level units, stored separately
• Need to resolve units to the correct level (component, model, predefined)
• Need all numbers in equations to be quantities with units
• Similarly all variables have units (although, see Model manipulation #21, these may not be known when the equation is first created, and need to be calculated when all model manipulation done) (issue Adding unit conversion for code generation #77 will deal with this)
• Need to be able to calculate the units for an expression
• Need to be able to automate units conversions (including adding explicit conversions in generated code) (issue Adding unit conversion for code generation #77 will deal with this)
  • These are only required at connections between components
  • The protocol can define conversion functions for cases where you're not just scaling within one dimension. These specify the source dimension (actually, arbitrary source units within that dimension), target dimension, and a unary function converting a value from source to target units. This gets to the correct dimension; scaling may then be needed to get the exact required units.
• Handle 'quirks' in the CellML units system
  • The SI base units supported are: ampere, candela, kelvin, kilogram, meter, mole, second
  • Modellers can define new 'base units' to create novel dimensions, unrelated to any other units
  • There is an explicit 'dimensionless' unit for plain numbers
  • There are some name aliases: metre/meter, litre/liter
  • pycml adds special 'boolean' units for the results of relational operators and the MathML symbols true and false. There could be other ways of handling this :)
  • CellML does have an 'offset' field to support e.g. Celsius & Fahrenheit. But no models use this and the semantics are broken, so we'll say it's not allowed!
• Handle typical 'quirks' in CellML models, e.g.
  • exp(V) where V is in volts, not dimensionless (occasionally also in volt^2, millimolar, ...)
  • tanh(V) where V is in volts, not dimensionless
  • Many models also have more serious errors, mostly dimensional mismatches in the operands to eq, geq, gt, minus, plus, piecewise. Currently we only warn about these when generating code, as otherwise we'd need to fix lots of CellML files!

[MichaelClerx]

Ideas / initial libraries?

You mentioned https://pint.readthedocs.io/en/0.7.2/ at one stage?

[jonc125]

Yes, we're using pint for several other projects, and it's working nicely there!

[jonc125]

Sympy has its own units system; @tamuri will investigate this first, as it may integrate better with the rest of Sympy.

[jonc125]

@tamuri I've added more info in the description about the kinds of units quirks & conversions our code will need to handle.

[MichaelClerx]

CellML does have an 'offset' field to support e.g. Celsius & Fahrenheit. But no models use this and the semantics are broken, so we'll say it's not allowed!

Just wanted to +1 this, and mention that we removed it in CellML 2.0

(Also "e.g." here means "these 2 and these 2 alone". Apart from maybe shoe sizes)

Shoe size in the United Kingdom, Ireland, India, and South Africa is based on the length of the last used to make the shoes, measured in barleycorn (​1⁄3 inch) starting from the smallest size deemed practical, which is called size zero. It is not formally standardised. Note that the last is typically longer than the foot heel to toe length by about 1⁄2 to 2⁄3 inch (13 to 17 mm).

🤔

[MichaelClerx]

@tamuri I've got a list of common/less common SI units if that helps any :-)

https://github.com/MichaelClerx/myokit/blob/master/myokit/units.py

[tamuri]

Sympy uses gram (g) as the fundamental unit for mass (!), which leads to oddities. We'll define our own Sympy quantities.

See sympy/sympy#14734

[MichaelClerx]

Sympy uses gram (g) as the fundamental unit for mass

I've done the same in Myokit! It makes everything much easier, because none of the other base units have a prefix-multiplier. Didn't encounter any oddities!

[jonc125]

You end up with volt having a multiplier of 1000, because it's defined in terms of kg...

[MichaelClerx]

But who looks at those? Surely a Volt is built from the fundamental units, whatever way you define them (like a linear algebra basis), and once it's defined it's fine?
Why make the developers life difficult by choosing a basis where 1 of the elements has special prefixing rules?