On Tue, 26 Aug 2014 15:20:29 +0100 "Garth N. Wells" <[email protected]> wrote:
> > > On Tue, 26 Aug, 2014 at 1:18 PM, 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. > > If it's polynomial, a user can associate a FiniteElement. Not necessarily. f may not be polynomial and 'polynomial degree' of f serves just for quadrature degree estimation. The distinction between FE expression and pointwise expression is then that former _is_ at first interpolated before evaluation at quadrature points and the latter _is not_. > > > 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. > > Yes, as is what happens in many FE codes where the quadrature scheme > is determined by the polynomial order of the product test and trial > functions. > > > > 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. > > The good reason is to not break a lot of user code. For a functional, > there is nothing to work with to 'guess' a quadrature scheme, so user > input is necessary. Consistent with rank > 0 cases would be drop the degree of f so that resulting quadrature degree is zero. I don't claim that it's good approach - it's just consistent. > > We're trying to work towards a solution, so constructive replies that > propose solutions would be more helpful. Ok. Jan > > Garth > > > > > 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
