ffc team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/11/19 Johan Hake <hake@xxxxxxxxx>:
> Hello!
>
> We have been discussing to inherit the ffc.{Test,Trial,Basis}Function in
> dolfin, and instantiate the function with a functionspace instead of an
> element. Then in assemble.py we extract the functionspaces from the
> basisfunctions in Formdata (Anders promised this).
>
> I had a look in Formdata to try to just extract the basis functions, similare
> to the coefficients. But the problem is that these functions are not
> represented in the monomial as the original u and v as they were created by
> the user.
>
> I suppose this is a "feature" of the algrebra in ffc or have I missunderstood
> it? The function that is used to define the coefficients can be extracted
> using with c.f, should this be added for the basisfunctions too?

...

> Will this be an issue in ufl?

Let me think aloud:

- Subclassing BasisFunction (Test and Trial aren't classes) poses no
problems in itself.

- Attaching additional member variables and member functions in this
class is ok, as long as names don't collide.

- Implementing any special function "__foo__" other than __init__ in
the dolfin subclasses may cause trouble. This includes SWIG-generated
functions, which I think should be ok if the UFL class has precedence
over the SWIG-generated class in the inheritance list of the PyDOLFIN
class.

- BasisFunction and Function objects in a UFL Form are never replaced
with anything else, exactly with this in mind.

- Algorithms like "J = derivative(-F)", "b = action(a)" which
introduce additional arguments all have options to explicitly pass the
BasisFunction or Function to add.

- Retrieving the exact objects used for form arguments from a form
will be ok, that is the instances of ufl.Function or its PyDOLFIN
subclass.

I don't see any collisions with this design and ufl.

--
Martin