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 ""; }
>
> This function can then be implemented optionally by form compilers
> 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
> --
> Anders
>
>
>
>
>>
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev
