> 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. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
