fenics team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Martin Sandve Alnæs wrote:
> We've had plans for some time to define a Unified Form Language, which
> is to be the input language for both FFC and SyFi.
>
> Those who want to participate in the design should join the mailing
> list ufl-dev@xxxxxxxxxx:
> http://www.fenics.org/wiki/Contact
>
> We will begin by defining everything we need to include on this page:
> http://www.fenics.org/wiki/UFL

OK. I just added tensor-valued functions.

> Some initial thoughts:
>
> What I think we can quickly agree on is that it should:
> - be a fenics project
> - be a pure Python module
> - be very close to the current FFC form language
> - not depend on ffc, syfi, fiat, ginac, ...

All sounds good.

> There are some features missing from FFC that we need to add, and
> there might be some small adjustments. Some of the features we need
> may not be handled by all form compiler configurations (f.ex.
> quadrature code can easily handle exp(f), but not the tensor
> representation of FFC or symbolic integration of SyFi).

Tensor representation (and I guess SyFi) can work somewhat with such 
functions by interpolating them. The problem is computing a consistent 
linearisation for nonlinear problems when these functions are involved.

> Major features I myself need that is missing from the FFC form language:
> - basic functions like exp, ln, pow, sin, cos, ... (this is trivial)

Yes, these would be nice.

> - differentiation w.r.t. user-defined variables
> - automatic computation of the Jacobi for a nonlinear form

This would be great. In principle it shouldn't be too hard for problems 
with explicit non-linearities. A problem that we've run into is that 
forms of interest are often at the limits of what FFC can handle, and 
their linearisation is too much for FFC.

> I've written a prototype with the basics which you can get by:
>   hg clone http://www.fenics.org/hg/dev/ufl
> but remember this is just a prototype.
>
> (We _may_ consider building the implementation on top of SymPy, which
> will ease the implementation, give access to some more powerful
> symbolic tools, at the cost of a dependency and less control over the
> exact appearance.)

What's the status of SymPy? Is it very usable? Looks like it will be 
really neat if it realises its goals.

Garth

> --
> Martin
> _______________________________________________
> FEniCS-dev mailing list
> FEniCS-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/fenics-dev