First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Dimensional consistency and units conversions (was [Fwd: Re: ten Tusscher model])


Chronological Thread 
  • From: jonathan.cooper at comlab.ox.ac.uk (Jonathan Cooper)
  • Subject: [cellml-discussion] Dimensional consistency and units conversions (was [Fwd: Re: ten Tusscher model])
  • Date: Mon, 16 Apr 2007 11:38:19 +0100
On Mon, Apr 16, 2007 at 02:02:45PM +0800, David Nickerson wrote:
> > I don't think we agree on what a 'valid model' is. Is a model with an
> > equation like:
> > amount_Na [nmol] = 10^-6 [dimensionless] * conc_Na [nmol / L] * vol
> > [microL]
> > 'valid' by your definition?
>
> no, I would not deem this a valid equation.

While it is dimensionally consistent, it has both an implicit and an
explicit units conversion factor, which could lead to confusion and so
should, in my opinion, be considered bad practice.

> > That obviously depends on your definition of valid. However, I could
> > certainly build a mathematical model including the equation I described
> > above, and I think that would be both valid and useful (you might
> > suggest that dimensionless be changed for microL / L, but this is still
> > meaningless).
>
> I'm still failing to see how replacing dimensionless with microL/L is
> meaningless - but we'll get to this below...I think I am starting to see
> what you are getting at...
>
> > The standard meaning of the equals sign in the mathematics of real
> > numbers is that the left hand side of the equation has the exact
> > numerical value as the right hand side. I don't think there is anything
> > in the CellML or MathML specifications which suggests that any other
> > semantics, such as performing a unit conversion, are given to the equals
> > operator.
>
> The fact that CellML requires all variables and numerical constants to
> be assigned units, to me, is implying additional semantics. To all
> operators, not only the equals operator.

Indeed, I agree. To take an example, in mathematics, "1 = 1". However,
when units are included, I don't think you'll find anyone who'd seriously
argue that "1km = 1m". They are two different lengths! So the
semantics should change to reflect this.

> >> CellML already has a consistently meaningful system for dealing with
> >> units, which include units such as m/km - which is most assuredly
> >> meaningful in CellML.
> > CellML says in appendix C.3.2 that the operands to the equals operator
> > must be dimensionally equivalent. Dimensional equivalence is defined as:
> > "
> > Two units definitions have dimensional equivalence if, when each is
> > recursively expanded and simplified until left with nothing but products
> > of SI and user-defined base units:
> >
> > * the expanded form of each units definition consists of the same
> > set of base units, and
> > * the exponent on each base unit is identical in each expanded units
> > definition.
> > "
> >
> > After the first round of expansions of m/km, you get m^1 * m^-1. But the
> > simplification rules say...
> > "If two units references are equivalent (as defined in Appendix C.2.1
> > <http://www.cellml.org/specifications/cellml_1.1/.#sec_units_rules_units_equivalence>)
> >
> > and have exponents with equal and opposite value, then they may be
> > replaced by a reference to |dimensionless|."
> > Therefore, after expansion and simplification, m/km ends up in the
> > canonical form "dimensionless", hence why it is no more meaningful that
> > dimensionless.
>
> so are you saying that each variable should have its units expanded
> before the multiplication is done? I think this is the confusion I have
> - I would assume the m/km * km to be performed before the m/km is
> expanded and simplified. So if the expansion is done first then I can
> see why units like m/km is nonsensical...

The CellML specification distinguishes expansion and simplification. The
expansion algorithm given maintains a scale factor in the expanded unit,
and hence the *expansion* of m/km is *not* the same as dimensionless. It
is only when you then simplify that the scale factor is lost. For
checking dimensional consistency, this is fine. For performing units
conversions, it is not, and so the units conversion algorithm in the spec
does *not* drop the scale factor, even though it claims in the text that
the units involved are "fully expanded and simplified", this is according
to C.3.4 (expansion) not C.3.1 (simplification).

So there are two separate questions here:
1) checking the dimensional consistency of mathematics
2) ensuring a sensible semantics for simulating a model

> > This is why you cannot fully automatically 'validate' units consistency
> > beyond validating dimensional consistency in CellML. It has always been
> > designed to represent dimensions and not units. This is usually a good
> > thing, because it means that CellML can reduce everything to SI units.
> > For example, the familiar equation
> >
> > F [N] = m [kg] * a [m.s^-2]
> >
> > can be written as-is in CellML, without having to put a useless
> > conversion factor to write...
> >
> > F [N] = 1 [N / (kg.m.s^-2)] * m [kg] * a [m.s^-2]
>
> In this case a conversion scale factor is not required since N is a
> derived SI unit consisting of the base kg.m.s^-2, so your scale factor
> is indeed 1 [dimensionless] :-)
>
> > You can also then write the same equation as:
> > F [mN] = m [g] * a[m.s^-2]
> >
> > All these formulations are valid, and it would be unnatural to force the
> > author to do any more work to write them.
> >
> > However, the last formulation expands to:
> > F[mm.kg.s^-2] = m [g] * a[m.s^-2]
> >
> > We now have mm and m, and kg and g together (in this case, these
> > differences cancel out), so if there was to be a system that worked at
> > the level of units rather than dimensions, it would presumably flag an
> > error here, which is a bad thing.
>
> I don't see an error here.
>
> mN = mm.kg.s^-2 = m.g.s^-2 = 10^-3 N = 10^-3 m.kg.s^-2
>
> Given units should be resolved to their base units, and the base units
> generally are "dimensions" I don't see any problems here...the only
> issues arise when people start defining base units of mm or ms or
> something similar...
>
> > I am saying that, if these scale factors are not as a result of
> > conversions at the connections, they should be explicitly present in the
> > model, and they should be written in appropriate units (which might be
> > dimensionless). However, there is no need to litter the model with
> > multiplications by dimensionless "1", so these should ideally be left out.
>
> Generally the scale factors are not going to be as simple as the
> examples we have been discussing so saying that a model will be littered
> with nonsensical dimensionless units is probably a bit over the top.

There is indeed no need to have multiplications by dimensionless "1" - if
the scale factor is 1, no scaling is required! If you want an explicit
scale factor that isn't 1, I think you should give it appropriate units.
If this is considered to be ugly, then why not force tools to do the
conversions for you? Tools should be developed to help the modellers,
rather than modellers being forced to jump through hoops so that tool
developers have an easier life.

> I have been assuming that the units used in a mathematical expression
> were first manipulated by the mathematical operators in the expression
> before any expansion and simplification were done. eg:
>
> y [m] = 1000 [m/km] * x [km] = (1000 * x) [m]
>
> but it seems that expansion and simplification are done first, eg:
>
> y [m] = 1000 [m/km] * x [km] = 1 [dimensionless] * x [km] = x [km] ???

I think Andrew would say
y [m] = 1000 [m/km] * x [km] = 1000 [dimensionless] * x [km] = 1000x [km]
since the '1000' is explicitly given as a constant.

> in which case I fail to see how it is possible to write a valid equation
> in CellML with y in [m] and x in [km]. Perhaps this is something that
> needs looking at in the specification.

I'd say so. It doesn't help that even the errata for CellML 1.1 has an
incorrect formula - it doesn't include the exponent.

Jonathan.

--
Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/

On a cup by a cash register: "If you fear change, leave it here."


Archive powered by MHonArc 2.6.18.

Top of page