On Wed, Jun 04, 2014 at 12:54:58PM +0200, Martin Sandve Alnæs wrote: > 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?
Yes. > Does that mean "double * facet_normals" is an array of size num_points * gdim? Yes. > 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. If we add another integral type, then I guess we would want custom_cell_integral custom_facet_integral I don't have a very strong against this, but arguments in favor of just one integral type would be: 1. It is really a *custom* integral, so the form compiler should not really know what's going on. It just gets a bunch of points and does the quadrature. A custom integral can be used for anything, facets or not. 2. Fewer new integral types. > > 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 :) Sounds good! -- Anders _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
