← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Make Mixed FunctionSpace access more consistant.

 

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!

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





Follow ups

References