Re: [cellml-discussion] Proposal: BCP for including external code inCellML models

2007-03-15 Thread Andrew Miller
David Nickerson wrote:
   3) Do you agree with the basic premise of the proposal, that is that 
 it is better to have a model which is partly expressed in CellML, than 
 to have a model which is entirely expressed in a more general 
 programming language?
 

 yes.

   
   4) Do the best practice guidelines for CellML authors adequately 
 protect the utility of CellML as a model interchange format?
 

 I think so.

   
   5) Does the proposed approach fit well with the design of CellML?
 

 not really. The design philosophy of CellML is to utilise existing 
 standards where possible. I seem to recall the original intention for 
 the inclusion of required procedural code in a model was through the 
 csymbol mechanism you describe, but the code referenced is defined in a 
 standard format - with ECMAScript the preferred choice at that time. And 
 I see now there is a ECMAScript for XML extension, E4X, which might be 
 useful?
   
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.
 By using a standard format for the external code (particularly if 
 available support for that format is good), you could reasonably expect 
 multiple applications to support your model. Although, similarly, if the 
 support you describe is built into the CellML API (CCGS?) then you could 
 also expect multiple applications to support a given model with external 
 code.
   
 Maybe some examples of where the use of external code is required would 
 be useful?
   
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.
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!).
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.
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 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.

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.
2) CellML with standardised Turing-complete code support.
3) CellML with external (non-standardised) code.

Best regards,
Andrew Miller

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proposal: BCP for including external codeinCellML models

2007-03-15 Thread David Nickerson
 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 atand 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