On Tue, 26 Aug, 2014 at 2:59 PM, 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.
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.
Sounds good. Clean, and I think uncontentious. I'll register an issue.
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'm happy with this. Let's give it a little longer (the rest of today
:)) for people to feedback and then register it as an issue.
Garth
Martin
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
