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). 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. > 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
