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