Now the next round: 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:
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. 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. 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. 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. On Sun, May 6, 2012 at 1:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Fine > > On May 6, 2012, at 2:44 PM, Jed Brown wrote: > > > Should the refinement level be copied over by DMCoarsen (and the coarsen > level be copied by DMRefine)? > > > > It's useful for diagnostics to be able to define a universal level. If I > use PCMG and -snes_grid_sequence, there is effectively a sequence like > > > > DMCreate(,&dm0); // r=0,c=0 > > DMRefine(dm0,&dmf); // r=1,c=0 > > DMCoarsen(dmf,&dmc); // r=0,c=1 > > > > > > I would like a way to identify dmc as being on the "same level" as dm0. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120506/698faadf/attachment.html>