Anders Logg wrote:
> On Sun, Oct 18, 2009 at 11:43:03PM +0200, Johan Hake wrote:
>> 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 <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.
>>>>>>>>> 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.
>
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> FFC-dev mailing list
> ffc-...@fenics.org
> http://www.fenics.org/mailman/listinfo/ffc-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev
