dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Sunday 18 October 2009 21:29:51 Anders Logg wrote:
> On Sun, Oct 18, 2009 at 09:26:11PM +0200, Johan Hake wrote:
> > 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
> 
> It seems better to add it to the interface so that DOLFIN can check
> whether the ufl_repr function is implemented or not. If it returns and
> empty string, then it can return an appropriate error message.

If this is in place we could let signature return a hash of the "old" 
signature, as we discussed in a previous thread.

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