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