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.
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.
We're trying to work towards a solution, so constructive replies that
propose solutions would be more helpful.
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
