ffc team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

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?
 
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. 

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