Sorry I don't mean to spam but I thought of one other issue to consider with changing around the API for the Periodic BC AMR level one constraint issue. Right now the PeriodicBoundaries object is held inside of DofMap but for topological purposes, perhaps it doesn't belong there. At the very least, I clearly need access to it from the objects dealing with the Mesh. If we pass in the PeriodicBoundaries object as a reference to the new topological_neighbor function then the callers will need access to it only moving the problem "who should own it" problem.
For now I created a pointer in the MeshRefinement object and an accessor in DofMap to get a reference for the purpose of setting that pointer. This doesn't seem like the cleanest solution. If you have some better design ideas let me know. Thanks, Cody On Nov 10, 2010, at 3:55 PM, Cody Permann wrote: > > On Nov 10, 2010, at 3:37 PM, Roy Stogner wrote: > >> >> Sorry about the delay; you emailed while I was out of town and right >> before I got sick and this almost got buried in my inbox. >> >> On Sat, 30 Oct 2010, codyperm...@gmail.com wrote: >> >>> I was looking at this thread since Derek has asked me to look into >>> this problem >> >> The problem fixed in this thread was a silly typo in the point locator >> construction. For the "AMR on periodic boundaries" problem in general >> there's two aspects: making sure the constraints are correct and >> making sure the refinement pattern is correct, and the two seem to be >> conflated a bit in your email. But the first aspect should be >> completely solved (since failing to solve it correctly can make your >> solution grossly wrong), and the second aspect we haven't even >> attempted to solve (since failing to solve it correctly just makes >> your convergence rate slightly poorer). > > Yes I figured out that this was a different problem after I looked at your > patch again :D > >> >> And that second aspect is really a host of other little problems - >> making sure the refinement pattern is correct would require making >> changes to multiple different error estimator algorithms as well as to >> the MeshRefinement code itself. Right now we should be applying >> correct constraints to non-level-one-conforming hanging nodes on >> periodic sides, but we're ignoring any users' request to be level-one >> conforming on those sides. Likewise for interior unrefined islands on >> periodic sides, for constructing optimal patches when doing >> PatchRecovery on elements at periodic boundaries, for calculating >> JumpErrorEstimator terms... I don't have time to work on any of these >> myself but I'd be happy to look over any patches you can cook up. >> >>> We just need to make the elements on the periodic boundaries "see" >>> their respective mirrored elements as neighbors for the purpose of >>> this algorithm. This could be done by adding in the appropriate >>> logic right inside of the respective "_maintain_level_one" loops. >>> Does this seem reasonable? >> >> I think the right place to add the logic may be in elem.h - right now >> Elem::neighbor() gives you your geometric neighbor - if we had an >> Elem::topological_neighbor(PeriodicBoundaries&) alternative, which >> would give the same result as neighbor() in most cases but would do >> the right thing in the periodic BC case too, I think we could avoid >> adding more if/else/andanother special cases to a lot of these >> MeshRefinement/ErrorEstimator methods. > > So I've been working on this and have a partially working algorithm right > now that has converged on a similar approach. For now it is doing > something similar but doing so without the benefit of the suggested API > extension. I'm following a "hack_neighbors" -> refine_and_coarsen_elements > -> "unhack_neighbors" approach. > > This approach is working well in a small mesh only example that is not > using any error estimators and marking boundary elements manually > for refinement, but I'm still tracking down bugs with my larger test > problems. > I like the idea of adding that extra topological_neighbor function to elem > that can be used in MeshRefinement. > > After I get this working, I'll work in that direction to make this a cleaner > approach. > >> >>> I'd be happy to take a crack at this unless you have any other >>> ideas. >> >> Thanks! >> --- >> Roy > ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
