On 4 June 2014 11:55, Anders Logg <[email protected]> wrote: > > On Wed, Jun 04, 2014 at 11:02:53AM +0200, Martin Sandve Alnæs wrote: > > I see that facet_normals has been added as an argument to > > custom_integral::tabulate_tensor. If you actually want to use FacetNormal with > > custom integrals, I think the better way is to have custom_integral and > > custom_facet_integral, with the latter taking 'int facet' just like > > exterior_facet_integral, referring to the first cell. That will allow any facet > > related geometric quantity to be computed just as for other facet integrals. > > The failing on the next buildbot is not because facet normals were > added in UFC, but because a change in UFL allowing custom integrals to > use facet normals got lost in the merge. I pushed a fix earlier and it > should soon be green. > > Regarding adding custom_facet_integral, it's not enough to send in an > int for the facet because the facet in question may not be a facet of > any of the cells in the list. It is something that only the assembler > knows about.
Ok. > The signature of custom_integral allows sending in an arbitrary number > of cells (not just two), a list of quadrature points (which may or may > not be on a facet, just some arbitrary subset of the intersection of > the cells), and the value of the facet normal (if any) at each of the > quadrature points (the normal may be different for different > quadrature points). Ok, so that allows for curved surfaces handled from the outside? Does that mean "double * facet_normals" is an array of size num_points * gdim? I'm still not quite happy with an unused pointer facet_normals in the interface for non-facet custom integrals. A custom_facet_integral with the facet_normals argument would both fix that and allow better error checking in ufl. > This allows for integrating along a surface cutting arbitrarily > through an arbitrary number of overlapping cells. > > On a related note, the num_cells metadata hack should be made to fit with > > development of domain representation in ufl. > > Yes. This is something I want to discuss with you when I have thought > more about how to polish up the interface for custom > integrals/multimesh. Great, I have some ideas but don't know how your code fits together in detail. Something to discuss in Paris :) Martin
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
