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 10:44:55 +0800
> 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.

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

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

>> 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]. But you are right, the user needs
to be given the choice of doing this or not.

> 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. A classical example is engineering strain -
typically specified in units of length/length.

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. Otherwise, how would units balancing scale factors be
included in a CellML model? 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 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. Tools need to be able to check and validate
the units within equations and the user needs control over whether
incorrect but dimensionally consistent equations have appropriate scale
factors added in. It would also be useful for tools to flag
dimensionally inconsistent equations and possibly suggest corrections.
Additional metadata is required to describe the units and dimensional
correctness of any given part of a model.

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]


Andre.


Archive powered by MHonArc 2.6.18.

Top of page