dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Sep 22, 2005 at 09:56:01AM +0200, Johan Hoffman wrote:

> This looks very nice Anders! It seems that we now in DOLFIN have nice
> working modules (Stokes, Navier-Stokes, Elasticity,...) tackling many of
> the usual problems when implementing a PDE solver: high order, mixed
> element, non-linear problems (as a linearized problem),...
> 
> I think the approach with a PDE class holding the pair (a,L) sounds like 
> good idea.

I think so too. There's just a question about naming. Should we call
it PDE or LinearProblem? The reason one would like to call it
LinearProblem is that a pair (a, L) can be used to define a projection
as well, which is not a PDE but a linear problem:

    a = u*v*dx
    L = f*v*dx

The solution u of a(v, u) = L(v) is the projection of f onto the
space.

A reason not to call it LinearProblem might be that a linear problem
might be Ax = b, but maybe we will never have a reason to work with
pairs (A, b)?

> For the linear algebra we have Petsc + Hypre giving access to a range of
> parallel Krylov based solvers plus algebraic multigrid.

Yes. One thing we should do is to find out how to specify AMG as a
preconditioner without having to do it through the command-line with
-pc_type hypre -pc_hypre_type boomeramg.

> For efficiency the next big challenge is to have all components in DOLFIN
> parallelized; that means the mesh and the assembly routine. It seems that 
> Matt's Sieve will be the solution.

That should be the plan for the 0.6.x series. What things do we want
to finish before releasing 0.6.0? Manual + Navier-Stokes? What is the
status of the Navier-Stokes solver?

> As for abstraction of the implementation, hiding the linear algebra as you
> say is one thing. Another is to automate space-time FEM in FFC. That is,
> to give the forms for a space-time domain, instead of just for a space
> domain, as is the case today. The functionality of space-time FEM is
> already there, but the time discretization today has to be given
> explicitly to FFC. This would take the form-file code closer to the PDE
> formulation for time dependent problems.

Yes, we should do that, but the ODE solvers are not (yet)
parallel. And I don't think we are even completely satisfied with the
current sequential implementation yet. I think it's basically ok,
especially after the major rewrite Johan and I did last winter, but it
needs some more work (testing, tuning).

> Another thing to think about is to also automate the discretization of non
> linear problems. That is to give FFC the non-linear form to either
> discretize for the non-linear solvers of Petsc, or to linearize and
> dicretize for a linear solver.

Then we need to extend the FFC form language. The question is how to
do this properly. Matt Knepley has a grammar + AST (abstract syntax
tree) worked out for nonlinear forms and he can do differentiation.
Maybe we should use that?

/Anders