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