Independently configuring down & up smoothers in PCMG

[Barry Smith]

    Matt,

     You idea is more general than mine, and (I think) encompasses  
what you could
do with mine.

     We must keep in mind that prefixes can be append/prepended to  
other prefixes
repeatedly. To manage this with your approach we might likely need to  
turn a prefix
into a first class object and provide all the infrastructure to manage  
them. Yuck, if
we can help it.


Of course, with my approach and several _2_ and _CAP_ in a string the  
searches
get more complicated also, there is no free lunch. But I like the  
simplicity of
keeping the prefix a simple string.

We could avoid a prefix object if we, for example, divided the  
possibilities
with a |, for example my   mg_levels_1_ prefix would be <mg_levels_1_| 
mg_levels>
Note each "part" of an combined prefix would need to be separated by  
something
like <> so one knows where the | applies.

You write "we let an object have multiple prefixes", this is actually  
what my suggestion
does also, but with very limited possible multiples (which I kind of  
like, I hate to think
-you_bad_option_pc_type  and -a_totally_different_pc_type mean the  
same thing.)

   Barry


On Oct 20, 2008, at 4:56 PM, Matthew Knepley wrote:

> On Mon, Oct 20, 2008 at 4:18 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>> Sorry I haven't responded to this fully.
>>
>> I hate the idea of a hack that is just for this case and a special
>> flag you got to set or pass in.
>>
>> For the _1_, _2_ etc I did the following. If the string in the code  
>> has
>> _%d_  (for example _1_) it first checks for an exact match in the  
>> list of
>> set options. If it does not find an exact match it removes the _%d_  
>> and
>> tries
>> again for an exact match. This seems to work pretty well and could be
>> used in many places in the code, not just in the PCMG stuff.
>
> I am not sure I like this. It does not fit with my idea of  
> namespaces, but I
> do like something very similar (maybe even identical, I can't tell  
> yet). What
> if we let an object have multiple prefixes, and we have an order for  
> checking.
> The way we could have
>
>  -pc_mg_1_ksp_max_its 2 -pc_mg_1_up_ksp_max_its 3
>
> The second would override the first for the up smoother. Is this  
> identical to
> what you were proposing?
>
>  Matt
>
>> It would be nice to use some similar technique the case below.
>> Possibilities
>> 1) use _CAPS_ first exactly and then removing the _CAPS_
>> 2) make the part with special charactors _<string>_,  first look with
>> _string_
>> then try without _string_ (the <> are just my example charactors,  
>> could use
>> | or whatever.
>>
>> What do people think about this?
>>
>>  Barry
>>
>> Note that currently we always use small letters in the option  
>> names. We
>> could continue to
>> have the options database have small letters and use  
>> _tolower(CAPS)_ as the
>> first test.
>> I'm inclinded to do 1).
>>
>> With multiple _XXX_ _4_ in an option we'll have to be careful to  
>> properly
>> check all possibilities
>> in some consistent order.
>>
>>
>> On Oct 8, 2008, at 10:14 PM, Dave May wrote:
>>
>>> Howdy,
>>>    Should there be a mechanism to independently configure the down
>>> and up smoothers
>>> for PCMG from the command line?
>>>
>>> From the looks of things, it seems that on a  given level, one is  
>>> only
>>> able to set the smoothing
>>> sweeps to be different via
>>>  -pc_mg_smoothup 3 -pc_mg_smoothdown 2
>>>
>>> Since both the down and up smoothers (KSP's) have the prefix set  
>>> to be
>>> "mg_levels_X",
>>> it would seem that I cannot differentiate between the up ksp at  
>>> level
>>> X from the down ksp
>>> at level X via any command line arguments.
>>>
>>> It would be pain to ALWAYS have to configure both the up and down
>>> smoothers independently.
>>> But to enable the down and up smoothers to be configured  
>>> independently
>>> (on those odd occasions
>>> you want to do it) , could we do something like; set a flag via
>>>  -pc_mg_smoothers_different
>>> which would include in the smoothers prefix, the words "up" or  
>>> "down"?
>>> Then on the command line we could do something like
>>>  -mg_levels_1_up_ksp_type XXX
>>>  -mg_levels_1_down_ksp_type YYY
>>>
>>> Cheers,
>>>  Dave
>>>
>>
>>
>
>
>
> -- 
> 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
>