On Wed, 15 Jun 2011, Derek Gaston wrote: > Firstly: Very good idea. We have our own mesh to mesh projection > code here (mostly for interpolating high order solutions on fine low > order grids for visualization)...
Say, are you actually using high order geometry there? Or just taking a first-order grid and going all_second_order() with it? It might be worthwhile to test whether a second-order element is really geometrically first-order, and if so apply the bounding box test, since many (most?) people really only use the extra order for non-geometrical reasons, to handle higher-order FE types. > and it does take a bit to run for > 3D solutions... I'll bet. Just finished a 3D run with my own projection code; projecting several million DoFs from one low order grid to another now takes ten minutes instead of two hours. The time is still divided roughly 10% doing-the-local-projections and 90% finding-points, but at least now it's just one order of magnitude off instead of two. > and the speedup for periodic boundary conditions and some of our > point source code will definitely help the runtime of some of our > applications. I'd definitely be curious to know if you notice anything. > As for the actual problem... I don't think that there is any > calculation that you can do with just the nodes that will > _guarantee_ that all of the element is contained in the bounding > box. I think the only foolproof way to do it is to use the > gradients of the shape functions to actually find the minima / > maxima (this will be a small newton solve I believe). Performing > that operation for each side in 3D will probably be more expensive > than just doing inverse_map() in the first place.... You're probably right. > Now... that is the theory. However, I think that in practice our > elements are MUCH more well behaved than the pathological cases. > For instance, it's pretty hard for me to imagine an element being so > distorted that it lies outside of a bounding sphere made using the > corner nodes. Eh, I can come up with a counter-example for that, even in 2D... even a bounding sphere made using every node will fail for that singularly perturbed case I gave John. > In fact, I kind of wonder if such an element would > even have a positive jacobian.... That does seem like a good point. We don't need contains_point() to work for every element, just every everywhere-invertible element. Not sure if it helps us, though. Even that nasty singularly perturbed case is an everywhere-invertible EDGE3 (and can be extended to an everywhere-invertible planar QUAD9). > Does this mean we should have a "secure = true" option for > contains_point() just like we do in other places? I would vote for > when "secure = false" we build a bounding box and add a fudge factor > based on the relative distance between any two nodes. I think that > in practice this will save a lot of time and be correct 99.99% of > the time.... This is a good idea in the point locator case, I think. E.g. PointLocatorTree could do one pass with secure=false, then if it didn't find anything try again with secure=true? --- Roy ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
