dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

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?

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.

/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
>