On 27 August 2014 10:44, Garth N. Wells <[email protected]> wrote:
>
>
> On Wed, 27 Aug, 2014 at 9:15 AM, Martin Sandve Alnæs <[email protected]>
> wrote:
>
>> On 27 August 2014 08:25, Kristian Ølgaard <[email protected]> wrote:
>>
>>> On 26 August 2014 15:59, Martin Sandve Alnæs <[email protected]> wrote:
>>>
>>>> On 26 August 2014 15:21, Kristian Ølgaard <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Kristian Ølgaard <[email protected]>
>>>>> Date: 26 August 2014 15:20
>>>>> Subject: Re: [FEniCS] `Expression`s and their silent interpolation
>>>>> To: Jan Blechta <[email protected]>
>>>>>
>>>>>
>>>>> On 26 August 2014 14:18, Jan Blechta <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> On Tue, 26 Aug 2014 09:50:23 +0100
>>>>>> "Garth N. Wells" <[email protected]> wrote:
>>>>>>
>>>>>> > To summarise this thread, it seems we need to introduce the concept
>>>>>> > of an 'Expression' that can be evaluated at arbitrary points. It
>>>>>> > should not be a Quadrature{Element/Function} because the proposed
>>>>>> > object could be used in different forms with different evaluation
>>>>>>
>>>>>
>>>> Agree. Also it should not have any notion of degree. Pointwise is
>>>> pointwise.
>>>>
>>>>
>>>> > points. The follow-on on issue is then how a 'point-wise' expression
>>>>>> > should be treated in forms. We could estimate the quadrature scheme
>>>>>> > when test/trial functions are present, and in the case of
>>>>>> functionals
>>>>>> > throw an error if the user doesn't supply the quadrature degree.
>>>>>>
>>>>>> There's no principal difference regarding rank of the form. Consider
>>>>>>
>>>>>> f = PointwiseExpression(eval_formula)
>>>>>> u, v = TrialFunction(V), TestFunction(V)
>>>>>> a = f*u*v*dx
>>>>>> L = f*v*dx
>>>>>> F = f*dx
>>>>>>
>>>>>> Still, you need to know what is the polynomial degree of f to have
>>>>>> exact quadrature of any of these forms. Ignoring non-zero degree of f
>>>>>> (which seems to me you do suggest for a and L) means that you're
>>>>>> underintegrating any of those three forms. This is analogical to
>>>>>> integrating F with scheme of order zero. I don't see any good reason
>>>>>> why having distinct behaviour based on rank of the respective form.
>>>>>>
>>>>>
>>>> Agree.
>>>>> For PointwiseExpression, one should define EITHER the polynomial
>>>>> degree that the user would like the use for the approximation (of e.g.,
>>>>> 'sin(x)') OR the (degree of) quadrature rule for the measure.
>>>>> The latter should take precedence if both are defined, just as it does
>>>>> currently.
>>>>>
>>>>
>>>> Please, no. Isn't that basically the situation we're trying to get away
>>>> from? A pointwise expression doesn't have a degree and it's not a good
>>>> abstraction to assign one to it. The rules become complex which makes the
>>>> source code hard to follow, the documentation poor, and confuses the users
>>>> and developers alike.
>>>>
>>>
>>> Perhaps I got a little confused. Is PointwiseExpression supposed to
>>> replace Expression or will they co-exist?
>>>
>>> If PointwiseExpression will replace Expression, my suggestion to forcing
>>> the user to supply the degree (or element) was intended to solve Nico's
>>> original problem.
>>>
>>
>> Good question. There are two sides to that:
>>
>> From the UFL/FFC/UFC/Assembler side there needs to be two distinct
>> concepts: If a function is pointwise evaluated FFC must generate function
>> calls instead of using basis tables and dofs. Whether this is implemented
>> by adding a PointwiseExpression or a "Pointwise" family to UFL is an
>> implementation detail that affects other work in progress so lets not go
>> there in this thread at least. This is basically the new functionality
>> we're discussing here, and I don't think anyone disagrees with this, apart
>> from annotating the PointwiseExpression with a "virtual degree" for
>> integration degree purposes.
>>
>>
Agree, let's discuss this later.
> From the DOLFIN user interface side, there are several ways to go, and
>> this is where most opinions in this thread differ.
>>
>> The main interface point is whether to introduce new notation
>> PointwiseExpression("x[0]") and deprecate Expression("x[0]"), or to change
>> Expression("x[0]") to mean pointwise and remove the implicit interpolation.
>>
>> Deprecating Expression("x[0]") breaks all demos and lots of user programs.
>>
>> Changing the behaviour of Expression("x[0]") changes the numerical
>> results of lots of programs.
>>
>
> I'd be reluctant to introduce yet another object in the form of
> PointwiseExpression. How about passing a string or element argument to
> Expression? For now, the default could be the present behaviour
> (interpolation) with a warning that the default will change in release
> 1.foo to pointwise?
>
Do we need two arguments to do that?
Expression('x[0]*x[0]', pointwise=False, element=None)
This should then default to the current behaviour and interpolate the
expression using a linear element.
One can then supply the element to get the 'exact' integration
Expression('x[0]*x[0]', pointwise=False, element=quadratic_element)
and test the implementation of the pointwise feature by
Expression('x[0]*x[0]', pointwise=True)
which, depending on implementation details, will have a virtual degree
equal to zero.
In the future we can either set pointwise=True by default, or remove this
argument such that failing to provide the element implies pointwise
evaluation.
Kristian
>
> Garth
>
>
>
> Martin
>>
>>
>> These are two distinct issues:
>>>> 1) We need a "PointwiseExpression" with no degree and no hidden
>>>> interpolation under the hood. This expression is evaluated in quadrature
>>>> points - this is a clean concept and easy to understand.
>>>>
>>>
>>> If PointwiseExpression and Expression will co-exist, I agree to this
>>> definition. If it makes implementation cleaner for quadrature degree
>>> estimation, we can set the degree equal to zero, but hidden from users.
>>>
>>>
>>> 2) Degree estimation is not exact and some people are confused by that.
>>>> But it is not exact today, never was claimed to be, and never will be. If
>>>> that's not acceptable, we can just as well disable it completely. Disabling
>>>> it where it isn't exact will break a _lot_ of programs. What we _can_ do
>>>> without breaking programs or making the interface more cumbersome than
>>>> today, is to make it more obvious how to control the integration degree,
>>>> and to document it better.
>>>>
>>>
>>> I don't think anyone can disagree with this.
>>>
>>> Kristian
>>>
>>>
>>>> Martin
>>>>
>>>
>>>
>>
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
