First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
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 09:00:59 +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.)
>
I have now fixed this.
> Following the earlier discussion I think the important variables section
> should just be dropped from the simulation metadata specification.
>
Okay, I will do this shortly.
> 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.
We can infer the units from the bound variable, so it is not strictly
necessary to specify it again here.
> 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?).
If we were going to do this, it would probably best just have a literal
containing the XML. However, this places a significant burden on the
processing software, because it needs to be able to compute variables
and expressions just to be able to determine what times to start and end
the simulation.
> 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.
If you use variables from MathML (i.e. as names inside a cn element),
you get scoping issues, because you don't know what component the
variable is in.

Allowing a reification arc describing the units on arcs with predicate
cs:maximumStepSize, cs:tabulationStepSize, cs:startingValue, and
cs:endingValue (or perhaps better, making the targets of these arcs a
new anonymous node, and making arcs from that node to the value and 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.
>
Okay, I will take this approach in the specification for now, and we can
update it later if the consensus is that we need something better.
> 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.
It is very hard to get the exact same results from any two non-identical
solver implementations, even if they try to implement the same
algorithm, due to numerical instability issues and so on (e.g.
differences in the precision of intermediate results and constants built
into the program, different solver libraries giving slightly different
results, and so on). In some cases, the results may be comparable, and
in other cases they may not be, so it would be very hard to guarantee
this. I agree that gear-1 (I meant using Gear's BDF method, with M=1,
rather than a particular implementation of Gear's algorithm) is a bit
ambiguous and we need some more prose describing what is meant by each
method.

I guess the best we could do is give a reference to papers (we could do
this in every RDF document, but that would probably result in excessive
space use, since most simulations would use the same limit set of solvers).

> 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).
Does it make sense to say "give me an iterative solver" without saying
which one, though? This is the reason I intentionally left that off. If
there is consensus that it is useful, it could be put back.
> 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.
>
We could do this using a collection (in which order is important) to
describe successively less preferable choices of integration method. We
could then allow entries in this list which specify a class of
integrators, rather than a specific one.
> Is there also a case for specifying the minimum set of numerical
> algorithms an implementation has to support?
It probably depends what type of implementation we are talking about. It
is conceivable that some implementations exist solely to allow users to
use a new algorithm, and such implementations would then only support
that algorithm.
> 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.
>
I'm not sure this is feasible, even if the implementations are very
similar, there is a chance that, at least for some models, very
different results will be produced.
> 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?
Not at present, although I will need a way to get this data.
> I think this was briefly touched on at the last CellML meeting.
We discussed how we would deal with the RDF. A standardised way of doing
this would probably be needed before we could start working on any APIs.
The problem is, there is no standardised API equivalent to the DOM for
dealing with RDF, so it is hard to make a standardised API for exposing
data from specific RDF-based specifications.

> ..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.
>
Indeed, I could write the example RDF/XML serialisation in a large
number of different ways, so it would be very hard to deal with them
all. If we developed a general API for this, I don't think that
requiring a certain canonical form would be acceptable.

For the first release of PCEnv, I plan to either require a canonical
form (preferably the one that happens to come from 4Suite, since the
Model repository uses that), or use the Mozilla RDF library.
> I'll look at updating my implementation to use this new version of the
> specification and see what other issues come up.
>
Although be warned that it is still a draft could change again.

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page