From: Boyce Griffith <griffith@ci...>  20110418 22:33:19
Attachments:
fe_init_patch.diff

Hi, Folks  I need FE::reinit() to work at arbitrary locations for the side version of reinit(). Attached is a patch that adds this functionality for both the side version of reinit() and for edge_reinit(). I wasn't completely sure what to do for the InfFE case for the side case, so in the patch, if someone calls the side version of reinit or edge_reinit, an error message is printed and libmesh_error is called. I also anticipate eventually wanting to be able to supply both positions and quadrature weights, so I also added an optional weights argument to all of the reinit functions. If the user specifies points but not weights, then the patch reverts to using the same dummy weights as usual (all 1's).  Boyce 
From: Roy Stogner <roystgnr@ic...>  20110418 23:00:16

On Mon, 18 Apr 2011, Boyce Griffith wrote: > I need FE::reinit() to work at arbitrary locations for the side version of > reinit(). Attached is a patch that adds this functionality for both the side > version of reinit() and for edge_reinit(). I wasn't completely sure what to > do for the InfFE case for the side case, so in the patch, if someone calls > the side version of reinit or edge_reinit, an error message is printed and > libmesh_error is called. > > I also anticipate eventually wanting to be able to supply both positions and > quadrature weights, so I also added an optional weights argument to all of > the reinit functions. If the user specifies points but not weights, then the > patch reverts to using the same dummy weights as usual (all 1's). This is interesting; what's the application? Generally when I want FE::reinit at specified points, I've got those points in physical space, which means I can inverse_map them and get whatever I need from the regular reinit(vector). But I guess if you're doing something like interfacing an 3D with a 2D copy of its BoundaryMesh, you'd already have the points in 2D master element space and so you'd want to avoid the map+remap, huh? Our application code does just that, the lazy and expensive way, and it would be nice to fix that... My first inclination is to put this patch in right after releasing 0.7.1 around the end of the week. If others could look it over beforehand that would be good.  Roy 
From: Boyce Griffith <griffith@ci...>  20110418 23:29:38

On 4/18/11 7:00 PM, Roy Stogner wrote: > > On Mon, 18 Apr 2011, Boyce Griffith wrote: > >> I need FE::reinit() to work at arbitrary locations for the side >> version of reinit(). Attached is a patch that adds this functionality >> for both the side version of reinit() and for edge_reinit(). I wasn't >> completely sure what to do for the InfFE case for the side case, so in >> the patch, if someone calls the side version of reinit or edge_reinit, >> an error message is printed and libmesh_error is called. >> >> I also anticipate eventually wanting to be able to supply both >> positions and quadrature weights, so I also added an optional weights >> argument to all of the reinit functions. If the user specifies points >> but not weights, then the patch reverts to using the same dummy >> weights as usual (all 1's). > > This is interesting; what's the application? Generally when I want > FE::reinit at specified points, I've got those points in physical > space, which means I can inverse_map them and get whatever I need from > the regular reinit(vector). This is related to my questions from the end of last week. I'm looking for intersections between a set of lines and the boundary elements of a volumetric mesh, and I need to be able evaluate things like the surface normals at those locations. This appears to require using the side version of reinit, because that seems to be the only place where surface normals are computed. I find these points by projecting each side element onto a suitably chosen plane and then inverse_map()ing a point contained in that plane, which may or may not lie in the projected element. If it does, this gives me master coordinates on the surface element. (Incidentally, if there is a more clever way to do this, I'd be happy to find out!) As for the *real* application . . . it is part of a fluidstructure interaction code coupling libMeshbased mechanics with an AMR incompressible flow solver that is implemented using SAMRAI and some other stuff. Fluidsolid coupling is by a version of the immersed boundary method. > But I guess if you're doing something like interfacing an 3D with a 2D > copy of its BoundaryMesh, you'd already have the points in 2D master > element space and so you'd want to avoid the map+remap, huh? Our > application code does just that, the lazy and expensive way, and it > would be nice to fix that... Not sure this is totally avoiding the map+remap  there is still a call to inverse_map(), which seems like something that could possibly be avoided...?  Boyce 