dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 05. sep. 2010 12:02, Garth N. Wells wrote:
>
>
> On 05/09/10 10:29, Marie Rognes wrote:
>> 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?
>>
>
> Looks very Python centric. The issue of the shape isn't Python
> specific - it needs to be refined/sorted out in the C++ interface too.


Ok. So what is the problem in the c++ interface?`


>
>>
>>>>
>>>>>>> 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.
>
> What do you mean by never used in a form? What's it used for if not in
> a form?
>


I mean "it is never used in a form" ;) In the mixed-poisson demo, it is
used as data for the DirichletBC. In this case, interpolation should not
be required, and is in particular not desired.


>>>> 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.
>>
>
> My original point from looking at the doc string  was less subtle than
> these. It was that doc string doesn't make clear that a user can
> provide a finite element to a non-JIT Expression subclass, thereby
> prescribing the space in which the expression should be interpolated
> rather than letting FFC decide.
>


Ok, so there are two issues:

(a) that the doc-string is not adequate
(b) that the interface for how the value_[size|shape|dimension|rank] is
prescribed for Expressions (when one does not want to specify a function
space/element) is suboptimal

?

--
Marie



> Garth
>
>>
>> -- Marie
>>
>>
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~dolfin Post to     :
>> dolfin@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~dolfin More help   :
>> https://help.launchpad.net/ListHelp