ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 20, 2009 at 06:18:37PM +0100, Garth N. Wells wrote:
>
>
> 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
>>
>> 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.
>>
>
> I find the use of 'degree' in the above contexts confusing. Is  
> 'max_quadrature_element_degree' the number of points? Is it the order of  
> accuracy?

It's the maximum degree of all quadrature elements in the form, which
is the degree argument given as input:

  element = FiniteElement("Quadrature", shape, degree)

Quadrature element shares this interface with other element families so
the name of the variable is "degree". UFL does not know anything about
what degree means for a quadrature element (nor does it know what it
means for RT elements).

The form compiler extracts this degree and in the case of FFC it sets
quadrature_order to be equal to this degree unless quadrature_order
has been specified by a user.

-- 
Anders



> Garth
>
>> estimate_max_polynomial_degree:
>> Estimates the highest polynomial degree of the expression.
>> It is an estimate since not all operators are polynomials.
>>
>> I've added a unit test, but only for some basic cases.
>>
>> Martin
>>
>>
>>
>> On Sun, Apr 19, 2009 at 8:46 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>>> On Sun, Apr 19, 2009 at 02:11:12PM +0800, Garth N. Wells wrote:
>>>>
>>>> Anders Logg wrote:
>>>>> On Fri, Apr 17, 2009 at 12:02:04PM +0200, Martin Sandve Alnæs wrote:
>>>>>> Take a look at
>>>>>>   ufl/sandbox/algorithmtests/degree_estimation.py
>>>>>> just added.
>>>>>>
>>>>>> Is this good enough for the initial version?
>>>>>> It handles mixed elements by using the max
>>>>>> degree of subelements, and nonlinear operators
>>>>>> by just using the degree of the operands.
>>>>>> Should work fine for most forms where accurate
>>>>>> estimation is possible.
>>>>>>
>>>> Should it be called 'estimate_max_poly_order' rather than
>>>> 'estimate_max_quadrature_order'?
>>> My suggestion would be
>>>
>>>  estimate_max_polynomial_degree
>>>
>>> Then it's very clear what it is.
>>>
>>>>>> I'll add it into UFL soon.
>>>>>>
>>>>>> Martin
>>>>> It looks good to me, but I haven't tried it.
>>>>>
>>>>> UFL now seems to have at least three ways to estimate the quadrature
>>>>> degree:
>>>>>
>>>>>   extract_quadrature_order
>>>> This gets the order of a quadrature element.
>>> ok. I find the naming a bit confusing. How about we change the name of
>>> this as well. Then we have two functions:
>>>
>>>  estimate_max_polynomial_degree
>>>  extract_max_quadrature_element_degree
>>>
>>> Maybe the first one should also be named 'extract'. Or is it
>>> 'estimate' because it might only make a qualified guess if the
>>> integrand is not a polynomial? So we could have
>>>
>>>  extract_max_polynomial_degree
>>>  extract_max_quadrature_element_degree
>>>
>>> Then it would be very clear what these two functions do.
>>>
>>> Martin?
>>>
>>>>>   estimate_quadrature_order
>>>> I don't follow exactly what this function is doing.
>>>>
>>>>>   estimate_max_quad_degree
>>> This is still in the sandbox.
>>>
>>> Do you have a good test example that can be added to the demos so we
>>> verify things work as expected?
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iEYEARECAAYFAknqyLAACgkQTuwUCDsYZdEPsACfbtx/920zZNHQOBUUyBIsDbTZ
>>> KLcAmgK6iXnkuYTCYoMN+tGbykPeTEy9
>>> =KkbD
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> UFL-dev mailing list
>>> UFL-dev@xxxxxxxxxx
>>> http://fenics.org/mailman/listinfo/ufl-dev
>>>
>>>
>
>

Attachment: signature.asc
Description: Digital signature