On Nov 17, 2010, at 11:13 AM, Roy Stogner wrote: > > On Tue, 16 Nov 2010, Cody Permann wrote: > >>>> Everything seems to be working just fine. There is one more mystery >>>> which I cannot figure out. I am forced to clear the point locator >>>> class manually in each adaptivity step before I use it or I end up >>>> with data corruption and a seg fault in the Point Locator Tree in >>>> the middle of the mesh refinement algorithm. I'm not sure if this >>>> is an indication that I'm doing something wrong or not. Everything >>>> works fine as long as I start with a clear locator each timestep. > > I think the root trouble is that we never pictured PointLocatorTree > being used on a mesh in mid-flux. That's why it's cleared in > MeshBase::prepare_for_use() - because once you start adding elements > then the tree will erroneously return their parents instead of them, > and once you start removing elements the tree can segfault when it > "finds" orphaned pointers to them. > > I'm actually not sure how this is causing your bug, though - you're > just using the point_locator in the flagging stage, right? Where the > elements haven't actually been created or deleted yet? >
Yes, I am using the point_locator in the flagging stage. However, the elements are refined and coarsened right after the flagging is complete but if you are in the middle a refinement loop, you enter the flagging stage again. This is exactly what's happening in ex10.C. The mesh refinement loop is running iteratively but none of the calls made in that loop would re-initialize the point locator after the elements have been refined and/or coarsened. So I do believe that you have identify the problem. >> I think we'll still need a "has_topological_neighbor" function in >> element too. > > Yeah; I pictured leaving that function in Elem, just using a > simplified inline function in MeshRefinement that dispatches to it > after handling the ifdefs and picking out the right > Mesh/PeriodicBoundaries parameters. OK - I'll get that in with the proper dispatch semantics you mentioned yesterday > >> After we get this all hammered out, we'll have to >> think about optimizations. Using that point locator on every single >> boundary element all the time has got to be fairly expensive. > > Not necessarily. With a tree it's a log(N_elem) lookup each time, so > O(N_bdyelem*log(N_elem)) in total. A cached std::map would barely be > an improvement at O(N_bdyelem*log(N_bdyelem)). I suppose a cached > unordered_map would at least be worth trying out. After talking with Derek, I realized that this is not a big issue. Aside from the argument here, we are only refining the mesh at each time step which might contain many nonlinear and nested linear iterations so the overall cost of this is relatively small anyway. I ran a much larger mesoscale simulation yesterday with periodic conditions that previously used to seg fault after a number of transient time steps. I let it run for hours and it continued to run and adapt without problems using the current patch. I did not notice any speed degradation with the patch applied. > --- > Roy ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
