From: Minq Q <micavn@gm...>  20100818 22:51:02

Hi, I am having a problem when using the periodic BC together with the mesh refinement. When one BC is set to refine, the other paired BC is not allocated the new nodes as it should. The strange thing is: The first time of the refinement is OK. But from the second time the two paired BCs are become different. Do I need to call any things after refinement step. My current refine function is: .... mesh_refinement.flag_elements_by_error_fraction (error_per_cell); if( mesh_refinement.refine_and_coarsen_elements() ) es.reinit (); .... Thanks in advance, / Ming 
From: Roy Stogner <roystgnr@ic...>  20100819 00:41:30

On Thu, 19 Aug 2010, Minq Q wrote: > I am having a problem when using the periodic BC together with the mesh > refinement. When one BC is set to refine, the other paired BC is not > allocated the new nodes as it should. That's actually correct  the new node is a hanging node on one side of the boundary, and shouldn't exist on the other until the element on the other side is refined. > The strange thing is: The first time of the refinement is OK. But > from the second time the two paired BCs are become different. There are currently two issues with combining the periodic BC and the AMR feature: The "level 1 conformity" constraint is not supported across the boundary. I.e. if you set enforce_level_one to true it will only be enforced on the mesh interior, not from one side of a periodic boundary to another. The mix of AMR and periodic constraint equations may not be working correctly. The two features are supposed to be compatible, but when I wrote the latter I was mostly using one or the other, or at best running periodic problems where the nonuniform refinement occurred away from the periodic BC, so I haven't tested it thoroughly. If you can set up a test case (as simple as possible, please) where the constraints are coming out wrong, please post the code to the list, and we can at least see if it's a simple bug/fix.  Roy 
From: Ming Q <micavn@gm...>  20100819 09:30:05
Attachments:
Message as HTML

Here is the test case that will show the BC constrain is broken after the refinement. Thanks, / Ming 
From: Ming Q <micavn@gm...>  20101030 10:14:30

Hi again, It seem the periodic BC functions is not working with the current SVN version. I resend the test case I have sent before. Regards, / Ming Q. 
From: <codypermann@gm...>  20101030 16:15:26

Roy, I was looking at this thread since Derek has asked me to look into this problem a little more and noticed that your original patch to fix the problem was all written within fe_base dealing with constraints. I'm no expert but this doesn't seem like enough when you consider cascading effects that show up when you enforce the level one rule. Instead I was thinking about fixing the problem by essentially applying your interior AMR algorithms inside of the MeshRefinment class across the periodic boundaries. Specifically, I was considering making changes to the make_(?:refinementcoarsening)_compatible functions. Each of these functions contains a loop that runs to maintain the level one rule by adjusting the refinement flags each time the mesh is coarsened and/or refined. All of the right logic is present to force the right refinement patterns throughout the interior mesh elements already. Think about a worst case scenario where you have refinement happening right on one periodic boundary and then "just inside" of the mirrored boundary. If you take some naive approach and only work with flags on the boundary you start to see unrefined patches of elements showing up or other interior pattern cases which again are already handled for interior elements. 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'd be happy to take a crack at this unless you have any other ideas. Thanks, Cody On Oct 30, 2010 4:14am, Ming Q <micavn@...> wrote: > Hi again, > It seem the periodic BC functions is not working with the current SVN > version. > I resend the test case I have sent before. > Regards, > / Ming Q. 
From: Roy Stogner <roystgnr@ic...>  20101110 22:38:06

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, codypermann@... 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 nonleveloneconforming hanging nodes on periodic sides, but we're ignoring any users' request to be levelone 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 
From: Cody Permann <codypermann@gm...>  20101110 22:55:23

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, codypermann@... 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 nonleveloneconforming hanging nodes on > periodic sides, but we're ignoring any users' request to be levelone > 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 
From: Roy Stogner <roystgnr@ic...>  20101031 17:18:51

On Sat, 30 Oct 2010, Ming Q wrote: > It seem the periodic BC functions is not working with the current SVN version. Not working with the libmesh0.7.0 release either  my "one last bugfix" included a really blatant error and wasn't tested well enough. Things ought to be fixed now in the svn head and libmesh0.7.0.1  Roy 
From: Roy Stogner <roystgnr@ic...>  20100819 18:02:46

On Thu, 19 Aug 2010, Ming Q wrote: > Here is the test case that will show the BC constrain is broken after the refinement. This replicates here perfectly; thanks. And cutting down the mesh size to 2x2 (then expanding the refinement criteria to y>5 to compensate) reduces the problem to something I can look at by hand. I'm swamped lately but I'll try to check it out this weekend. Unless any other interested parties want to try to beat me to it? E.g. I think Derek's coworkers already ran into this bug, but just hadn't managed to boil it down to such a simple test case.  Roy 
From: Derek Gaston <friedmud@gm...>  20100819 18:05:56

Yes... we're seeing this too... but haven't had time to go further. There are other modifications to the periodic constraints that are on my todo list.... most notably the ability to apply them to individual variables instead of EVERY variable in the system. Yes, I know it sounds weird, but we really do have a system of equations where some variables are periodic and others aren't... Unfortunately.... I _still_ don't have time immediately to look at either of these issues.... Derek On Aug 19, 2010, at 12:02 PM, Roy Stogner wrote: > > On Thu, 19 Aug 2010, Ming Q wrote: > >> Here is the test case that will show the BC constrain is broken after the refinement. > > This replicates here perfectly; thanks. And cutting down the mesh > size to 2x2 (then expanding the refinement criteria to y>5 to > compensate) reduces the problem to something I can look at by hand. > I'm swamped lately but I'll try to check it out this weekend. > > Unless any other interested parties want to try to beat me to it? > E.g. I think Derek's coworkers already ran into this bug, but just > hadn't managed to boil it down to such a simple test case. >  > Roy > >  > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIMdev2dev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20100823 00:04:21

On Thu, 19 Aug 2010, Roy Stogner wrote: > This replicates here perfectly; thanks. And cutting down the mesh > size to 2x2 (then expanding the refinement criteria to y>5 to > compensate) reduces the problem to something I can look at by hand. > I'm swamped lately but I'll try to check it out this weekend. I actually had time to look at the problem and I actually found a fix pretty quickly. Give the svn HEAD a try. And don't take my confidence as a replacement for verification. in particular, although I think the fix should work in 3D and for multilevel constraint cases I wouldn't trust it would testing. One more catch if you're using AMR with periodic BCs: I don't think the JumpErrorEstimator or PatchRecoveryErrorEstimator classes are currently PeriodicBoundaryaware. How suboptimal the resulting refinement patterns are will depend on your application.  Roy 