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 13:10:23 +1200
Sent to the mailing list for the benefit of the archives and anyone not
CCd. Sorry if you have already seen this.

-------- Original Message --------
Subject: Re: ten Tusscher model
Date: Mon, 16 Apr 2007 09:32:26 +1200
From: Andrew Miller <ak.miller at auckland.ac.nz>
To: Jonathan Cooper <jonathan.cooper at sjc.ox.ac.uk>
CC: Peter Hunter <p.hunter at auckland.ac.nz>, "Edmund J. Crampin"
<e.crampin at auckland.ac.nz>, David Nickerson
<david.nickerson at nus.edu.sg>, "James B. Bassingthwaighte"
<jbb at bioeng.washington.edu>, Alan Garny <alan.garny at physiol.ox.ac.uk>,
James Lawson <j.lawson at auckland.ac.nz>, Tommy Yu
<tommy.yu at auckland.ac.nz>, Erik Butterworth
<butterw at bioeng.washington.edu>, Penny Noble
<penny.noble at physiol.ox.ac.uk>, Martyn Nash
<martyn.nash at auckland.ac.nz>, Jagir Hussan <r.jagir at auckland.ac.nz>,
Mark Trew <m.trew at auckland.ac.nz>, Poul Nielsen
<p.nielsen at auckland.ac.nz>, Matt Halstead
<matt.halstead at auckland.ac.nz>, Steve McKeever
<steve.mckeever at comlab.ox.ac.uk>
References: <460EF662.40107 at auckland.ac.nz>
<Pine.LNX.4.58.0704030935360.23133 at arwen.bioeng.washington.edu>
<4619BE54.1000005 at auckland.ac.nz> <4619CA9F.9010902 at nus.edu.sg>
<Pine.OSX.4.64.0704090843030.10210 at gollum.bioeng.washington.edu>
<461A6B4E.2080508 at auckland.ac.nz> <461AE48C.1090002 at nus.edu.sg>
<461AEC84.6030400 at auckland.ac.nz> <461AFF1C.5090005 at auckland.ac.nz>
<20070413091332.GA16014 at jonc.ath.cx>



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:

Section 5.2.6 says explicitly: "CellML processing software is not
required to be capable of converting between units definitions."
I think that in future versions of CellML, there should be no option to
not implement units conversions at the connections, as it leads to two
different interpretations of the same model.

Section 5.2.7 also says: "This specification does not attempt to
completely prevent model authors from creating invalid mathematics.
Dimension consistency checking prevents modellers from adding variables
with different dimensions but would not find errors in Equation 7
<http://www.cellml.org/specifications/cellml_1.1/.#eqn_uedc_1> and
Equation 8
<http://www.cellml.org/specifications/cellml_1.1/.#eqn_uedc_2>, which
have different units but the same dimensions:

Equation: uedc_1 (7)

Equation: uedc_2 (8)

Although it would be technically possible (and useful) to find and
correct such errors, CellML processing software is not required to be
able to do so."

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 think we should wait to continue this discussion
>> until next week when Poul and Andrew are both back in Auckland. Maybe in
>> the meantime Jonathan or Steve could comment on how Jonathan's Python
>> units checker handles this.
>>
>
> 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).
> 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.

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

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.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page