On Jun 15, 2011, at 12:49 PM, Roy Stogner wrote: > > 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.
Well... we do both depending on the application. One added wrinkle for us is that we also work on displaced grids.... ie the solution itself is moving the grid.... so if you are using higher order shape functions for your solution then you are displacing your grid in a higher order fashion. This means that even if you start with a higher order grid that is geometrically lower order... it might not stay that way. > 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. Sounds good. > I'd definitely be curious to know if you notice anything. I'll let you know. >> 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). Bah... >> 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? Actually that can give incorrect answers. I drew a case on the whiteboard here for John using your singularly perturbed edge as a side for a Quad with a neighbor on the other side of that edge.... if things are nasty enough the bounding box check will actually tell you that the point lies in the neighbor when in reality it lies in _this_ distorted element! But wait... in that case it would then run inverse_map() on the neighbor and it wouldn't be in there... returning false. So.... yes! You're right. Search with secure=false then secure=true..... and it would work. As long as we're optimizing things.... while doing the secure=false search I would keep track of the ~10 closest elements (using their centroids) so that if you don't find anything and you go to search with secure=true.... search those 10 first before doing a huge search. Derek ------------------------------------------------------------------------------ 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
