On Sun, May 6, 2012 at 5:57 PM, Jed Brown <[email protected]> wrote:
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.
This is a huge mistake. The only way unstructured stuff works is through this interface. That is why I added it Matt
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 <[email protected]> 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.
-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener