| Thread Previous • Date Previous • Date Next • Thread Next |
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?
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! JohanGarth > 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 <gnw20@xxxxxxxxx>" >>>>>>> date: Sat Oct 17 13:24:47 2009 +0100 >>>>>>> files: dolfin/mesh/SubDomain.h >>>>>>> description: >>>>>>> Small formatting fix. >>>>>>> >>>>>>> >>>>>>> changeset: 7376:8ee974ed5f7e >>>>>>> user: Anders Logg <logg@xxxxxxxxx> >>>>>>> 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@xxxxxxxxxx >>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev>>>>>> >>>>>> _______________________________________________ >>>>>> 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
| Thread Previous • Date Previous • Date Next • Thread Next |
