| Thread Previous • Date Previous • Date Next • Thread Next |
kent-and@xxxxxxxxx wrote:
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 elementsSounds 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.
I think that it's more common to use a scheme that integrates the product of the test and trial functions exactly (coefficients are ignored).
Garth
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. Kentestimate_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_______________________________________________ UFL-dev mailing list UFL-dev@xxxxxxxxxx http://fenics.org/mailman/listinfo/ufl-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
