Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

This looks like a good thing to be doing, and I think #1 especially will
be beneficial in terms of providing a basis for an authoritative
reference implementation of how units are expected to be handled by
CellML compliant tools (at least the tools which are not using CUSES
directly).

I'm just wondering if ordering of equations should also be separated out
from CCGS as you'd imagine most procedural languages would require the
same ordering process. Maybe the actual ordering is too intricately
linked to the specific language for it to make sense separating it out?

And in the code I originally did for CMISS I had some code which took
care of the line length and indentation/prefix requirements of generated
Fortran 77 code, while I'm sure its not very elegant it might be a place
to start if we want to go down the track of generating F77 compatible code.


Andre.

PS - how'd you come up with all the names? :-)


Andrew Miller wrote:
> 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
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [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.