On 27 August 2014 11:45, Martin Sandve Alnæs <[email protected]> wrote:
> Just to see how single argument, different types would work out:
>
> Expression("x[0]") # old behaviour with warning
> Expression("x[0]", "pointwise")
> Expression("x[0]", ufl_element)
> Expression("x[0]", degree_int)
> Expression("x[0]", function_space)
>
I think this looks good.
>
> The last one because I also want to transition towards Expression having a
> full FunctionSpace.
>
> I think this is doable. However, after suitable deprecation periods, I
> want only this:
>
> Expression("x[0]") # pointwise
> Expression("x[0]", function_space) # interpolated
> Expression("x[0]", virtual_degree) # pointwise, degree for
> auto-integration only
>
I don't think we need the virtual_degree case.
I'd prefer to force users to pass an argument to dx.
The virtual_degree of a PointwiseExpression is, to me, just something that
could make things easier when estimating the polynomial degree to avoid
explicit handling of PointwiseExpression objects.
When I think about it, I think we should try to avoid the concept of
virtual_degree as it doesn't make much sense for an expression that is
evaluate at arbitrary points.
Kristian
>
> (I concede the virtual degree will be practical and not a problem).
>
> Martin
>
>
>
>
> On 27 August 2014 11:36, Garth N. Wells <[email protected]> wrote:
>
>>
>>
>> On Wed, 27 Aug, 2014 at 10:21 AM, Kristian Ølgaard <
>> [email protected]> wrote:
>>
>>> 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)
>>>
>>
>> We need to allow passing of different types, but it could be just one
>> argument and the Expression constructor can do whatever it needs to do
>> depending on the type.
>>
>>
>> This should then default to the current behaviour and interpolate the
>>> expression using a linear element.
>>>
>>
>>
>> For now, yes. The default isn't a linear element. I think there is some
>> magic to pick a suitable order.
>>
>>
>> One can then supply the element to get the 'exact' integration
>>>
>>> Expression('x[0]*x[0]', pointwise=False, element=quadratic_element)
>>>
>>
>> No need to pass pointwise. Just an element would do.
>>
>>
>> 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.
>>>
>>
>> If one did
>>
>> f = Expression('x[0]*x[0]', pointwise=True)
>> assemeble(f*dx)
>>
>> it should throw an error. Integrating f would require something like
>>
>> assemeble(f*dx(degree=2))
>>
>>
>>
>> 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.
>>>
>>
>> Yes.
>>
>> Garth
>>
>>
>> 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
