2008/10/21 Johan Hake <hake@xxxxxxxxx>:
On Tuesday 21 October 2008 22:34:04 Martin Sandve Alnæs wrote:
2008/10/21 Johan Hake <hake@xxxxxxxxx>:
On Tuesday 21 October 2008 21:37:13 Martin Sandve Alnæs wrote:
2008/10/21 Anders Logg <logg@xxxxxxxxx>:
On Tue, Oct 21, 2008 at 06:01:53PM +0100, Garth N. Wells wrote:
Anders Logg wrote:
On Tue, Oct 21, 2008 at 04:45:01PM +0100, Garth N. Wells wrote:
I have a few questions and thoughts regarding the new Function
design
* It's not clear to me what the intention is with user-defined
functions. The functions Function::interpolate(...) never call
eval(..), so they can't pick up user-defined values. Should
Function::interpolate test for the presence of a GenericVector to
decide whether or not the Function is discrete or user-defined?
Yes, sorry. I've missed this. I'll fix it.
* It would be useful to declare user-defined functions without
associating a FunctionSpace. If we want to interpolate the
function, a FunctionSpace must then be provided. Anyone see any
problems with this?
The reasoning here is that all Functions must always be associated
with a FunctionSpace so that they may be correctly interpreted in
forms and correctly plotted. When a Function is created in
PyDOLFIN, it must always be associated with a certain FiniteElement
(and in a while FunctionSpace). It would simplify the handling of
Functions if they are always associated with a FunctionSpace.
I agree that is makes life simple if every function has a space, but
it is a bit clunky for declaring user-defined functions. The forms
must be declared first to extract the finite element to create the
function space. Could look nasty when a lot of functions are
involved.
We have a function Function::interpolate which takes a function space
V as an argument and it interpolates the function u in V. What if we
permit undefined function spaces (which perhaps only have a domain)?
We would then interpolate the user defined function u in the provided
space V.
Garth
Are user-defined functions ever used without being related to a
particular element/function space?
It don't think it will be very clumsy. The clumsy thing will be to (in
C++) get from something compiled by a form compiler to a
FunctionSpace.
If we can make that operation smooth, then creating (user-defined)
functions will be very simple and convenient. One just needs to supply
the variable V holding the function space.
The current way of extracting function space data from the form is not
very nice (in C++). What would be the optimal way to initialize a
FunctionSpace in C++? We could think of extending the code generation
to generate code that makes this convenient.
--
Anders
The current way of extracting function space data from the form is not
very nice in Python either, since it doesn't work with compiled
functions. (Never mind that the current code is FFC-specific, this will
be the same with UFL).
Using Python functors can easily make the assembly slower than solving
the linear system, so it's not really interesting to do in real
applications...
To make a function object that is both of a C++ subclass of
dolfin::Function and of the Python class ufl.Function, we can't use the
fixed multiple inheritance
solution in the current PyDOLFIN.
We would have to define a new class dynamically in python, inheriting
from both ufl.Function and the freshly compiled C++ Function subclass.
After all this work cleaning up the Function class hierarchy, is that
really something you want?
I'm not sure if that is even possible to do while maintaining
efficiency, with cross-language inheritance and SWIG directors and all
that.
If anyone has another solution, I'm very interested in hearing it!
Otherwise, I'm all for keeping the ufl.Function objects used in form
definition separated from dolfin.Function objects used in assembly.
I agree with Martin that we need to have a solution for PyDOLFIN users
that does not depend on using python functors, as it will take forever
for a complex form together with a moderate mesh to just assemble the
form.
Is it possible to let compile_functions compile a cpp function, with a
FunctionSpace and all, instead of a mesh as it is today. Then after doing
If you have a dolfin::FunctionSpace object already, there's no reason
compile_functions can't take this instead of dolfin::Mesh.
That's exactly the same and no problem at all.
this compile_function extract the element, and instantiate a
UFL/FFC/PyFunction-function, and "attach" the compiled version to it.
This
What I state above is that this "attachment" must be done with
dynamic creation of a new class with multiple inheritance.
And I am unsure whether this will work out properly with SWIG directors
etc. I believe it _may_ work, but I don't dare to keep my hopes up :-)
Ok, I get it. For a moment I thought we could get away by defineing our own
PyDOLFIN::Function class that could inherit from UFL/FFC, and then have a
cpp_Function, but I realise this will not work.
See the attached python file for a prototype of dynamic class creation
with multiple inheritance using pure python classes.
(I think this is called "aspect oriented programming" by some people)
can be used to define forms, but more important it can be handed to the
python assembly that check if the function has a compiled version
attached to it and send this to the cpp_assembler?
If the "attachment" is anything other than inheritance, it will have
to be checked with manually written python code _everywhere_
a dolfin::Function is expected... We can't have one kind of functions
for assembly and one for other stuff.
Ok, I guess we have three different cases:
1) PyFunctions inherting from both UFL/FFC and cpp_Function as today,
taking a functionsspace in its constructor. This will work with both
user defined and discrete functions, more or less as we have it today.
2) The special functions, MeshSize, etc, can also be defined in the same
way as now, right?
3) Using compile_functions, that creates a multi inheritance object that
can be sent to any function expecting a cpp_Function, without manually
extending the python interface.
I'm with you up to this point.
Could the last be done by letting compile_function create a muliti inheritance
Function. Instantiate the cpp_one with the function space and by that
creating a dummy cpp_function. Then "attach" the compiled function to a
protected attribute and define eval, by overloading it in python. This will
then just call the attached and compiled cpp_functions eval.
What you describe here sounds like the envelope-letter design
that was just _removed_ from dolfin. What I'm suggesting is that
compile_functions dynamically creates a Python class that inherits
from ufl.Function and the freshly compiled C++ class, which is
a dolfin::Function subclass. Then it can construct an object of this
new class, passing a FunctionSpace object given by the user to
the dolfin::Function constructor, and an ufl.FiniteElement to the
ufl.Function constructor. This of course requires that dolfin.FunctionSpace
is a Python subclass of dolfin::FunctionSpace with an additional
ufl.FiniteElement member variable. Using jit, dolfin.FunctionSpace
can compile the ufc::finite_element and ufc::dof_map classes it needs
from an ufl.FiniteElement. And then there's the issue of reusing
dofmaps, where DofMapSet enters the play...
This will hopefully work in all cases that expect a cpp_Function? In assembly
where we need speed we extract the compiled function and send that one to
cpp_assembly.
I'm not sure what you mean by extracting.
Neat? No... but could work!
And it is pretty much guaranteed to blow the minds
of any non-experts who tries to understand it.
--
Martin
