dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Mon, 2006-04-24 at 09:07 +0200, Johan Hoffman wrote:
> It appears that the most straightforward (and general?) way to implement
> surface integrals would be to just integrate the cell basis functions over
> a boundary/interior facet. Possibly by first throwing away dofs that are
> zero on the facet. Using the "trace_tabulate" of FIAT this should be too
> much work?
> 
> On the DOLFIN side we would get element matrices corresponding to all dofs
> of the cell also when looping over (boundary) edges, typically with a lot
> of zero entries. There may be some optimizations here to consider, but the
> general algorithm seems rather clear, or?
> 

I wouldn't worry about any optimisations yet. The time to assemble over
boundary cells will be small relative to the assembly over all cells.
DOLFIN is pretty much ready for this - the code will mirror the assembly
over all cells.

> On the FFC side, the reference tensor needs to be modified (using FIAT
> trace_tabulate?) to reflect integration over an edge/face instead of over
> the whole cell.
> 

I started poking around the FFC code to understand FCC and look at
boundary integrals should be incorporated. Have you already started on
it Johan? If so, I'll wait on it, or if you need any help point me in
right direction.

Garth 

> /Johan
> 
> 
> > Yes, FFC will need to work with the basis functions for the space on
> > the entire element, for two reasons:
> >
> > 1. It won't work for other elements than Lagrange, since we may have
> > basis functions associated with other entities than the boundary
> > segment in question (the edge or the face) that don't vanish on the
> > boundary segment.
> >
> > 2. It won't work for Lagrange either, since you may want to integrate
> > derivatives along the boundary and then we need to differentiate all
> > basis functions since their derivatives don't vanish on the boundary.
> >
> > The boundary assembly will look something like the applyBC* functions
> > in FEM.cpp (or NewFEM.h :-) and will go something like this:
> >
> > Iterate over faces in mesh:
> >    cell = cell to which face belongs (function Face::cell())
> >    segment = compute which segment we are on
> >    A^K = call FFC code to compute tensor
> >    A += A^K as usual
> >
> > Johan Jansson and Karin Kraft has implemented a prototype version of
> > assembly over the boundary, where they hand-coded the code that FFC
> > should generate.
> >
> > The "unsigned int boundary" is needed since the element tensor should
> > be computed differently depending on which edge or face we are
> > integrating over (with respect to the reference element). I think we
> > should rename it to "segment" instead of "boundary".
> >
> > Thanks for pointing out the trace_tabulate function in FIAT, I was
> > gonna ask about that at some point.
> >
> > Another thing I just realized: Rob, you use the term "boundary facet".
> > Could we use that as a common term to name edges and faces? So we have
> >
> >     d        cell
> >     d - 1    facet
> >     d - 2    ???
> >     ...
> >     0        vertex
> >
> > /Anders
> >
> >
> > On Wed, Apr 12, 2006 at 10:37:13AM -0500, Robert C. Kirby wrote:
> >> There is a "trace_tabulate" method in FIAT that computes the values
> >> of the basis functions on a boundary facet (or the interior, if you
> >> like), FFC should make use of that and then throw away things that
> >> are zero.
> >>
> >>
> >> On Apr 12, 2006, at 10:22 AM, Johan Hoffman wrote:
> >>
> >> >Ok, good to know. Any ideas on what would be the best solution?
> >> >
> >> >/Johan
> >> >
> >> >
> >> >>You most definitely don't want to use the d-1 dimensional element of
> >> >>the same type.  Works great for Lagrange (and actually Hermite, for
> >> >>what it's worth), but is disastrously catastrophic for everything
> >> >>else.
> >> >>
> >> >>
> >> >>On Apr 12, 2006, at 8:29 AM, Garth N. Wells wrote:
> >> >>
> >> >>>On Wed, 2006-04-12 at 15:09 +0200, Garth N. Wells wrote:
> >> >>>>On Wed, 2006-04-12 at 14:30 +0200, Johan Hoffman wrote:
> >> >>>>
> >> >>>>>Apart from the issue of duplicating code with or without
> >> >>>>>templates, what
> >> >>>>>do we need to figure out to get the assembly of boundary integrals
> >> >>>>>correct?
> >> >>>>>
> >> >>>>>Do we have a clear way to obtain the FE basis for the boundary of
> >> >>>>>a cell
> >> >>>>>given the basis of the cell? Do we use the corresponding basis
> >> >>>>>for for d-1
> >> >>>>>dimensions?
> >> >>>>>
> >> >>>>>/Johan
> >> >>>>>
> >> >>>>
> >> >>>>This will have to come from FFC won't it? It might be less
> >> >>>>efficient,
> >> >>>>but we could work with the finite element of the whole cell and
> >> >>>>perhaps
> >> >>>>the edge/face number is enough for FFC to do the rest.
> >> >>>
> >> >>>Thinking about this some more, it might be better not to restrict
> >> >>>the
> >> >>>finite element basis to the boundary in order to work with problems
> >> >>>where derivatives of the basis functions appear in the boundary
> >> >>>integrals, and hence involve all nodes of the element. Similar
> >> >>>story for
> >> >>>non-conforming elements.
> >> >>>
> >> >>>Garth
> >> >>>
> >> >>>
> >> >>>>I noticed that
> >> >>>>the FFC-produced function eval takes "unsigned int boundary" as an
> >> >>>>argument, but doesn't do anything with it yet.
> >> >>>>
> >> >>>>Garth
> >> >>>>
> >> >>>>
> >> >>>>_______________________________________________
> >> >>>>DOLFIN-dev mailing list
> >> >>>>DOLFIN-dev@xxxxxxxxxx
> >> >>>>http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >>>
> >> >>>
> >> >>>_______________________________________________
> >> >>>DOLFIN-dev mailing list
> >> >>>DOLFIN-dev@xxxxxxxxxx
> >> >>>http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >>
> >> >>
> >> >>_______________________________________________
> >> >>DOLFIN-dev mailing list
> >> >>DOLFIN-dev@xxxxxxxxxx
> >> >>http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >> >>
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >DOLFIN-dev mailing list
> >> >DOLFIN-dev@xxxxxxxxxx
> >> >http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >>
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >>
> >
> > --
> > Anders Logg
> > Research Assistant Professor
> > Toyota Technological Institute at Chicago
> > http://www.tti-c.org/logg/
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> >
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev