ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

[Please ignore my previous empty reply, I pressed the wrong key...]

On Fri, May 02, 2008 at 09:54:06PM +0200, Martin Sandve Alnæs wrote:
> It would be great to finalize the finite element classes and argument
> classes in UFL soon.

Agree.

> That way, Function in PyDOLFIN can depend on ufl.Function instead of
> ffc.Function.
> At the moment, I'm using dolfin.cpp_Function (==dolfin::Function)
> since ffc.Function
> is mixed into dolfin.Function, and this small difference quickly
> propagates to many
> parts of the code. Since Function seems to be the next target for
> revision in DOLFIN,
> this seems like a good time.

I'm not sure it's that simple. If Function does not depend on
ffc.Function, then it will not be possible to assemble forms easily in
PyDOLFIN, unless large parts of FFC are rewritten to use UFL. This
should happen, but it will take some time.

> I have collected some ideas for simplified function definition in PyDOLFIN.
> The key to understand the below examples is that the second argument
> is interpreted solely based on its type, and thus it relies much on conventions.
> However, the element provides full information about the value shape and
> geometric and topological space dimensions, which makes many kinds of
> consistency checking possible.
> 
> # To use Python functions, we should only rely on
> # the number of arguments, which is easy to verify:
> def python_function(x, y):
>     return (x**2, y**2)
> f = Function(element, python_function)
> f = Function(element, lambda x,y: (x**2, y**2))
> # (Note that lambda functions may be removed from Python 3)
> 
> # Functions based on symbolic expressions are handy for code verification
> # (given an analytic solution, it's easy to compute the mathing source
> term from the PDE):
> f = Function(element, sympy_expression)
> 
> # If you have an object inheriting ufc::function from some
> # other source, we should be able to use it directly:
> # (SFC can f.ex. compile a swiginac expression to an ufc::function object)
> f = Function(element, ufc_function)
> 
> # UFL expressions can be passed to the form compiler in use, resulting
> in an ufc::function object:
> f = Function(element, ufl_expression)
> 
> # Using Instant, we can easily compile C++ code, the tricky part is defining
> # simple conventions so we don't have to parse the code string too much:
> ufc_function_string_to_compile = """
> class f: public ufc::function {
>   void eval(double * v, const double *x, ...) {
>     v[0] = sin(x[0]*y[1]);
>   }
> };
> """
> f = Function(element, ufc_function_string_to_compile)
> 
> # If "ufc::function" or "dolfin::Function" isn't found in string,
> # which is a trivial string search, we can add class details like
> # above automatically, relying on conventions for variable names:
> f = Function(element, "v[0] = sin(x[0]*y[1]);")

These all look like good things to have!

-- 
Anders