dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Wed, Feb 11, 2009 at 11:16 AM, Anders Logg <logg@xxxxxxxxx> wrote:

> On Wed, Feb 11, 2009 at 10:26:45AM +0100, Ola Skavhaug wrote:
> > Sorry for cross posting.
> >
> > The new ODECollection class in DOLFIN will enable batch processing of
> ODEs, and
> > this is exactly what we need to solve the bidomain equations. However,
> the
> > interaction with the ODEs are limited. The callback method update(ODE&,
> real*,
> > uint) gives, in principle, the user an opportunity to interact with each
> ODE
> > system before stepping forward in time. However, the interface of
> dolfin::ODE
> > is too limited to really benefit from the callback. I suggest another
> callback,
> > now at the ODE level, that can be called from a possible subclass of
> > dolfin::ODECollection's update:
> >
> > namespace paracardium
> > {
> > class CellCollection: public dolfin::ODECollection
> > {
> >   public:
> >
> >       [...]
> >
> >       virtual void update(ODE& ode, real* u, uint system)
> >       {
> >          ode.update(parameters[system]);
> >       }
> >
> >    private:
> >       std::vector<real*> parameters; // parameters.size() == num_systems.
> >
> > }; // End class
> >
> > } // End namespace
> >
> > Of course, we run the risk of the ode.update() call getting the wrong
> number of
> > array components. I would argue that the need for speed is important
> enough to
> > take this risk.
>
> Since there may be very many different ways in which an ODE should be
> updated in between calls (not necessarily with a single parameter
> value) I think it's the responsibility of the ODE and ODECollection
> subclasses to decide on how to interact.


My suggestion was not restricted to a single parameter value. Only doubles.


>
>
> The user will subclass both the ODE and ODECollection subclasses so
> one may for example do the following:
>
> class MyODE
> {
> public:
>
>  void f();
>  ...
>
>  friend class MyODECollection;
>
> private:
>
>  real a;
>  real b;
>
> };
>
> class MyODECollection
> {
> public:
>
>  MyODECollection(uint num_systems) : ODECollection(ode, num_systems) {}
>
>  void update(real* u, uint system)
>  {
>    if (system == 0)
>    {
>      ode.a = 5.0;
>      ode.b = 3.0;
>    }
>    else
>    {
>      ode.a = 3.0;
>      ode.b = 5.0;
>    }
>  }
>
> private:
>
>  MyODE ode;
>
> };
>
> So my suggestion would be to remove the ODE argument to the update
> function. Then a user must store the ODE (either as part of the class
> or by reference) in the ODECollection subclass. Then the compiler will
> know what kind of ODE it is so that one may set specific variables.
>

This is one solution. Spesifically, I will implement a new ODE abstraction,
paracardium::CellModel, where my suggested parameter system will be
implemented :)

Ola


>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmSpYEACgkQTuwUCDsYZdHYjwCggd0UPEx2r13aVTqFer+cYSo0
> vwUAnAgDx2w1VzPyfoHtK2zCsFDW88he
> =w8Dd
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev<https://www.fenics.org/mailman/listinfo/dolfin-dev>
>
>


-- 
Ola Skavhaug