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

Kristian


>
> Jan
>
> >
> > If this is the consensus, we can add an issue(s) to Bitbucket. Please
> > reply with feedback.
> >
> > Garth
> >
> >
> > On Fri, 15 Aug, 2014 at 9:27 AM, Martin Sandve Alnæs
> > <[email protected]> wrote:
> > > On 14 August 2014 11:09, Martin Sandve Alnæs <[email protected]>
> > > wrote:
> > >> On 14 August 2014 10:38, Garth N. Wells <[email protected]> wrote:
> > >>> I favour (a) explicit provision of the element/function space; or
> > >>> (b) evaluation at quadrature points with errors for cases where
> > >>> no data is available for deciding on a sensible quadrature
> > >>> scheme. Using quadrature points would fix some other awkward
> > >>> issues, like specifying boundary conditions on polygon faces
> > >>> which 'creep' around corners is subdomains are not marked.
> > >>
> > >>
> > >> I agree with both (a) and (b).
> > >
> > > I see I was a bit quick there.
> > >
> > > I favour evaluation at quadrature points for cases where no
> > > element/function space is provided, combined with making the choice
> > > of quadrature degree/scheme easier accessible with dx(degree=3)
> > > notation. Maybe we can add in a "Warning: automatic selection of
> > > integration degree 3, this may be inexact.".
> > >
> > > The quadrature degree estimation is just that: an _estimation_. It
> > > is not exact for any non-polynomial expressions. If we want to
> > > throw an error when the degree for exact integration cannot be
> > > determined, that is a partially separate issue from this one, and
> > > it will break a lot of programs. If we want integration involving
> > > any Expression without an element to be guaranteed exact, we will
> > > need to require the integration degree to be set explicitly. This
> > > will probably break every single dolfin demo.
> > >
> > > Martin
> >
> > _______________________________________________
> > fenics mailing list
> > [email protected]
> > http://fenicsproject.org/mailman/listinfo/fenics
>
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to