ffc team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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.

I still think the signature() -> UFL object is a neat feature!

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