Chronological Thread 

< Chronological >      < Thread >

---

> ECMAScript is not practical for use in modelling, because it is an
> interpreted, non-typed language, which necessarily means that it cannot
> be compiled and will be slower than compiled code.

But CellML is an language for the description and exchange of
mathematical models. It is not meant to be a one-off wonder describing
the most efficient and best performing method for executing numerical
computations.

To turn a CellML model description into something useful for computation
that description has to be interpreted and compiled into some other
format suitable for the environment using it...

Surely in the same manner, a standard description of procedural code
could then be interpreted by any number of applications in whatever
manner they feel best suits their environment?

> External code needs to be extensible, and hence outside the scope of the
> CellML specifications, for several reasons:
> 1) Performance. Code may need to be written in a way which is specific
> to a particular platform in order to be able to perform well.

some response as above.

> 2) Access to existing libraries. There are often extensive libraries and
> other software packages into which a model needs to be integrated. This
> could be in practically any language, and so it would be necessary to
> access to data structures of these libraries to have the model work. I
> believe that this is the case for much of the CMISS-CellML work (I don't
> really think that a proposal to re-write CMISS in ECMAScript would be
> very popular!).

In every case of people using CMISS that I know of, the use of CellML is
to define model specific mathematical equations for integration into a
larger model. I'm not suggesting re-writing CMISS in ECMAScript - rather
you seem to be suggesting including CMISS in a CellML model?!?

This would hold for most such cases of using existing libraries that I
can think of, with the exception of someone wanting to solve a
particular equation or set of equations in a model using a very specific
numerical method that their CellML simulation tool does not support.

Even if you take a step back and look at the larger picture of using
things like FieldML, CellML, MathModelML (or something), etc... to
describe something like an electrical propagation model in the heart,
the tool (eg, CMISS) pulls it all together and plugs fields and
variables together based on the model annotations. Otherwise you'll end
up with cell models that say things like "give me the current load at
this point in space by solving the bidomain model over this geometric
domain" - making the cell model description useless for any other
application. What you rather want is a simply a variable in the model
which is the current load that has an interface of in. Your cell model
integrator doesn't care where this value comes from, it just knows that
when the tool calls for the cell model to be integrated that it will
provide some appropriate value.

> 3) Access to specialised hardware. A model could potentially even
> require that a function is evaluated by some sort of online experimental
> procedure (perhaps automated probing of a hardware model) for a given
> set of inputs.

Again, this seems more like a case where you define a mathematical model
which given some input(s) produces some output(s). The controlling
software would take the mathematical model definition in CellML and
connect the appropriate inputs and outputs. I would really need a
concrete example of why you would want to describe a mathematical model
in CellML which requires input from specialised hardware. Surely you
just define a variable that has an interface of in and annotate it such
that the controlling software can find it and plug in the appropriate
value(s)?

> 4) Multiple standards, with different communities who favour them. It
> would not be practical to get everyone involved with CellML to agree on
> a certain procedural programming language (even deciding on Fortran vs
> C++ etc... has been a challenge at this institute, and will probably be
> impossible for the wider CellML community).

As above, you are not performing computations using CellML directly -
you always turn the model description into something suitable for the
computational environment in which the model is being used. Thats the
beauty of CellML - you can turn it into Fortran or C++, depending on
your personal preference!

CellML is all about being able to exchange a standard description of a
mathematical model between potentially very different software
environments. The whole idea is specifically not specifying the best way
to compute outputs from the model - which seems to be what you are
driving at....and the best way to compute outputs from a model is always
going to be dependent on the target computational environment.

> As an example, consider my PhD project, where I plan to put machine
> learning components into CellML models:
> 1) Performance is likely to be important. If it is too slow, it might
> not be feasible to do at all.
> 2) I plan to use existing libraries, in a range of different languages.
> 3) I also have another (perhaps not as common) gain from specifying the
> external functions without describing their details: I need to run
> different code in 'training' and 'simulation' modes, and if I just wrote
> generic ECMAscript for the simulation case, there would be no simple way
> to deduce the training case. Because of this, it is probably good to
> keep the non-algebraic parts of the model completely separate, and leave
> it up to whoever implements the specific CellML processor.

I'd probably need to see more detailed plans on exactly what you are
planning on doing before commenting on this. But from what I have seen,
whenever anyone has wanted to include procedural code directly in a
CellML model it has always turned out that they are approaching the
problem from the wrong direction.

Just to re-iterate, CellML is all about exchanging *descriptions* of
mathematical models - not implementations of computational code.

> That said, I think we could have multiple levels of degeneracy away from
> standardised code, where you only go down to the next item if the
> current one is impossible:
> 1) Pure CellML.

definitely.

> 2) CellML with standardised Turing-complete code support.

I can see why we should provide a mechanism for this, but have yet to
see an example where it would be useful (other than to get around a
particular tool's deficiencies).

> 3) CellML with external (non-standardised) code.

I still haven't seen a reason why this would ever be required?


David.

--
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: BCP for including external code in CellML models, Andrew Miller, 03/15/2007
  • [cellml-discussion] Proposal: BCP for including external code inCellML models, David Nickerson, 03/16/2007
    • [cellml-discussion] Proposal: BCP for including external code inCellML models, Andrew Miller, 03/16/2007
      • [cellml-discussion] Proposal: BCP for including external codeinCellML models, David Nickerson, 03/16/2007
        • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Andrew Miller, 03/18/2007
          • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Matt , 03/19/2007
            • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Andrew Miller, 03/19/2007
              • [cellml-discussion] Proposal: BCP for including external codeinCellML models, Matt , 03/19/2007
          • [cellml-discussion] Proposal: BCP for including externalcodeinCellML models, David Nickerson, 03/19/2007

---

Archive powered by MHonArc 2.6.18.