ufl team mailing list archive

[kent-and@xxxxxxxxx]

> On Sun, Apr 19, 2009 at 2:48 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>> On Sun, Apr 19, 2009 at 02:02:57PM +0200, Martin Sandve Alnæs wrote:
>>> With some renaming, we now have:
>>>
>>> extract_max_quadrature_element_degree:
>>> Returns max degree of found quadrature elements, None with no
>>> quadrature elements
>>
>> Sounds good.
>>
>>> estimate_quadrature_degree:
>>> Uses the formula 2*v.element().degree() for linear forms,
>>> v.element().degree()+u.element().degree() for bilinear forms,
>>> don't know if we need this? Returns None for functionals now.
>>> The form compilers could have an option to use this variant.
>>
>> Is it to be used as a fallback if the others fail?
>
> No, from what I understand this is the default in e.g. Diffpack,
> and may often be sufficient? I don't know the conditions for this.
> I was thinking that we can give the choice between the two
> approaches to the user through options to the form compilers.
>
> Kent, what do you say?



Yes, this was the default in Diffpack. I think
this is common for elliptic equations even with coefficients.

As long as the default option are well documented and the order can be
changed easily, I think this is a reasonable default option. But I
don't have any strong opinion. I do however think it might be difficult to
find a general formula that is good in the sense that it will not
overestimate or underestimate in various situations.

Kent


>
>>> estimate_max_polynomial_degree:
>>> Estimates the highest polynomial degree of the expression.
>>> It is an estimate since not all operators are polynomials.
>>
>> Does it return something sensible even if the expression is not a
>> polynomial?
>
> Yes, the default rule for unhandled types are to return the max
> degree of the operands, so the degree of exp(f**2) will be the
> same as the degree of f**2. We could define heuristic rules like
> degree(exp(f)) -> 2*degree(f), if that makes any sense.
>
>> If so, then estimate_quadrature_degree may not be needed.
>>
>> It would be enough for a form compiler to do this:
>>
>>  quadrature_degree = extract_max_quadrature_element_degree(integral)
>>  if quadrature_degree is None:
>>      quadrature_degree = estimate_max_polynomial_degree(integral)
>>
>> Perhaps this should be in UFL?
>
> As I said above, I think this should be controllable by form compiler
> options,
> so in that case no. Also, Kristian wants splitting of expression terms
> by polynomial degree in the future, which will be yet another way to
> handle this.
>
> Martin
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev
>