dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Sunday 18 October 2009 21:10:08 Anders Logg wrote:
> On Sun, Oct 18, 2009 at 08:37:21PM +0200, Johan Hake wrote:
> > 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
> 
> How about adding an optional function to the UFC interface for
> returning the UFL string:
> 
>   virtual std::string ufl_repr() const { return ""; }

Look like this is already described as a Blueprint, which comes from an old 
point in the TODO file.

  <https://blueprints.launchpad.net/ufc/+spec/string-description>

I think Martin added it when we discussed this a while back.

Johan

> This function can then be implemented optionally by form compilers
> that rely on UFL. We should not tie the UFC interface to UFL.
> 
> --
> Anders
> 
> > > 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
> >
> > _______________________________________________
> > FFC-dev mailing list
> > FFC-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/ffc-dev
>