ffc team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 13/04/10 00:16, Andre Massing wrote:
> Hi!
>
> Anders and I are working on an implementation for Nitsche's method, where the
> question of integration on cut cell and facets also (beside XFEM for you) came
> up.
>
> On Monday 12. April 2010 16.20.13 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.
>
> I think code generator is cool :) But in this case and maybe also other use-
> cases for DOLFIN it presents a high barrier to try out new FEM schemes.
> And for example adding an evaluate integrand function would *DOLFIN* make to
> do what we want to to with Nitsche (see below).
>
> > > 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.
>
> That's sounds like a pretty cool and sophisticated framework but to me it is
> not clear how our implementation would easily fit into this framework. Although
> there are quite a lot similiarities as integration on cut cells and facets my
> understanding of the pum code is not deep enough to see
> how we could *easily* reuse your code in our case. Maybe you could give a hint
> of how it would possible?  For example how tight is your ffc code generation
> implementation for XFEM connected with the use of the CutCellIntegrator class?

You wouldn't be able to re-use all the code, but we could share some 
common base classes, for example for locating quadrature points, which 
in turn would depend on how the surface is represented, and for 
integrating on surfaces.

> Since Nitsche methods can be understand as a kind of domain decompositon we
> have *several* (overlapping) meshes.
> Then we want is to integrate forms (possibly different equation) on each (not
> covered part of the) mesh and some additonal interface integrals along the
> interfaces. Basically we have almost everything in place. We have an
> intersection map, mapping each cell/facet to the covering cells/facets and we
> have at least a barycenter quadrature rule for arbitrary cut cells and facet
> at hand.
>
> So for trying out another FEM scheme in DOLFIN all we need is to assemble it
> and merging the domain specific matrices. Everything can already be done in
> DOLFIN with resonable effort except the actual calculation of the integrals.

We do this now more-or-less in tabulate_tensor with our PUM object 
providing the necessary data for taking care of the merging.

Garth

> To summarize, this only one evaluate_integrand  function would help to make
> DOLFIN/FENICS flexible enough for an average programmer like me to implement
> new, semi-automated :) FEM schemes  with a reasonable amount of time.
>
>
> > > 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.
> >
> > Garth
> >
> > > --
> > > Anders
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~ffc
> > Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ffc
> > More help   : https://help.launchpad.net/ListHelp