Putting a peculiar multilevel scheme into DMMG?

[Barry Smith]

On Dec 13, 2009, at 12:55 PM, Jed Brown wrote:

> 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.)

    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.

    Barry

>
>>    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