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, [email protected] 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
