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 also don't understand how it can work at all since the quadrature > >points are not known at compile-time. Or do you a fixed set of reference > >polyhedra that you map to? > > > > The "CutCellIntegrator" object is asked for the quadrature points, > and it returns them. One way to do it is to sub-triangulate > polyhedra (I think that CGAL can do this). "CutCellIntegrator" would > usually be aware of intersecting surfaces, etc. It can also return > schemes on surfaces. > > I would like a quadrature generator on polyhedra to eventually be > part of DOLFIN. It is already. See the BarycenterQuadrature class in the Nitsche repository. I'm currently merging it. It computes the simplest possible quadrature (exact for linear polynomials) for arbitrary polyhedra. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
