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 <h...@simula.no>" > > > >>>>>>>>>>>>>> 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@fenics.org > > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > _______________________________________________ > > DOLFIN-dev mailing list > > DOLFIN-dev@fenics.org > > http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev