Hi, I have been wanting to use some functionality present in the CellML Code Generation Service, for a quite different type of problem (not a system of ODEs). The problem is, the functionality isn't exposed. I think there is actually quite a lot of useful functionality in the CCGS which could be exposed. I am therefore proposing that the CCGS be split into a number of smaller, independently useful components...
1) CUSES: The CellML Unit Simplification And Expansion Service. This service will allow a string, describing a unit, together with a component or units element in which the unit appears, to be passed in. It will then return another object, which represents the unit in a special canonical. This canonical form will consist of an ordered sequence of base units (for some unique ordering of base units). Base units will include built-in base units as well as user-defined base units. The canonical sequence will also carry multipliers, offsets, and exponents for each base unit. It will be possible to compare to canonical forms of units. There will also be an option for whether to combine exponents when units have a different multiplier, so that, for example, millimetre . (millisecond ^ -1) . microsecond will only be simplified to micrometre if you turn the option on. I think it is this specific type of simplification that has lead to the recent debate over units. It is hoped that this module will be useful for editing tools, validators, and code generators, as well as any other software that needs to worked with units. If you work on such software, let me know if this sounds useful. 2) CeVAS: The CellML Variable Association Service. This service provides an efficient way to find all the variables which are connected to each other, even if they are different components, and perhaps in different imported models. It also allows annotations to be made per actual variable (i.e. group of connected variables), and it uses CUSES to compute conversion factors and offsets needed to convert between one CellML variable and another one connected to it. This should be useful for a range of simulators and code generators, hopefully even ones which are not ODE-based. 3) MaLaES: The MathML to Language Expression Service. This provides facilities for translating individual MathML expressions into code in a specific language. The code will provide a programmatic interface for setting up tables used to drive the code generation, which will aim to support a range of common languages (earlier FORTRANs being the hardest, due to the line-length restrictions). The code will use CeVAS annotations to look up the name of the variables, so you will be able to use arbitrary variable names. This service will also be able to determine certain information about the mathematics, such as returning a set of variables on each side of the equation, and determining whether external code is used. The CCGS will keep the code used to determine the order of the expressions, as well as generation of the actual expressions. I welcome any opinions on whether this is useful, suggested improvements, and so on. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
