Putting a peculiar multilevel scheme into DMMG?

Jed Brown jed at 59A2.org
Sun Dec 13 12:55:19 CST 2009


On Sun, 13 Dec 2009 12:01:39 -0600, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> On Dec 13, 2009, at 11:43 AM, Jed Brown wrote:
> 
> > On Sun, 13 Dec 2009 10:11:07 -0600, Matthew Knepley  
> > <knepley at gmail.com> wrote:
> >> Not sure if you would need API additions. Can't everything you  
> >> describe be
> >> handled through defining the grid, operator, residual, and  
> >> projections?
> >
> > Yes, but DMMG doesn't seem to have an API for setting such things.
> 
>     Hmm, doesn't the DMMG make calls on the DM to get those operators?  
> So you would provide a DM that provided the custom beasts you want?

You're right, this can be done by replacing dm->ops->refine rather than
providing an API for that manipulation inside of _n_DMMG.  I would make
this refinement produce DMs with suitable definitions for
dm->ops->getinterpolation.  There is a little nonlocal information in
that my refinement function needs to know when to produce a different
type of DM, but there is no explicit "level" argument.  Using
ops->coarsenhierarchy is better in this regard, but it can only be
selected by setting (currently unprefixed) -dmmg_refine 0
-dmmg_hierarchy.  Is there a reason the DMRefineHierarchy branch of
DMMGSetDM is commented out?  (This is actually the most natural thing
for me.)

>     Or is it that the DMMG doesn't have enough of them? That is, it  
> does not have a separate function for restriction, for interpolation,  
> for residual computer?

That's what I was thinking, but I can just have refinement produce DMs
that know how to do the right thing.

> 
>     Regarding how I see DMMG and PCMG. PCMG has the "function slots"  
> for what MG needs. DMMG calls methods on the DM to "fill" those  
> function slots. The problem is that DMMG is not a PC, so cannot be  
> imbedded inside a larger solve; for example wanting to use DMMG on two  
> components of that three component problem.  My thought was that we  
> would move the "filling" behavior of DMMG directly into PCMG (or PC?)  
> so that a PCMG has both the "function slots" one can fill manually as  
> today or one can provide a DM and the PCMG would use methods on the DM  
> to fill up its own "function slots". It is actually a simpler model  
> than today with the DMMG and more flexible since the DMMG  
> functionality could be used anywhere in a big hierarchy of  
> pcfieldsplit, pccomposite, pcmg etc. Now if I could stop sleeping 10  
> hours a day and wasting most of my awake time on anxiety I could do  
> all this cool shit.

;-)


Jed



More information about the petsc-dev mailing list