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: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] [Fwd: Re: ten Tusscher model]
  • Date: Mon, 16 Apr 2007 16:09:31 +1200
David Nickerson wrote:
>> Jonathan Cooper wrote:
>>
>>> On Tue, Apr 10, 2007 at 03:06:04PM +1200, Peter Hunter wrote:
>>>
>>>
>>>> Hi David, Edmund, et al,
>>>>
>>>> No question that writing the equation like that is bad practice - and I
>>>> agree that the '1000' factor should be stated as a parameter with units.
>>>> The point that Andrew was making (I think) is that if CellML-compliant
>>>> tools do not enforce units balance within the mathematics (which I
>>>> understand from Andrew is the case) then the JSim checks would yield a
>>>> different outcome.
>>>>
>>>>
>>> I would consider this to be a shortcoming of the other CellML-compliant
>>> tools, personally.
>>>
>>>
>> For CellML to be useful, there should be a unique interpretation of it.
>> I have discussed this before at a CellML meeting:
>> http://www.cellml.org/meeting_minutes/meeting-minutes-for-2006/13.11.2006/
>>
>> Poul has said before that his intention was that units should always be
>> converted at the interfaces, and never be automatically converted at the
>> mathematics. I am in favour of this approach, but I don't think that the
>> current specification is clear on that at all:
>>
>
> 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.
>
>> This could be interpreted to mean that it is acceptable for tools to
>> automatically insert conversion factors into the mathematics (although I
>> think the intended interpretation was that the user should be asked).
>>
>> I therefore think that JSim should not attempt to change the
>> mathematics, and only perform conversions at the connections. Tools that
>> do no conversion at all, on the other hand, are technically still
>> implementing the CellML specification as it is now, but I hope that
>> future versions of the specification will not allow compliant tools to
>> do this.
>>
>
> I agree. And while the default behaviour of JSim is to add in these
> units conversion factors within the mathematics, it is a feature the
> user can choose to turn off. Then when tools like JSim serialise models
> back into CellML the user should again be given the choice of including
> the units conversion factors or not - although as far as I can tell
> there is never a reason not to include them in a valid model.
>
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?
>
>>> The units checking doesn't apply any conversions itself, since it doesn't
>>> transform the CellML model being checked. It does however have the
>>> ability to determine where conversions would be required, even within
>>> mathematics, and display a warning message, to alert model authors that
>>> the behaviour of the model when simulated might vary depending on the
>>> tool. Hence the equation "y [m] = x [km]" would produce a warning.
>>>
>>>
>> Although m and km are in the same dimensions, so that could be correct.
>> For example, what if y was the size on a scale diagram of x (that is a
>> contrived example, but if I can find a contrived example, it means there
>> are probably others that are more realistic).
>>
>
> I would really be interested in a real example where such an equation
> appears in a mathematical model and is valid.
>
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).
>
>>> The transformation tools can add in explicit conversion factors, and
>>> would convert the above equation to "y [m] = 1000 [m/km] * x [km]".
>>>
>>>
>> I think that is wrong, because tools shouldn't change mathematics like
>> that. If the author write y [m] = x [km] within a component, then we
>> should not automatically change those well defined semantics to
>> something completely different, especially if we don't ask the user first.
>>
>
> you could equally argue that the well defined semantics are telling you
> how to convert x in [km] to y in [m].
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.
> But you are right, the user needs
> to be given the choice of doing this or not.
>
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.
>
>> m/km is not meaningful in CellML, because it is just dimensionless (or a
>> multiple of dimensionless, whatever that means?). I don't think we could
>> develop a consistently meaningful system for dealing with dimensionless
>> quantities as having some additional meaning, without also causing more
>> problems for units that should be equivalent, especially when
>> dimensionless ratios of one quantity might be used to scale another
>> quantity (do you then need to add in a factor of 1 which converts from
>> one type of dimensionless ratio to another?).
>>
>
> 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.

> A classical example is engineering strain -
> typically specified in units of length/length.
>
That is again dimensionless.
> These types of units are required if a tool capable of correcting units
> balance inside equations is used to validate a model and reserialise it
> back into CellML for use in other tools which are not capable of the
> units balance.
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]

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.

> Otherwise, how would units balancing scale factors be
> included in a CellML model?
If the scale factor has dimensions, they should be present on the scale
factor. If not, it should be dimensionless.
> As things stand there are very few models
> which do not require such scale factors somewhere (sure, the m/km
> example is probably a bad one).
>
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.
>
>> I think that the current approach in CellML, which is that mathematics
>> are not changed by tools (although dimensions could be checked, and more
>> metadata could be added to facilitate units checking in equations if
>> required), but conversions occur at connections, solves the problems
>> which it is attempting to solve. Components created by different people
>> in different but dimensionally consistent units can be connected, and
>> dimensions can be checked. Providing additional redundant data for
>> checking the equations is useful to many users, but it is not really a
>> direct part of the core objectives of CellML. Part of the reason for
>> CellML's success in the past has been that it restricts itself to only
>> describing the data that is needed for the model, while putting any
>> additional information in metadata. Therefore, it would make sense to
>> ensure that models are dimensionally correct, and put optionally put
>> additional information that justifies the numerical correctness of the
>> mathematics in metadata. This could help computer programs to check that
>> the maths are correct, and users to understand the model.
>>
>
> I can't see a need for any extra metadata to aid units checking and/or
> validation - there is already enough well defined information in the
> equations to achieve this.

My point is that there is not enough such information, as I have
discussed above. You seem to be advocating that authors add more
information into the CellML itself, using a hack on the units support in
CellML (to deliberately define units dimensionally equivalent to
dimensionless). I don't think that this is a very consistent and
workable way of doing things, and it is certainly a hack. If we want to
make authors specify their model redundantly so it can be checked, then
using metadata is the best way to do it.

> Tools need to be able to check and validate
> the units within equations
Checking dimensions is probably enough in most cases, because we can't
tell if the author has made a sensible model in terms of the numerical
values of constants and so on anyway. If tools want to do more, they
need more information than what CellML provides, and this is information
which is only useful to some specific tools (implying it should be
metadata).
> and the user needs control over whether
> incorrect but dimensionally consistent equations have appropriate scale
> factors added in.

There is no way to know automatically that an equation is correct. There
could be metadata that says that the equation has been checked for unit
consistency (a process involving the author), and perhaps annotations
describing what constant values are, to aid in this process. I think the
best we do is to have tools draw the user's attention to equations which
might be incorrect.

> It would also be useful for tools to flag
> dimensionally inconsistent equations
Definitely.
> and possibly suggest corrections.
>
Although this is not necessarily that useful, unless the tool knows
something about the modelling domain being worked on.
> Additional metadata is required to describe the units and dimensional
> correctness of any given part of a model.
>
Agreed.
> I think you are also right in that the specification does need to be
> tightened up to enforce CellML compliant applications to do the units
> conversions at the connection level. And the expect behaviour of tools
> in regard to units checking/correcting within the mathematics. This
> would allow consistent behaviour across all CellML compliant tools. [I'm
> just working through with Matt the best way to capture such proposals on
> cellml.org - we'll hopefully have something soon]
>
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.

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page