>> CellML processing software is not required to check for >> dimensional consistency at the equation level (but validating >> software would probably want to). Software is also not >> strictly required to convert at the connection level, >> although appendix C defines how to do this if software >> implements the functionality (CCGS and mozCellML do have this >> functionality). Derived units are converted into the set of >> base units, and base units are compared (and constant factors >> multiplied and raised to the appropriate powers, to get the >> conversion factor). > > Exactly and I guess this is the point I was trying to make: maybe CellML > processing softwares should be forced to do those checks?
While I'm not sure we should be making it compulsory for CellML compliant applications to completely support units validation and conversion, I do think we need to think a bit about this issue to address the following example... Currently, when I read my model in to an application which has complete units support (such as JSim) it may generate and insert appropriate unit conversion factors within my equations (and variables) when compatible but different units have been used. Then I can perform simulations using the model and get a given set of results. However, when I read my model into an application with less than complete support for units those conversion factors may or may not be added to the equations and variables and when I run the same simulations I get a different set of results for essentially the same input model. Both applications can be seen as behaving correctly....I guess. I'm really not sure how to address this other than suggesting that applications clearly state their units support status and provide some way to easily locate (and view?) instances where unit conversion factors have been added to the model (either at the connection level or within equations). _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
