ffc team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Sunday 18 October 2009 20:31:41 Garth N. Wells wrote:
> 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 <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?
> >
> > 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().

True. However that is something we discussed a year ago when we implemented 
the transition to FunctionSpace in PyDOLFIN. I thought this went into the ufc 
documentation, but I now see that this is not the case. For now...

Lets get a blueprint at ufc and here what folks says.

Johan



> 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/s
> >>>>>>>>>>i 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/s
> >>>>>>>>>>i 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/s
> >>>>>>>>>>i 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/s
> >>>>>>>>>>i 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/s
> >>>>>>>>>>i 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/s
> >>>>>>>>>>i 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 <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
>