ufl team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

On 11 June 2011 00:53, Florian Rathgeber
<florian.rathgeber@xxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/06/11 09:18, Martin Sandve Alnæs wrote:
>> On 4 June 2011 00:40, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
>>> On 3 June 2011 22:27, Florian Rathgeber
>>> <florian.rathgeber@xxxxxxxxxxxxxx> wrote:
>>
>> On 03/06/11 21:02, Kristian Ølgaard wrote:
>>>>>> On 3 June 2011 21:38, Florian Rathgeber
>>>>>> <florian.rathgeber@xxxxxxxxxxxxxx> wrote:
>>>>>> On 24/05/11 14:31, Martin Sandve Alnæs wrote:
>>>>>>>>> On 24 May 2011 11:39, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
>>>>>>>>>> On 24 May 2011 11:23, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>>>>>>>>>>> On 23 May 2011 12:05, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
>>>>>>>>>>>> On 23 May 2011 11:20, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>>>>>>>>>>>>> Is this documented somewhere? Since it is a UFL argument, it should be
>>>>>>>>>>>>> documented in UFL.
>>>>>>>>>>>>
>>>>>>>>>>>> It's not documented anywhere I think. True, it is a UFL argument, but
>>>>>>>>>>>> UFL doesn't know anything about quadrature schemes and I don't think
>>>>>>>>>>>> it needs to. The argument just has to be a string, then it's up to the
>>>>>>>>>>>> form compilers how to deal with the argument.
>>>>>>>>>>>> FFC currently supports two different schemes, the 'default' scheme
>>>>>>>>>>>> which is the hardcoded quadrature schemes which Garth implemented and
>>>>>>>>>>>> the 'canonical' scheme which is a Gauss--Legendre--Jacobi quadrature
>>>>>>>>>>>> scheme mapped onto simplices.
>>>>>>>>>>>
>>>>>>>>>>> Ok. And why does a FiniteElement need to have an associated a quad scheme?
>>>>>>>>>>
>>>>>>>>>> Because the dofs of quadrature elements are located at the quadrature
>>>>>>>>>> points with a value of 1 at those points and zero elsewhere.
>>>>>>>>>> Derivatives are not defined. This enables this type of element to be
>>>>>>>>>> handled like any other finite element by the form compilers.
>>>>>>>>>> However, it also means that FiniteElement("Quadrature", triangle, 2)
>>>>>>>>>> will have 4 dofs if the 'canonical' scheme is used and only 3 dofs if
>>>>>>>>>> the 'default' scheme is used.
>>>>>>>>>> Therefore the scheme has to be included when identifying unique elements.
>>>>>>>>>
>>>>>>>>> Thanks, that makes perfect sense.
>>>>>>
>>>>>> Kristian, could you provide an example how this is used? I have a use
>>>>>> case where I want to specify a quadrature scheme and this would come in
>>>>>> really handy. However I don't currently see how to access this
>>>>>> information in the form compiler.
>>>>>>
>>>>>>> Currently, only the FFC compiler supports different quadrature schemes.
>>>>>>> This is selected from the command line using the '-q scheme' options
>>>>>>> where 'scheme'
>>>>>>> can be one of 'default' or 'canonical'. 'default' is, well, the default.
>>>>>>> To use a different scheme you can add one to
>>>>>>> ffc/ffc/quadrature_schemes.py and perhaps submit a patch if you think
>>>>>>> it might be useful for others.
>>>>>>
>>>>>>> The 'quadrature_scheme' argument to FiniteElements in UFL is not used
>>>>>>> by the form compilers at the moment so it can be ignored for now.
>>
>> Sorry, I was imprecise. The quadrature_scheme parameter to a
>> FiniteElement would usually be a string specifying the name of the
>> scheme to be parsed by the form compiler?
>>>>
>>>> Yes, but it could be anything. I don't think UFL does any type checks
>>>> on the argument at the moment, but if it did it should probably only
>>>> be a check if it is a string or not. What the argument actually means
>>>> is left completely to the form compilers.
>>>>
>> I want to use the
>> quadrature_scheme argument in UFL to pass the quadrature degree
>> (gaussian quadrature) for our own form compiler (which is completely
>> separate from FFC) and would hence abuse it to carry an int. Since UFL
>> doesn't interpret the parameter in any way I should be fine doing that,
>> right?
>>>>
>>>> That's exactly how I think it should be used from UFL.
>>
>>> Can't you use the degree parameter instead for the degree?
>
> Do you suggest to compute the quadrature degree needed to integrate an
> element of polynomial degree "degree" exactly? Could do, but currently
> the quadrature degree is given in the input file format, so the form
> compiler is not smart about choosing the quadrature degree. This might
> change however.

But if you already pass the quadrature degree to the compiler in the
input file, then why do want to pass it as part of the
FiniteElement? Then you'll have to add it in all element definitions.
I suggest to let UFL compute the polynomial degree of a given integral
using the ufl.algorithm.estimate_total_polynomial_degree function and
from that determine what quadrature degree you need for the scheme
that you're using.
If you find this degree to be too high, you can always set a threshold
in your input file.

Kristian

> What is form_degree for btw.?
>
> Florian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3yoG4ACgkQ8Z6llsctAxZrnACfYM9jn3Iz3B388mTkcoa2+8fy
> tvoAnRhUeCyhn/mPNigCMzwmj0Opy7J8
> =fu+p
> -----END PGP SIGNATURE-----
>
>