Chronological Thread 

< Chronological >      < Thread >

---

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] Proposal: Refactoring the CCGS into smaller, re-usable components, Andrew Miller, 04/24/2007
  • [cellml-discussion] Proposal: Refactoring the CCGS into smaller, re-usable components, David Nickerson, 04/24/2007

---

Archive powered by MHonArc 2.6.18.