A list for the developers of CellML tools

Text archives Help


[cellml-dev] r2499 - in CellML_DOM_API/trunk: CIS/sources interfaces


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] r2499 - in CellML_DOM_API/trunk: CIS/sources interfaces
  • Date: Mon, 28 Jul 2008 18:16:15 +1200

Alan Garny wrote:
>
>
>> One option might be to allow time values which are within tolerance of
>> the requested one through instead of a strict equality test.
>>
>
> That's one possible solution. Something else that I have been using
> successfully in COR (but don't know whether it could be applied here, as I
> am not familiar with the code) is to have something like:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> n = 1;
> tStep = <whatever>;
> tStop = n*tStep;
> tEnd = <whatever>;
>
> repeat
> n++;
>
> tStop = n*tStep;
>
> <do_whatever>
> until tStop == tEnd;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
The problem is that actual step sizes are under the control of the
integrator. We are just controlling where the integration stops. In
other words, <do_whatever> will tell us where it got up to, which may or
may not be tStop, or may, due to the internals of the integrator, be
very close to tStop but not exactly on it.

> Otherwise, something that worries me is the fact that CISSolver.cxx contains
> quite a bit of code that is duplicated. I have in
> "CDA_CellMLIntegrationRun::SolveODEProblemGSL" and
> "CDA_CellMLIntegrationRun::SolveODEProblemCVODE" in mind. This is very much
> error prone and not neat at all.
>
The code is, however, quite tightly coupled to the GSL and CVODE
integrators, respectively. We could build a common interface around
CVODE and GSL, but that extra layer of abstraction would most likely
slow things down, and given the small amount of code currently involved,
it would probably be more error prone to maintain the extra abstraction
layer rather than maintaining the two similar bits of code for each
library. If the amount of duplicated general code (not specific to one
library) grows too much, however, this balance might change.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page