Subject: [UFL-dev] [HG UFL] Separate finite element classes from registration of new elements:

From: [email-masked] (UFL)
Date: Fri, 2 May 2008 18:57:00 +0200 (CEST)

One or more new changesets pushed to the primary ufl repository.
A short summary of the last three changesets is included below.

changeset:   96:41823e95323f7eca983911568c8d546f4db9ef80
tag:         tip
user:        Anders Logg <[email-masked]>
date:        Fri May 02 18:57:01 2008 +0200
files:       ROADMAP ufl/all.py ufl/basisfunctions.py ufl/elements.py ufl/finiteelement.py ufl/output.py
description:
Separate finite element classes from registration of new elements:

   element classes in finiteelement.py
   registration and list in elements.py

changeset:   95:fef145c99ee2fd50e891a17b33ce141e445890fe
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Thu Apr 10 23:00:19 2008 +0200
files:       ufl/base.py
description:
Fixed bug in Transpose.

changeset:   94:38bdb6ba347d767fe2a3b8afd8fd72246f2d866f
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Thu Apr 10 22:57:40 2008 +0200
files:       setup.py
description:
Fixed setup.py after directory changes, and fixed prefix installation bug inherited from UFC.

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ufl

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 2 May 2008 21:54:06 +0200

It would be great to finalize the finite element classes and argument
classes in UFL soon.

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 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]);")

--
Martin

2008/5/2 UFL <[email-masked]>:
> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev
>
>

---

From: Anders Logg <[email-masked]>
Date: Fri, 2 May 2008 23:25:53 +0200

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

> It would be great to finalize the finite element classes and argument

Agree.

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

> f = Function(element, "v[0] = sin(x[0]*y[1]);")

These all look like good things to have!

-- 
Anders