dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 12, 2006 at 12:53:42PM +0200, Johan Jansson wrote:
> Hi!
> 
> I've put up my dissertation:
> 
> http://www.math.chalmers.se/~johanjan/publications/dissertation.pdf
> 
> One of the included papers describes aspects of DOLFIN as an automated
> problem solving environment. Some aspects of that are automatic
> time-(and space-)discretization of time-dependent PDE and the ability
> to use Python (or an arbitrary language) to access the DOLFIN
> interface.

Very good. I think we should put more effort into the DOLFIN Python
interface. I will make sure the new mesh library works transparently
in PyDOLFIN.

> TimeDependentPDE abstracts the automatic discretization. Currently the
> design is that the user implements the right-hand side f() of the PDE:
> 
> dot(u) = f(u, grad(u))
> 
> where grad(u) represents that f(u) can also be a function of
> space-derivatives of u.

Should we add something like Dt() to FFC? So one can write stuff like

    a = v*Dt(U)*dx + dot(grad(v), grad(U))*dx
    L = v*f*dx

Maybe one could treat this differently from

    a = v*Dt(U)*dx
    L = v*f*dx - dot(grad(v), grad(U))*dx

In the first case, we keep the Laplacian (or any other terms) on the
left-hand side in an implicit method and in the second case, we throw
everything into the right-hand side an let the ODE solver take care of
it.

> Right now I have implemented multi-field PDEs manually, i.e. by having
> a different form for the different fields, and keeping track of the
> fields separately. This should be solved by subfunctions, and is in
> the plan.
> 
> I have moved to implementing solvers (the elasticity solvers for
> example) in Python and this is working very well. Certain special
> functions where you perform some manual computation which is not
> represented in the form can be implemented as static functions in C++
> and published as a Python API using SWIG. My plan is to do as much
> development as possible in Python.

How should we differentiate between C++ and Python demos in src/demo?
Or should they be mixed freely so some demos are C++ and some Python?
I think src/demo/scripting is not prominent enough.

> Ko is also now an "official" component of FEniCS, representing an
> automated solid mechanics solver with support for large deformation,
> elasto-visco-plasto materials and contact with an efficiency
> comparable to a mass-spring solver. I have plans to develop some
> real-time application around Ko.

Maybe you could throw some of the new results into the gallery?

/Anders