ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 13, 2010 at 10:31:51AM +0200, Mehdi Nikbakht wrote:
> On Tue, 2010-04-13 at 09:45 +0200, Anders Logg wrote:
> > On Tue, Apr 13, 2010 at 07:17:28AM +0800, Garth N. Wells wrote:
> > >
> > >
> > > On 12/04/10 23:35, Anders Logg wrote:
> > > >On Mon, Apr 12, 2010 at 10:20:13PM +0800, Garth N. Wells wrote:
> > > >>
> > > >>
> > > >>On 12/04/10 21:49, Anders Logg wrote:
> > > >>>On Mon, Apr 12, 2010 at 09:34:38PM +0800, Garth N. Wells wrote:
> > > >>>>
> > > >>>>
> > > >>>>On 12/04/10 21:29, Anders Logg wrote:
> > > >>>>>On Mon, Apr 12, 2010 at 09:21:32PM +0800, Garth N. Wells wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>On 12/04/10 21:19, Garth N. Wells wrote:
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>On 12/04/10 20:47, Anders Logg wrote:
> > > >>>>>>>>We are doing some work where we need to do run-time quadrature over
> > > >>>>>>>>arbitrary polyhedra.
> > > >>>>>>>
> > > >>>>>>>We (Mehdi and I) do this already (using UFC), so I don't see why a new
> > > >>>>>>>function is required. Can you explain why evaluate_tensor is not enough?
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>I meant 'tabulate_tensor'.
> > > >>>>>
> > > >>>>>Which function do you call for evaluating the integrand?
> > > >>>>>
> > > >>>>
> > > >>>>We evaluate it inside ufc::tabulate_tensor. We construct our forms
> > > >>>>with an extra argument, say an object "CutCellIntegrator", which can
> > > >>>>provide quadrature schemes which depend on the considered cell.
> > > >>>
> > > >>>That would require a special purpose code generator.
> > > >>
> > > >>What's wrong with that? FFC won't (and shouldn't) be able to do
> > > >>everything. Just adding a function to UFC won't make FFC do what we
> > > >>do now. We reuse FFC (import modules) and add special purpose
> > > >>extensions.
> > > >
> > > >Exactly, it won't make FFC do what we need, but we could *use* FFC to
> > > >do what we need (without adding a special-purpose code generator).
> > > >
> > > >>>Having
> > > >>>evaluate_integrand would allow more flexibility for users to implement
> > > >>>their own special quadrature scheme.
> > > >>>
> > > >>
> > > >>We make "CutCellIntegrator" an abstract base class, so the user has
> > > >>*complete* freedom to define the quadrature scheme and the generated
> > > >>code does not depend on the scheme, since the scheme may depend on
> > > >>things like how the cell 'cut' is represented.
> > > >
> > > >Then it sounds to me like that generated code is not at all special,
> > > >but instead general purpose and should be added to UFC/FFC.
> > > >
> > > >And the most general interface would (I think) be an interface for
> > > >evaluating the integrand at a given point. We already have the same
> > > >for basis functions (evaluate_basis_function) so it is a natural
> > > >extension.
> > > >
> > >
> > > I still don't see the need for 'evaluate_integrand' unless you plan
> > > to call it directly from the assembler side (i.e. DOLFIN). Is that
> > > the case? Perhaps you can give me a concrete example of how you plan
> > > to use it.
> >
> > Yes, that's the plan. In pseudo-code, this is what we want to do:
> >
> >   for polyhedron in intersection.cut_cells:
> >
> >     quadrature_rule = QuadratureRule(polyhedron)
> >     AK = 0
> >
> >     for (x, w) in quadrature_rule:
> >
> >       AK += w * evaluate_integrand(x)
> >
> >     A += AK
> >
> > All data representing the geometry, the polyhedra, mappings from those
> > polyhedra to the original cells etc is in the Intersection class (in
> > the sandbox):
> >
> >   intersection = Intersection(mesh0, mesh1)
> >
> > Eventually, we might want to move part of the functionality into
> > either DOLFIN or FFC, but having access to and evaluate_integrand
> > function makes it possible to experiment (from the C++ side) without
> > the need for building complex abstractions at this point.
>
> As far as I understood you want to compute the integration points for
> polyhedrons inside Dolfin and evaluate_integrands will just compute that
> integrand in that specific integration points. If it is the case how
> would you determine what is the order of quadrature rule that you want
> to use?

The quadrature rule would be a simple option for the user to
set. Currently we only have one general rule implemented which is
barycentric quadrature.

> Since to evaluate integrands you need to tabulate basis functions and
> their derivatives on arbitrary points. How do you want to tabulate basis
> functions and their derivatives inside evaluate_integrands?

That's a good point. We would need to evaluate the basis functions and
their derivatives at a given arbitrary point which is not known at
compile-time.

> I think it is better not modifying UFC at this point. You can derive a
> class from ufc::foo_integrals which you can pass information on the
> geometry of polyhedra to compute the integration points.

I don't understand how that helps. Don't you run into the same
problem, that the location of the quadrature points is not known at
compile-time?

--
Anders

Attachment: signature.asc
Description: Digital signature