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

Text archives Help


[cellml-discussion] [Fwd: Re: ten Tusscher model]


Chronological Thread 
  • From: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] [Fwd: Re: ten Tusscher model]
  • Date: Mon, 16 Apr 2007 14:02:45 +0800
>> I think the key here is automatically. As far as I know there are no
>> tools that will do the conversion within mathematics automatically.
>> About the closest is JSim which has units conversion on by default but
>> this can always be turned off - in which case it is only the units at
>> the interfaces which get converted.
>>
> Based on what Erik said in an earlier e-mail, it looks like JSim either
> always converts units or never converts units, rather than converting at
> the connections only. In any case, if it is on by default, and the
> conversion happens without warning unless you explicitly turn it off, I
> think there is an issue of model interoperability to be concerned about.

Perhaps Erik will correct me, but from my understanding the conversions
at the connection level are done when you first import a CellML model in
JSim's MML. At this point the user is able to turn units conversion off
(which has no effect on the conversion at the connection level). Then
when the MML model gets compiled the units within the mathematics is
checked and corrected where possible if units correction is on.

I see no interoperability issues since I see the behaviour of JSim in
this regard as correct :-)

> 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.

> 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.

> Not only that, but the user should be quite explicitly asked on an
> equation-by-equation basis if they want the change to be made.

I'm not convinced that such an explicit question-answer session is
required - I'm happy enough for a user to state once that they are happy
for all corrections to be made. It would obviously also be nice for a
user to be able to choose how fine-grained they'd like to see the
corrections and for the corrections to be visibly flagged somehow in the
application.

>> 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...

> 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.

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] ???

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.

> It would be useful to me at least, and perhaps others too, if you could
> have any discussions about this on the mailing list. That said, I'm not
> sure that the ability to 'capture proposals on cellml.org' is the
> limiting factor in the emergence of more proposals (which would suggest
> that we could keep it informal until such a time as a true need for a
> more formal process arises), although at least a note that we welcome
> external contributions, and asking for people to contact the list with
> proposals, would be useful.

This will be discussed once we have worked through the issues involved.


Andre.


Archive powered by MHonArc 2.6.18.

Top of page