ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> 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?

Martin


>
> Kristian
>
>> Florian
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>>
>> iEYEARECAAYFAk3pQ8YACgkQ8Z6llsctAxbMhQCgoCGLFrA9lLBc30QPo3cAYuST
>> qZgAnRX7Vl7nAUyUHc/D23ofRHSDUshU
>> =FdMJ
>> -----END PGP SIGNATURE-----
>>
>>
>