dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 26, 2011 at 01:35:54PM -0700, Johan Hake wrote:
> 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?

The idea is to have one big solution vector but work through offsets
in the ODECollection class. Anyway, it's probably good to stay away
from it since it might change rapidly or be removed.

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

Yes, Benjamin, Marie and myself (post 1.0 and book).

--
Anders