The associated ugly hackery is here. I'd welcome suggestions for a better way to do this.<div><br></div><div><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/9943253a5ac2">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/9943253a5ac2</a><br>
<br><div class="gmail_quote">On Sun, May 6, 2012 at 3:57 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":f1">Now the next round:<div><br></div><div>For semi-coarsening, we used to have stuff like -da_refine_hierarchy_x 1,1,3 -da_refine_hierarchy_y 2,2,1 -da_refine_hierarchy_z 2,2,1. Two changes make this harder now:</div>
<div><br>
</div><div>1. You essentially got rid of DMRefineHierarchy (it's not called any more), so each call to DMRefine and DMCoarsen have to figure out where they are.</div><div><br></div><div>2. Since the coarse DMs are not reused by PCMG, but instead created again using DMCoarsen, we have to figure out how to reverse the refinement process so that the same coarse grids get reconstructed again.</div>

<div><br></div><div>I added a DMRefineHook so that we can port data the other way and I modified DMCoarsen_DA and DMRefine_DA to not call DMDACreate{1,2,3}d because it eagerly calls DMSetFromOptions before we can set the refinement/coarsen level. Unless someone stops me, I'm also going to add coarsen_{x,y,z} fields to DM_DA because the refinement ratio may have nothing to do with the coarsening ratio.</div>

<div><br></div><div>I have no idea how to expose semi-coarsening through a C API other than to hold the refinement/coarsening path arrays in each DM_DA so that refinement/coarsening steps can be retraced.</div></div></blockquote>
</div><br></div>