ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Aug 20, 2008 at 10:44:46AM +0200, Kristian Oelgaard wrote:
> 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?
> 
> Kristian

UFL will not care about this. FFC will take an UFL object as input and
then from that generate either quadrature or tensor code. We will need
to add a predicate is_multilinear to UFL that checks whether or not
the form is multilinear (in which case tensor representation is
possible).

-- 
Anders

Attachment: signature.asc
Description: Digital signature