Subject: [FFC-dev] Formdata and basis functions.

From: Johan Hake <[email-masked]>
Date: Wed, 19 Nov 2008 20:20:54 +0100

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? 

Johan

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 20 Nov 2008 00:05:59 +0100

> 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

---

From: Johan Hake <[email-masked]>
Date: Thu, 20 Nov 2008 09:03:16 +0100

On Thursday 20 November 2008 00:05:59 Martin Sandve Alnæs wrote:
> > 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?
>
> ...
>

This won't be the case. A dolfin.BasisFunction will inherit 
ufl/ffc.BasisFunction, nothing else. It will have a FunctionSpace.

> class is ok, as long as names don't collide.

Ok. I have added a function_space funciton to extract the FunctionSpace.

> over the SWIG-generated class in the inheritance list of the PyDOLFIN

This won't be the case. 

> with anything else, exactly with this in mind.

Nice.

> BasisFunction or Function to add.

Nice.

> will be ok, that is the instances of ufl.Function or its PyDOLFIN

Nice.

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

So, when is it due? ;)

Johan

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 20 Nov 2008 10:20:48 +0100

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

In a finite number of days. ;)

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Thu, 20 Nov 2008 10:37:14 +0100

> with anything else, exactly with this in mind.

FFC calls the copy constructor of BasisFunction in many of the
algorithms to create new copies of BasisFunctions in new expressions.

I've added a public member "data" now to BasisFunction that will be
copied along to all copies. It defaults to None.

Will also add extraction of basis function data to FormData.

-- 
Anders