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?
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/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
