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