ffc team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Sunday 18 October 2009 21:14:10 Garth N. Wells wrote:
> Anders Logg wrote:
> > On Sun, Oct 18, 2009 at 08:37:21PM +0200, Johan Hake wrote:
> >> On Sunday 18 October 2009 20:31:41 Garth N. Wells wrote:
> >>> Johan Hake wrote:
> >>>> On Sunday 18 October 2009 20:07:41 Garth N. Wells wrote:
> >>>>> On Oct 18 2009, Johan Hake wrote:
> >>>>>> On Sunday 18 October 2009 18:21:23 Garth N. Wells wrote:
> >>>>>>> Johan Hake wrote:
> >>>>>>>> On Sunday 18 October 2009 16:43:28 Garth N. Wells wrote:
> >>>>>>>>> Garth N. Wells wrote:
> >>>>>>>>>> Johan Hake wrote:
> >>>>>>>>>>> On Saturday 17 October 2009 21:08:14 Garth N. Wells wrote:
> >>>>>>>>>>>> Garth N. Wells wrote:
> >>>>>>>>>>>>> DOLFIN wrote:
> >>>>>>>>>>>>>> One or more new changesets pushed to the primary dolfin
> >>>>>>>>>>>>>> repository. A short summary of the last three changesets is
> >>>>>>>>>>>>>> included below.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> changeset:   7378:e5c921e0293a
> >>>>>>>>>>>>>> tag:         tip
> >>>>>>>>>>>>>> user:        "Johan Hake <hake@xxxxxxxxx>"
> >>>>>>>>>>>>>> date:        Sat Oct 17 15:45:36 2009 +0200
> >>>>>>>>>>>>>> files:       site-packages/dolfin/function.py
> >>>>>>>>>>>>>> site-packages/dolfin/functionspace.py description:
> >>>>>>>>>>>>>> Make Mixed FunctionSpace access more consistant.
> >>>>>>>>>>>>>>   - All methods are now defined in FunctionSpaceBase.
> >>>>>>>>>>>>>>   - We now do not save any spaces in MixedFunctionSpace
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This change broke my code. See below.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Seems that the problem arises with spaces which are
> >>>>>>>>>>>> restricted,
> >>>>>>>>>>>>
> >>>>>>>>>>>>      V = FunctionSpace(mesh, "CG", 1, "facet")
> >>>>>>>>>>>
> >>>>>>>>>>> This is an error in the generated FFC code.
> >>>>>>>>>>>    ufc::finite_element::signature()
> >>>>>>>>>>> should return a string that can be executed in a ufl namespace
> >>>>>>>>>>> and then generate the corresponding ufl.FiniteElement.
> >>>>>>>>>>>
> >>>>>>>>>>> For a restricted element the signature returns:
> >>>>>>>>>>>
> >>>>>>>>>>>    "FiniteElement('Lagrange', 'triangle', 1)|_{<interval of
> >>>>>>>>>>> degree 1>}"
> >>>>>>>>>>>
> >>>>>>>>>>> where it should return:
> >>>>>>>>>>>
> >>>>>>>>>>>    "ElementRestriction(FiniteElement('Lagrange',
> >>>>>>>>>>> Cell('triangle', 1, Space(2)), 1), Cell('interval', 1,
> >>>>>>>>>>> Space(1)))"
> >>>>>>>>>
> >>>>>>>>> I've had a look, and while I don't yet follow where UFL defines
> >>>>>>>>> its signatures,
> >>>>>>>>
> >>>>>>>>   repr(ulf_object)
> >>>>>>>>
> >>>>>>>> returns the uniqe signature of an ufl_object.
> >>>>>>>>
> >>>>>>>>> things are dangerous because FFC formats its own signature
> >>>>>>>>> strings, see line 227 of
> >>>>>>>>>
> >>>>>>>>>      ffc/ffc/fem/finiteelement.py
> >>>>>>>>
> >>>>>>>> Yes, this is dangerous, at least if we want to use them as we do
> >>>>>>>> in PyDOLFIN. However taking repr of the corresponding ufl object
> >>>>>>>> is a well defined method that ufl use internally, when for example
> >>>>>>>> creating a unique string representation of a form.
> >>>>>>>>
> >>>>>>>>> We stopped using signature strings in DOLFIN because it gave us
> >>>>>>>>> all sorts of problems. Is it desirable to have PyDOLFIN depend on
> >>>>>>>>> the generated strings? Can it be avoided?
> >>>>>>>>
> >>>>>>>> It is a very nice way of constructing an ufl object when we have
> >>>>>>>> the compiled version. As the convention of repr(object) is that:
> >>>>>>>>
> >>>>>>>>   new_object = eval(repr(object))
> >>>>>>>>
> >>>>>>>> should return a new object of the same kind.
> >>>>>>>>
> >>>>>>>> So when we have a SubSpace with its compiled FiniteElement, it is
> >>>>>>>> easy to just call its signature method of its element to generate
> >>>>>>>> the corresponding ufl element, which is used to construct a full
> >>>>>>>> fledged dolfin.FunctionSpace.
> >>>>>>>>
> >>>>>>>> Not sure how this could be done another way.
> >>>>>>>
> >>>>>>> Can't we get the sub-element from the original UFL function?
> >>>>>>
> >>>>>> Not when we return a SubSpace which is a compiled C++ structure. To
> >>>>>> be able to construct the ufl.FiniteElement (done in the class
> >>>>>> FunctionSpaceFromCpp in functionspace.py) we use the signature of
> >>>>>> the cpp.FiniteElement.
> >>>>>>
> >>>>>>> If I do
> >>>>>>>
> >>>>>>>     (u0, u1) = pde.solve().split()
> >>>>>>>
> >>>>>>> are u0 and u1 UFL Functions, or just cpp Functions?
> >>>>>>
> >>>>>> They should be both. Their FunctionSpaces (self._V) are constructed
> >>>>>> using the the FunctionSpace.sub(i) (operator[]) method, which
> >>>>>> returns the compiled SubSpace I am talking about above.
> >>>>>
> >>>>> OK, but if we have
> >>>>>
> >>>>>   U = pde.solve()
> >>>>>
> >>>>> and U is a UFL Function, can't the UFL finiteelement for U be
> >>>>> accessed, and then the UFL sub-element(s) accessed and then compiled?
> >>>>
> >>>> Yes, this should be possible! (Did not think of getting the sub
> >>>> element from a mixed ufl.element :P)
> >>>>
> >>>> However we do not have to compile them, as we needed to go the other
> >>>> way, from compiled to UFL.
> >>>
> >>> OK. Now the situation is clear to me.
> >>>
> >>>> I still think the signature() -> UFL object is a neat feature!
> >>>
> >>> The problem is that there is nothing that says that a form compiler
> >>> that uses UFL and produces UFC-compliant code must return the UFL
> >>> signature (repr) in ufc::finite_element::signature().
> >>
> >> True. However that is something we discussed a year ago when we
> >> implemented the transition to FunctionSpace in PyDOLFIN. I thought this
> >> went into the ufc documentation, but I now see that this is not the
> >> case. For now...
> >>
> >> Lets get a blueprint at ufc and here what folks says.
> >>
> >> Johan
> >
> > How about adding an optional function to the UFC interface for
> > returning the UFL string:
> >
> >   virtual std::string ufl_repr() const { return ""; }
> >
> > This function can then be implemented optionally by form compilers
> > that rely on UFL. We should not tie the UFC interface to UFL.

Ok.

> The really clever way would be to have PyDOLFIN create a sub-class of
> ufc::finite_element which implements ufl_repr().

It is not PyDOLFIN that compile the ulf.form. This is done in the jit function 
of the formcompiler together with the ufc.build_module function.

Not sure how easy (or correct) it is to interfere with the jit function.

Johan

> Garth
> 
> > --
> > Anders
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>