dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday April 26 2011 13:27:10 Anders Logg wrote:
> On Tue, Apr 26, 2011 at 01:16:34PM -0700, Johan Hake wrote:
> > On Tuesday April 26 2011 10:41:50 Anders Logg wrote:
> > > On Tue, Apr 26, 2011 at 10:23:35AM -0700, Johan Hake wrote:
> > > > Hello!
> > > > 
> > > > (Sorry for the spamming, the previous email was prematurely sent...)
> > > > 
> > > > I am about to use DOLFIN to solve a set of distrinct ODEs. The ODEs
> > > > are a result of an operator splitting of a PDE, avoiding an
> > > > expensive reassemble each newton itteration.
> > > > 
> > > > Each ODE is potentially small but it needs to be solved for each node
> > > > on a mesh. Each one of the ODEs are decoupled from eachother.
> > > > 
> > > > What do you think would be fastest:
> > > >   1) To solve each small ODE using a DenseMatrix and a direct solver
> > > >   2) Put all the small dense matrices into a big sparse one and go
> > > >   for an
> > > >   
> > > >      iterative solver.
> > > > 
> > > > For the last one I need to construct my own assembler, iterating over
> > > > the degrees of freedom.
> > > 
> > > I think Option (1) since it can be easily and efficiently
> > > parallelized.
> > 
> > Ok.
> > 
> > > You could also consider checking out the ODECollection class.
> > 
> > Has this been tested, and are there any example of how to use the
> > ODECollection? What ODE solver is used to solve the ODE. I do not need
> > any multi adaptive ODE solver ;), just an implicit fast and rock stable
> > one.
> 
> You can choose between cG(q) and dG(q) for any q, and it can be either
> mono- or multi-adaptive, or not adaptive at all.

Ok

> The ODECollection class is untested and probably doesn't work so it
> might need some love.

Well, I need some love right now, so I will probably not spend time pouring 
love over something that will be changed... I also see that the TimeStepper 
still holds the solution vector, and for a big ODECollection that would mean a 
lot of copying. Not sure this would be the biggest hog though?

> Anyway, the plan is to move much of the functionality for solving ODEs
> into FFC and generate code for in the same way as we do for assembling
> PDE systems so much of the ODE code might be removed or rewritten in
> the near future.

Sounds very cool! Do you have any person to do the job? I am not offering 
myself ;) Are the potential heart (bi/mono-domain) solver included in the 
greated scheme here?

Johan

> --
> Anders
> 
> > I guess I then just implement
> > 
> >   virtual void f(const Array<real>& u, real t, Array<real>& y)
> > 
> > and potentially also:
> >    virtual void J(const Array<real>& dx, Array<real>& dy,
> >    
> >                   const Array<real>& u, real t);
> > 
> > as I have my ODE in a symbolic language (SymPy) already, so it would be
> > easy to generate that code.