dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Fri, Sep 23, 2005 at 09:18:58AM +0200, Johan Hoffman wrote:

...

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

I think a nice solution for this would simply to write all PDEs in the form:

dot(u) = f(u, t)

(which is what Anders is talking about in his dissertation)

The heat equation:

dot(u) - laplace(u) = g(t)

would be:

integral(dot(u)*v) = integral(grad(u)*grad(v) + g(t)*v)

then we would need something to handle the mass matrix integral(u*v)
on the left hand side. An initial version could perhaps simply do
lumping.

This would mean that the space discretization is handled by f() and
the time discretization by the ODE solver which is fed the dot(u) =
f(u, t) problem. I suppose there would need to be an extra interface
between the discretizations for mesh refinement, but hopefully it
won't be too complicated. Any comments on this from someone who has
done mesh refinement for time-dependent problems?

For non-linear problems, f(u, t) needs to be recomputed anyway. And
computing the action f(u, t) is cheaper than to first compute the
matrix, then compute the matrix-vector product.

For linear problems, an optimization could be made by pre-computing
the Jacobian df/du. The standard right hand side of a PDE could be
computed by f(0, t). Perhaps f(u, t) could be split up into two
different parts, one dependent on u and one not, to simplify this type
of optimization. The overhead of this approach compared to explicitly
assembling the matrix and vector part should be very small (just a
small startup cost).

For time-independent problems, we have dot(u) = 0. So the ODE solver
could have a special case for that, and simply solve 0 = f(u, 0).

What do you think? It would be even nicer if the solver would be able
to detect if the problem was non-linear or linear, or time-dependent
or not, automatically, and select the most optimal solution
strategy. But initially perhaps this information can be supplied with
the PDE.

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

I think what I'm proposing is orthogonal to that. I guess it's just an
issue of computing f(u, t)?

  Johan