Thanks for the update Andrew. Its generally looking pretty good and the 
example helps me a lot, I just have a couple of points I'd like to 
raise. (a minor point is the about attribute on the main rdf:Description 
refers to the model as CoupledPendulum_version01 which doesn't match the 
cmeta:id on the model element.)

Following the earlier discussion I think the important variables section 
should just be dropped from the simulation metadata specification.

I'm wondering if the cs:startingValue, cs:endingValue, 
cs:maximumStepSize, and cs:tabulationStepSize should be specified using 
MathML. This is where my ignorance of RDF will show through, but its 
useful (necessary and required?) to be able to at the least use a 
mathml:cn to specify a value with a defined set of units. And 
potentially you might want to bound your integration interval based on 
the value of some variable (?) I'm not sure how you would do this with 
valid RDF and having it contained in the closed world of the 
cs:simulation node (arc?). Maybe we just start off by adding a 
cellml:units attribute to the cs:startingValue etc nodes, but then you 
have the issue of scoping the units. I guess it just makes sense to 
leave it as it is and assume the values are specified in the same units 
as the bound variable itself. But that assumption should be added to the 
specification.

For the specification of the numerical algorithms used in a simulation, 
I think we need to be clearer on the implications of each of the 
allowable options. i.e., you need to be sure that in any given 
implementation you will get comparable results for the same choices, 
that my implementation of gear-1 uses the same method as your 
implementation of gear-1. And maybe there also needs to be some generic 
options that allow a model author to hint at the requirements of their 
model/simulation. For example, cs:linearSolver has an option for direct 
but not a generic iterative (for various reasons I have found that some 
models under some circumstances simply run faster with an iterative 
solver than with a direct solver). Or for cs:multistepMethod maybe there 
should be options for explicit, implicit, stiff etc. as well as being 
able to specify specific methods. We might also want to consider the 
ability to specify alternative methods, e.g., an author knows that 
gear-2 gives the best results for their model but if an implementation 
does not provide that option it would be good to know that it will fall 
back on a stiff method rather than simple Euler stepping.

Is there also a case for specifying the minimum set of numerical 
algorithms an implementation has to support? It would be good to be able 
to have a model/simulation that you know will run and produce 
quantitatively the same result in any compliant implementation.

And just as a final query, is there anyone working on an implementation 
for pulling this metadata out of a model using the current CellML 1.1 
API? I think this was briefly touched on at the last CellML meeting...in 
the work I've been doing I just use the 
cellml_api::model::getRDFRepresentation() method to grab the metadata in 
a "standard" DOM form and then use standard DOM navigation to pull out 
the information I need - which I guess only works because I know the 
serialised format of the simulation metadata.

I'll look at updating my implementation to use this new version of the 
specification and see what other issues come up.


Andre.

Andrew Miller wrote:
> Hi all,
> 
> I have updated my earlier draft of the simulation metadata 
> specification, to include features from the draft Andre posted to this list.
> 
> The draft can be viewed at 
> http://www.cellml.org/specifications/metadata/simulations
> 
> As requested by Andre, the draft now includes an example model 
> containing (hopefully!) valid metadata.
> 
> Opinions on the draft are solicited. I am especially keen to hear 
> feedback about the definition of parameters such as cs:iterationMethod 
> and cs:linearSolver, and to hear if they make sense to people using 
> those (I am not sure if I interpreted Andre's specification correctly).
> 
> Best regards,
> Andrew Miller
> 
> _______________________________________________
> cellml-discussion mailing list
> [email protected]
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
_______________________________________________
cellml-discussion mailing list
[email protected]
http://www.cellml.org/mailman/listinfo/cellml-discussion

Reply via email to