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 <[EMAIL PROTECTED]> To: Jonathan Cooper <[EMAIL PROTECTED]> CC: Peter Hunter <[EMAIL PROTECTED]>, "Edmund J. Crampin" <[EMAIL PROTECTED]>, David Nickerson <[EMAIL PROTECTED]>, "James B. Bassingthwaighte" <[EMAIL PROTECTED]>, Alan Garny <[EMAIL PROTECTED]>, James Lawson <[EMAIL PROTECTED]>, Tommy Yu <[EMAIL PROTECTED]>, Erik Butterworth <[EMAIL PROTECTED]>, Penny Noble <[EMAIL PROTECTED]>, Martyn Nash <[EMAIL PROTECTED]>, Jagir Hussan <[EMAIL PROTECTED]>, Mark Trew <[EMAIL PROTECTED]>, Poul Nielsen <[EMAIL PROTECTED]>, Matt Halstead <[EMAIL PROTECTED]>, Steve McKeever <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
