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. -- Anders > > > > Garth > > > > > Johan > > > > > >> Garth > > >> > > >>>>> Isn't it possible to use what repr(ufl_element) returns to define the > > >>>>> signature of an element or isn't the ufl_element available in > > >>>>> ffc.FiniteElement? > > >>>> > > >>>> Yes. I committed this change to FFC a short while ago. > > >>> > > >>> Ok! > > >>> > > >>> Johan > > >>> > > >>>> Garth > > >>>> > > >>>>> Johan > > >>>>> > > >>>>>>> If I look at the generated code in Poisson.h (the DOLFIN demo), the > > >>>>>>> signature is > > >>>>>>> > > >>>>>>> "FiniteElement('Lagrange', 'triangle', 1)" > > >>>>>>> > > >>>>>>> so the restricted one looks consistent to me. How does PyDOFLIN use > > >>>>>>> the signature? > > >>>>>>> > > >>>>>>> Garth > > >>>>>>> > > >>>>>>>> Johan > > >>>>>>>> > > >>>>>>>>> Garth > > >>>>>>>>> > > >>>>>>>>>> Garth > > >>>>>>>>>> > > >>>>>>>>>> File "solver.py", line 96, in solve > > >>>>>>>>>> (uhat, uu) = Uh.split() > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/function.py", line 150, in split > > >>>>>>>>>> return tuple(self._sub(i,deepcopy) for i in > > >>>>>>>>>> xrange(self._V.num_sub_spaces())) > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/function.py", line 150, in <genexpr> > > >>>>>>>>>> return tuple(self._sub(i,deepcopy) for i in > > >>>>>>>>>> xrange(self._V.num_sub_spaces())) > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/function.py", line 135, in _sub > > >>>>>>>>>> return Function(self, i) > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/function.py", line 80, in __init__ > > >>>>>>>>>> self._V = V.sub(i) > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/functionspace.py", line 88, in sub > > >>>>>>>>>> return FunctionSpaceFromCpp(cpp.SubSpace(self,i)) > > >>>>>>>>>> File > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s > > >>>>>>>>>>i te- pa cka > > >>>>>>>>>> > > >>>>>>>>>> ges/dolfin/functionspace.py", line 101, in __init__ > > >>>>>>>>>> self._ufl_element = eval(cppV.element().signature(), > > >>>>>>>>>> ufl.__dict__) File "<string>", line 1 > > >>>>>>>>>> FiniteElement('Lagrange', 'triangle', 1)|_{<interval of > > >>>>>>>>>> degree 1>} > > >>>>>>>>>> > > >>>>>>>>>>> changeset: 7377:40cca61143c6 > > >>>>>>>>>>> user: "Garth N. Wells <gn...@cam.ac.uk>" > > >>>>>>>>>>> date: Sat Oct 17 13:24:47 2009 +0100 > > >>>>>>>>>>> files: dolfin/mesh/SubDomain.h > > >>>>>>>>>>> description: > > >>>>>>>>>>> Small formatting fix. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> changeset: 7376:8ee974ed5f7e > > >>>>>>>>>>> user: Anders Logg <l...@simula.no> > > >>>>>>>>>>> date: Sat Oct 17 00:05:34 2009 +0200 > > >>>>>>>>>>> files: dolfin/function/Function.cpp > > >>>>>>>>>>> description: > > >>>>>>>>>>> Remove unnecessary lines in Function::eval noted by Marc S. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> --------------------------------------------------------------- > > >>>>>>>>>>>- --- -- - For more details, visit > > >>>>>>>>>>> http://www.fenics.org/hg/dolfin > > >>>>>>>>>>> _______________________________________________ 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 > > > _______________________________________________ > FFC-dev mailing list > ffc-...@fenics.org > http://www.fenics.org/mailman/listinfo/ffc-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev