Chronological Thread 

< Chronological >      < Thread >

---

>> 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.

yeah, thinking about it some more that seems the best approach for now.

>> 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).

I would hope that if a model author were to be specific enough to say
use the runge-kutta-prince-dormand-8-estimate-9 multistep method with
this maximum bound variable step size then you should be getting the
exact same answer out of any implementation that supports that very
specific algorithm (to within some machine precision error). Otherwise
there would seem little point in being so specific about the method to
use. Maybe you could expect differences if a given implementation used
single instead of double (or higher) precision, so maybe we need to
include that in the specification? We're already saying that all the
typed literals are generally of type xsd:double so it doesn't seem too
bad to be adding that runge-kutta-prince-dormand-8-estimate-9 is
expected to be a implementation of that method using at least double
precision floating point arithmetic.

Especially once we start getting into model curation it is going to be
very important to know exactly what methods were used to validate the
model. And again, I would hope that such a detailed specification of the
method should be enough, without also having to specify the exact
implementation used as well.

Probably the thing to do is to provide the appropriate references for
each of the methods in the specification (or maybe an appendix?) as well
as test models and results that people can use to test/validate their
implementation. Maybe its not such a bad thing to have in the
specification that runge-kutta-prince-dormand-8-estimate-9 refers to the
implementation of this method in the GNU scientific library and the BDF
method refers to the implementation in the SUNDIALS CVODE
implementation, if we need to be that precise to guarantee
quantitatively similar results for different applications with the same
solver options ???

>> 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.

It may be a useful option to be able to include as a fallback solver
rather than letting an implementation fall back on the default direct
solver. More as a method for saying don't even try to use a direct
solver for my model. (for example, you might know that under certain
conditions your model is going to result in a very nearly singular
matrix that will never be feasible for 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.
>>
> 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.

I think that would be very useful.

>> 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.

I think that if an implementation is falling back on the generic options
then you might expect some models to produce different results. But if
an implementation supports the specific method the model author
specifies then you should get the same results.

But you're right, its not worth specifying the minimum set.

> 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.

Will be good if you can let us know the canonical form that will
initially be used in the model repository. Does anyone happen to know
any good C/C++ compatible RDF tools that could be used in a standalone
application outside of mozilla and the model repository?

>> 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.

yep - but its always good to try things out to make sure they make as
much sense in practice as they do in discussion :-)

An issue I forgot to mention yesterday was that the specification
includes a way to specify the iteration method to be used with the
linear solver. For what I have been doing, the specification of the
linear solver to use decides the iteration method that will be used for
the linear solver (i.e., all my iterative solvers are krylov-subspace)
and the iteration method I specify applies to the multistep method. The
options available are functional and Newton iteration - where functional
is only suitable for non-stiff systems and requires no linear solution
while Newton requires a linear solver.

So I think there should either be two iteration method predicates or the
linear solver choices need to include the iteration method. For example,
instead of generalised-minimum-residual you have GMRES (Newton
iteration) and SPGMR (krylov-subspace iteration). Probably the first
option is better and we could have cs:iterationMethod refer to the
multistep method iteration and then add a cs:linearSolverIterationMethod
for the linear solver iteration method.


Andre.

---

• [cellml-discussion] New draft of Simulation Metadata Specification available, Andrew Miller, 08/14/2006
  • [cellml-discussion] New draft of Simulation Metadata Specification available, Shane Blackett, 08/15/2006
    • [cellml-discussion] New draft of Simulation Metadata Specification available, Andrew Miller, 08/16/2006
      • [cellml-discussion] New draft of Simulation MetadataSpecification available, David Nickerson, 08/17/2006
  • [cellml-discussion] New draft of Simulation Metadata Specification available, David Nickerson, 08/17/2006
    • [cellml-discussion] New draft of Simulation Metadata Specification available, Andrew Miller, 08/18/2006
      • [cellml-discussion] New draft of Simulation Metadata Specification available, David Nickerson, 08/18/2006
        • [cellml-discussion] New draft of Simulation Metadata Specification available, Andrew Miller, 08/18/2006
    • [cellml-discussion] New draft of Simulation Metadata Specification available, Andrew Miller, 08/18/2006

---

Archive powered by MHonArc 2.6.18.