dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #07769
Re: [UFL-dev] [HG UFL] Separate finite element classes from registration of new elements:
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 <ufl@xxxxxxxxxx>:
> 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 <logg@xxxxxxxxx>
> 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 <martinal@xxxxxxxxx>"
> 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 <martinal@xxxxxxxxx>"
> 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
>
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev
>
>
Follow ups