First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
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: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-dev] r2499 - in CellML_DOM_API/trunk: CIS/sources interfaces
  • Date: Mon, 28 Jul 2008 07:47:42 +0100
> -----Original Message-----
> From: cellml-tools-developers-bounces at cellml.org [mailto:cellml-tools-
> developers-bounces at cellml.org] On Behalf Of Andrew Miller
> 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.

As I said, this is roughly what I use in COR and it works perfectly fine.
Now, I know that PCEnv also uses GSL and I have no idea about that library.

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

That's certainly what should have been done in the first place (and I cannot
believe that it would slow things down that much to the point where it
wouldn't be worth doing).

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

Not sure about that.

> If the amount of duplicated general code (not specific to one
> library) grows too much, however, this balance might change.

Agreed.



Archive powered by MHonArc 2.6.18.

Top of page