dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 05. sep. 2010 00:00, Johan Hake wrote:
> On Sep 4, 2010, at 11:16, Marie Rognes <meg@xxxxxxxxx> wrote:
>
>   
>> On 04. sep. 2010 18:26, Johan Hake wrote:
>>     
>>> On Saturday September 4 2010 03:54:35 Marie Rognes wrote:
>>>
>>>       
>>>> On 04. sep. 2010 01:36, Johan Hake wrote:
>>>>
>>>>         
>>>>> Hello!
>>>>>
>>>>> Garth found an ambiguity in the Expression doc string regarding how a
>>>>> user should initiate a user defined Expression (not a compiled one) in
>>>>> Python. If the Expression is vector or tensor valued the user need to
>>>>> provide information about this.
>>>>>
>>>>> This can be done in two ways. Either overload the dim method or provide a
>>>>> ufl FiniteElement while instantiating the Expression. Neither of these
>>>>> methods are documented in the docstring.
>>>>>
>>>>> In the mixed poisson demo both dim and rank are overloaded. I think rank
>>>>> is not needed (works fine without). However dim is just a method
>>>>> introduced to be able to automatically select a FiniteElement.
>>>>>
>>>>>           
>>>> Thanks for bringing this up -- evidently I'm confused.
>>>>
>>>>         
>>> Well, me too. Ever since Anders introduced the automatic selection of elements 
>>> for the Expressions, I have been some what confused.
>>>
>>>
>>>       
>>
>> Well, that part made perfect sense to me --- I think ;)
>>     
> :)
>
>   
>>>>> First I am not sure dim is the correct name. We could use value_size as
>>>>> this is present in the GenericFunction interface for just this purpose.
>>>>> Second I am not sure overloading a method is the best and most clear way
>>>>> to provide this information. Maybee he could do it while instantiating
>>>>> the Expression instead?
>>>>>
>>>>> class BoundarySource(Expression):
>>>>>     def eval_data(self, values, data):
>>>>>         g = sin(5*data.x()[0])
>>>>>         values[0] = g*data.normal()[0]
>>>>>         values[1] = g*data.normal()[1]
>>>>>
>>>>> s = BoundarySource(value_size=2)
>>>>>
>>>>>           
>>>> I don't really like the name value_size, but this looks natural to me.
>>>> What would it be for matrix-valued functions?
>>>>
>>>>         
>>> As I have understand it, value_size is the size of the values array passed to 
>>> the Expression. So that would then be:
>>>
>>> value_size = m x n
>>>
>>> I am not totally happy with the above code as the class should contain 
>>> everything it needs to be instantiated correctly.
>>>
>>> Would it make more sense to change the name of dim to value_size?
>>>
>>>
>>>       
>>
>> Exactly what do you mean here? Keep needing to supply a method "dim",
>> but renaming it to "value_size" ? (I still don't find the name
>> value_size very intuitive.)
>>     
> Something like that. The point is that a user need to provide this information so the Expression can be properly evaluated. 
>   


How about

     s = Expression(value_shape=I)

where I is a multiindex such as (m,) or (m, n) or (m, n, q, ...) etc.
Maybe with the options of

    Expression(value_shape=m) <=> Expression(value_shape=(m,))

And no overloading of dim or rank?


>>     
>>>>> Or just use the FiniteElement which is a litle bit over kill but already
>>>>> possible as it is.
>>>>>
>>>>> s = BoundarySource(element=BDM.ufl_element())
>>>>>
>>>>> What you say?
>>>>>
>>>>>           
>>>> When prescribing an element (or a function space) to anything that
>>>> resembles a function, I assume that the function (in this case, the
>>>> Expression) is interpolated into the function space defined by that
>>>> element. Is that correct? 
>>>>
>>>>         
>>> Yes, that is correct. We need a FiniteElement to be able to initiate the 
>>> ufl.Coefficient. If not provided we automatically choose one based on (for now 
>>> the dim method) what the user provides.
>>>
>>>
>>>       
>>
>> But no element space is needed in this case. If the "s" is never used in
>> a form (as is the case in the mixed Poisson example), then it only needs
>> to be evaluate-able. Hence, we should not require an element or function
>> space to be set for Expressions. I seem to remember this being one of
>> the main points with the Function vs Expression design.
>>     
> He he no need to take that disc one more time. 


Ok :)

> The point is that a user can optionally provide a FiniteElement. In this case the expression will get the correct value_size. 
>   


My point was simply that it should not be required.


--
Marie