ufl team mailing list archive

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

2008/8/20 Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>:
> Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
>
>> 2008/8/20 Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>:
>> >
>> > Hi,
>> >
>> > Just a quick question:
>> >
>> > Do you plan on including quadrature code generation in UFL?
>> >
>> > Kristian
>>
>> More or less all my uses for UFL will be with quadrature.
>> Although UFL doesn't care about how you integrate,
>> this should be possible:
>>
>> e = FiniteElement("Quadrature", triangle)
>> f = Function(e)
>>
>> I'm also considering
>>
>> e = FiniteElement("Boundary Quadrature", triangle)
>> f = Function(e)
>>
>> for functions that need to be evaluated on the boundary.
>>
>> Maybe quadrature order could be specified in FiniteElement?
>>
>> e = FiniteElement("Boundary Quadrature", triangle, 4)
>>
>> The default can be up to the form compiler, and the
>> form compiler is free to override anyway.
>> But we shouldn't allow this of course:
>>
>> e1 = FiniteElement("Quadrature", triangle, 2)
>> e2 = FiniteElement("Quadrature", triangle, 4)
>
> This is close to the syntax we have in FFC now:
>
> e1 = QuadratureElement(triangle, 2)
> e2 = QuadratureElement(triangle, 4)
>
> so it looks fine by me.
>
> But this was not what I meant. I'm talking about the
> output that UFL will generate in the tabulate_tensor() function. In FFC we have
> tensor representation and quadrature representation. Will we also have both in
> UFL?

UFL isn't a form compiler. However, I have some algorithms written and
some planned that will aid in the implementation of our form compilers.

FFC must make its tensor representation based on the UFL input,
and combine that with elements from FIAT in some way.
SFC will get its basis functions from SyFi and do its thing.
I will update SFC to use UFL, somebody else must update FFC
when the time comes.

--
Martin