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. >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. 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
