A compromise for safety would be to add "bool requires_facet_normals() const" to custom_integral so the assembler can do a consistency check.
On 4 June 2014 13:04, Anders Logg <[email protected]> wrote: > 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
