Putting a peculiar multilevel scheme into DMMG?

Matthew Knepley knepley at gmail.com
Sun Dec 13 18:06:04 CST 2009


On Sun, Dec 13, 2009 at 5:56 PM, Jed Brown <jed at 59a2.org> wrote:

> On Sun, 13 Dec 2009 16:59:39 -0600, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >     It was never fully developed (i.e. things might not work). It
> > could be we should switch to using that one and slowly remove the
> > regular refine (note that one could still use the refinehierarchy one
> > several times to get the effect of the current refine.
>
> So none of the present DMs implement refinehierarchy.  I think it would
> be reasonable for DMMGSetDM to always call DMRefineHierarchy where
> DMRefineHierarchy had a default implementation that just repeatedly
> called DMRefine.  If you didn't want to deprecate DMRefine, a default
> implementation for that could be given in terms of DMRefineHierarchy.
> Similarly for coarsening, this would get rid of the extra branching in
> DMMGSetDM.
>

I will explain the history since I am to blame for this one. I needed
coarsenHierarchy
because repeated coarsening can cause degradation of the meshes. Thus all
coarse meshes must be made at once. I added the hierarchy option, but only
the
coarsen branch was used.


> It seems to me that caller of DMMGSetDM knows whether they are setting
> the fine or coarse mesh.  In that case, I don't see the point of the
> -dmmg_refine option, and would prefer an explicit argument for whether
> the DM is on the fine, coarse, or perhaps intermediate level.  Is there
> a use case where the caller of DMMGSetDM doesn't know?
>

I guess this sounds reasonable.


> DMCoarsenHierarchy is implemented for Mesh, but the array is currently
> leaking (DMMGSetDM forgets a PetscFree).  Is it indeed preferred that
> the caller does not allocate the array (despite knowing how much is
> needed) but is responsible for freeing it (I ask because this is clumsy
> for a single level of refinement).  Either way, I'll document the choice
> and fix the leak.
>

Cool. I guess we could have caller allocation, but that is harder to check
for
correctness.

   Matt


> Jed
>
-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091213/ece70520/attachment.html>


More information about the petsc-dev mailing list