dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Feb 11, 2009 at 11:26:23AM +0100, Ola Skavhaug wrote:
> 
> 
> 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
> :)

Sounds good. I've removed the ODE argument to update now.

-- 
Anders

Attachment: signature.asc
Description: Digital signature