Subject: Re: [FFC-dev] [DOLFIN-dev] [HG DOLFIN] Make Mixed FunctionSpace access more consistant.

From: "Garth N. Wells" <[email-masked]>
Date: Sat, 17 Oct 2009 20:37:15 +0100

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 <[email-masked]>"
>>>> 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)))"
>

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-packa
>>> 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-packa
>>> 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-packa
>>> 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-packa
>>> 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-packa
>>> 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-packa
>>> 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 <[email-masked]>"
>>>> date:        Sat Oct 17 13:24:47 2009 +0100
>>>> files:       dolfin/mesh/SubDomain.h
>>>> description:
>>>> Small formatting fix.
>>>>
>>>>
>>>> changeset:   7376:8ee974ed5f7e
>>>> user:        Anders Logg <[email-masked]>
>>>> 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
>>>> [email-masked]
>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>> _______________________________________________
>>> DOLFIN-dev mailing list
>>> [email-masked]
>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>> _______________________________________________
>> DOLFIN-dev mailing list
>> [email-masked]
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 18 Oct 2009 15:43:28 +0100

Garth N. Wells wrote:
>> should return a string that can be executed in a ufl namespace and 
>> then generate the corresponding ufl.FiniteElement.
>>

I've had a look, and while I don't yet follow where UFL defines its 
signatures, things are dangerous because FFC formats its own signature 
strings, see line 227 of

     ffc/ffc/fem/finiteelement.py

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?

Garth

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 17:39:34 +0200

On Sunday 18 October 2009 16:43:28 Garth N. Wells wrote:
> 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
> 

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.

> 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

> >>>>      self._ufl_element = eval(cppV.element().signature(),
> >>>> ufl.__dict__) File "<string>", line 1
> >>>>> ---------------------------------------------------------------------
> >>>>>- For more details, visit http://www.fenics.org/hg/dolfin

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 18 Oct 2009 17:21:23 +0100

> Not sure how this could be done another way.

Can't we get the sub-element from the original UFL function? If I do

    (u0, u1) = pde.solve().split()

are u0 and u1 UFL Functions, or just cpp Functions?

> signature of an element or isn't the ufl_element available in 

Yes. I committed this change to FFC a short while ago.

Garth

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 19:53:47 +0200

On Sunday 18 October 2009 18:21:23 Garth N. Wells wrote:
> > 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.
> >
> > 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:
> >
> > 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.
> >
> 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

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.

> Yes. I committed this change to FFC a short while ago.

Ok!

Johan

> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-
> >>>>>>pa cka
> >>>>>>
> >>>>>>> -------------------------------------------------------------------
> >>>>>>>-- - For more details, visit http://www.fenics.org/hg/dolfin

---

From: "Garth N. Wells" <[email-masked]>
Date: 18 Oct 2009 19:07:41 +0100

On Oct 18 2009, Johan Hake wrote:

>> >>>>>>> One or more new changesets pushed to the primary dolfin 
>> >>>>>>> repository. A short summary of the last three changesets is 
>> >>>>>>> included below.
>> >>>>>>>
>> > 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 
> 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
>> 
> 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

>> >>> so the restricted one looks consistent to me. How does PyDOFLIN use 
>> >>> the signature?
>> >>>
>> >>> Garth
>> >>>
>> >>>> Johan
>> >>>>
>> >>>>> Garth
>> >>>>>
>> >>>>>> Garth
>> >>>>>>
>> >>>>>>> _______________________________________________ DOLFIN-dev 
>> >>>>>>> mailing list [email-masked]

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 20:22:06 +0200

On Sunday 18 October 2009 20:07:41 Garth N. Wells wrote:
> >> >>>>    "ElementRestriction(FiniteElement('Lagrange', Cell('triangle',
> >> >>>> 1, Space(2)), 1), Cell('interval', 1, Space(1)))"
> >> >>
> >> > 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.
> >> >

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

> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/si
> >> >>>>>>te- pa cka
> >> >>>>>>
> >> >>>>>>> ----------------------------------------------------------------
> >> >>>>>>>--- -- - For more details, visit http://www.fenics.org/hg/dolfin

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 18 Oct 2009 19:31:41 +0100

> However we do not have to compile them, as we needed to go the other way, from 

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().

Garth

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 20:37:21 +0200

On Sunday 18 October 2009 20:31:41 Garth N. Wells wrote:
> >>>>> well defined method that ufl use internally, when for example
> >>>>> creating a unique string representation of a form.
> >>>>>
> >>> 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.
> 

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

> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/s
> >>>>>>>>>>i te- pa cka
> >>>>>>>>>>
> >>>>>>>>>>> ---------------------------------------------------------------
> >>>>>>>>>>>- --- -- - For more details, visit
> >>>>>>>>>>> http://www.fenics.org/hg/dolfin

---

From: Anders Logg <[email-masked]>
Date: Sun, 18 Oct 2009 21:10:08 +0200

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

How about adding an optional function to the UFC interface for
returning the UFL string:

  virtual std::string ufl_repr() const { return ""; }

This function can then be implemented optionally by form compilers
that rely on UFL. We should not tie the UFC interface to UFL.

--
Anders

> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 18 Oct 2009 20:14:10 +0100

> that rely on UFL. We should not tie the UFC interface to UFL.

The really clever way would be to have PyDOLFIN create a sub-class of 
ufc::finite_element which implements ufl_repr().

Garth

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 21:26:11 +0200

On Sunday 18 October 2009 21:14:10 Garth N. Wells wrote:
> >>>>>>>>>>> should return a string that can be executed in a ufl namespace
> >>>>>>>>>>> and then generate the corresponding ufl.FiniteElement.
> >>>>>>>>>>>
> >>>>>>>>>>>    "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)
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>> 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:
> >>>>>>>>
> >>>>>>>> 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 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
> >>>>>>>
> >>>>>> 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.
> >>>
> >>> 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...
> >>

Ok.

> ufc::finite_element which implements ufl_repr().

It is not PyDOLFIN that compile the ulf.form. This is done in the jit function 
of the formcompiler together with the ufc.build_module function.

Not sure how easy (or correct) it is to interfere with the jit function.

Johan

---

From: Anders Logg <[email-masked]>
Date: Sun, 18 Oct 2009 21:29:51 +0200

> Not sure how easy (or correct) it is to interfere with the jit function.

It seems better to add it to the interface so that DOLFIN can check
whether the ufl_repr function is implemented or not. If it returns and
empty string, then it can return an appropriate error message.

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 21:36:08 +0200

On Sunday 18 October 2009 21:29:51 Anders Logg wrote:
> > > >>>>>>>>>>>>>> repository. A short summary of the last three changesets
> > > >>>>>>>>>>>>>> is included below.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>> should return a string that can be executed in a ufl
> > > >>>>>>>>>>> namespace and then generate the corresponding
> > > >>>>>>>>>>> ufl.FiniteElement.
> > > >>>>>>>>>>>
> > > >>>>>>>>> I've had a look, and while I don't yet follow where UFL
> > > >>>>>>>>> defines its signatures,
> > > >>>>>>>>
> > > >>>>>>>>   repr(ulf_object)
> > > >>>>>>>>
> > > >>>>>>>> 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:
> > > >>>>>>>>
> > > >>>>>>>> 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 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
> > > >>>>>>>
> > > >>>>>> 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()
> > > >>>>>
> > > >>>> However we do not have to compile them, as we needed to go the
> > > >>>> other way, from compiled to UFL.
> > > >>>
> > > >> 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...
> > > >>
> > It is not PyDOLFIN that compile the ulf.form. This is done in the jit
> > function of the formcompiler together with the ufc.build_module function.
> >

If this is in place we could let signature return a hash of the "old" 
signature, as we discussed in a previous thread.

Johan

---

From: Johan Hake <[email-masked]>
Date: Sun, 18 Oct 2009 23:43:03 +0200

On Sunday 18 October 2009 21:10:08 Anders Logg wrote:
> > > >>>>> is a well defined method that ufl use internally, when for
> > > >>>>> example creating a unique string representation of a form.
> > > >>>>>
> > > >>>>>> all sorts of problems. Is it desirable to have PyDOLFIN depend
> > > >>>>>> on the generated strings? Can it be avoided?
> > > >>>>>
> > went into the ufc documentation, but I now see that this is not the case.
> > For now...
> >

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

> > > >>>>> 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?
> > > >>>>
> > > >>>>>>> If I look at the generated code in Poisson.h (the DOLFIN demo),
> > > >>>>>>> the signature is
> > > >>>>>>>
> > > >>>>>>> so the restricted one looks consistent to me. How does PyDOFLIN
> > > >>>>>>> use the signature?
> > > >>>>>>>
> > > >>>>>>> Garth
> > > >>>>>>>
> > > >>>>>>>> Johan
> > > >>>>>>>>
> > > >>>>>>>>> Garth
> > > >>>>>>>>>
> > > >>>>>>>>>> Garth
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>> "/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2
> > > >>>>>>>>>>.6/s i te- pa cka
> > > >>>>>>>>>>
> > > >>>>>>>>>>> -----------------------------------------------------------
> > > >>>>>>>>>>>---- - --- -- - For more details, visit

---

From: Anders Logg <[email-masked]>
Date: Mon, 19 Oct 2009 13:21:23 +0200

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

ok. I've added some comments to that blueprint now.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 19 Oct 2009 12:23:35 +0100

> ok. I've added some comments to that blueprint now.

For the time being FFC is using the UFL repr(element) string in 
ufc::finite_element::signature.

Garth

> --
> Anders
> 
> 
> ------------------------------------------------------------------------
>