dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Nov 02, 2005 at 09:59:53AM +0100, Johan Hoffman wrote:

> I think the most intuitive way for the user to provide the variational
> form is to use a time derivative Dt(u). Then the desciption of the
> (variational form of the) equation would be something like what you
> describe above, which is very close to mathematical notation.
> 
> The next step is to determine how to discretize the equation. Today there
> are several options avaliable in DOLFIN:
> 
> (1) Semi-discretization time->space: this is what is done today in DOLFIN
> for PDEs, although the time discretization is done manually. The natural
> next step would be for FFC to do the discretization in time from Dt(u),
> given a specification in the form-file, either as a space-time element:
> 
> space_discretization = FiniteElement("Lagrange", "tetrahedron", 1)
> time_discretization = FiniteElement("discontinuous Lagrange", "interval", 2)
> space_time_discretization = space_discretization + time_discretization
> 
> for cG(1)dG(2), or as a semidiscretization:
> 
> space_discretization = FiniteElement("Lagrange", "tetrahedron", 1)
> time_discretization = FD_scheme("Crank-Nicolson")
> space_time_discretization = space_discretization + time_discretization

Perhaps, but it would probably be more appropriate with 

    space_discretization * time_discretization ?

> for cG(1) with Crank-Nicolson in time. Functions may then be defined using
> the space-time discretizations. The same output files from FFC to DOLFIN
> would then be generated as is done today; that is computation of element
> matrices and vectors.
> 
> (2) Semidiscreization space->time: this would be along the lines what
> Johan is doing now; computing f(u) to use in the ODE solver (for dot u =
> f(u)). We would then still declare a space element:
> 
> space_discretization = FiniteElement("Lagrange", "tetrahedron", 1)
> 
> but the time derivative Dt(u) would not be discretized by FFC, but instead
> would an output file for the ODE solver in DOLFIN be created that contain
> the evaluation of f(u).

This is the most convenient. The ODE solver wants an ODE.

> (3) We also might like to generate the vector F(u) for using the non
> linear solver on F(u)=0, although this can be done already today with FFC
> defining an L in this form. For Newton we would also like to generate the
> Jacobian automatically, which will demand some new functionality.
> 
> (4) A next step is moving meshes. Johan is doing this for elasticity I
> guess in a pure Lagrangian framework, but we also want to allow for ALE
> methods where the mesh is moving independetly from the solution. This
> corresponds to a coordinate transformation so that the derivatives and
> integrals (dx,ds etc.) needs to be modified according to a specified map.
> This would probably be quite easy to do in FFC by implementing
> map-dependent operators, where derivatives and integrals are interpreted
> using the chain rule wrt a given mapping.

I think we should be able to get this working with alternative (2),
but we need to think about the details.

/Anders

> 
> >> > I suggest we add a new class PDE (it's already there) and build some
> >> > intelligence into this class. In particular, it should know if the
> >> > problem is time-dependent or static. As a start, if FFC sees that a
> >> > pair of forms (a, L) is specified it could collect the two forms into
> >> > a PDE.
> >> >
> >>
> >> This is a good start.
> 
> Should PDE also know about the discretization? For example, if the forms
> are on the format (1) or (2); that is if the forms are prepared for the
> ODE solver or if it should be assembled to a matrix? So that the PDE class
> corresponds to a discretized PDE?
> 
> > Should the PDE class be generated as a class called PDE in the
> > namespace of the form? For Poisson, that would mean that we have a
> > class
> >
> >     Poisson::PDE
> >
> > which would contain a pair of forms
> >
> >     Poisson::BilinearForm
> >     Poisson::LinearForm
> >
> > Or should we replace the namespace Poisson with a class named Poisson
> > that is a subclass of PDE and put the two forms within its namespace.
> > The first alternative would probably work better with SWIG and it's
> > also more consistent with the current naming:
> >
> >     Poisson::BilinearForm a;
> >     Poisson::LinearForm L(f);
> >     Poisson::PDE pde;
> >
> > What do you think?
> 
> In the first alternative, we would still keep a base class called PDE in
> the DOLFIN kernel I guess? As we do for BilinearForm etc. I think this is
> the best solution, rather than introducing classes for all different
> problems that are generated.
> 
> /Johan
> 
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >
> 
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/