CellML Discussion List

Text archives Help


[cellml-discussion] New draft of Simulation Metadata Specification available


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] New draft of Simulation Metadata Specification available
  • Date: Fri, 18 Aug 2006 11:10:16 +1200

David Nickerson wrote:
> 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.
>
This has now been removed from the specification at
http://www.cellml.org/specifications/metadata/simulations
> 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.
>
I have now added a paragraph stating this assumption. If you want to
search for it, look for "All literals of type xsd:double defined in this
section are expressed in"

> 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.
I have added some additional information in brackets after the method
names to provide more information on this.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page