dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxxx>]

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

Maybe we should go with PDE. The projection is also a PDE, and further
ahead we might want to work with nonlinear forms.

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

Yes, this we should take care of.

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

The Navier-Stokes solver has been working fine for some weeks. Possibly I
have do update the boundary conditions after the changes in the
BoundaryCondition class. The benchmark problem setup is a standard
benchmark problem for 2d flow past a circular cylinder. If one wants to do
3d one just have to change the form-file elements to tetrahedrons and
change the boundary conditions to 3d. The solution is written to an
m-file.

That leaves the Manual, which is in progress.

>> 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).

To have FFC work with the ODE solver is one thing. What I meant is to have
FFC automatically discretize a PDE in space-time, that is we do not write
out the discretization of the derivatives in time for example ((u-u0)/k)
but instead we write u.dt().

The heat equation would then be something like:

a = v.dx(i)*u*dx(i)*dx*dt
f = v*f*dx*dt

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

Maybe this is something for a future release, we can to fine with the
linearization for now. But this is something worth planning for ahead. I
do not know much about Matt's nonlinear forms but it sounds interesting,
has he written anything about it?

/Johan

> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>