Independently configuring down & up smoothers in PCMG

[Barry Smith]

    I want  -mg_levels_2_down_blah to first match - 
mg_levels_2_down_blah then
-mg_levels_2_blah then -mg_levels_blah, I also want - 
mg_levels_down_blah  to
match -mg_levels_down_blah then -mg_levels_blah All this also with  
nesting
of the numbers and down etc.

    If you can find a C regular expression library that can manage  
this (and is portable
and "small") then I guess we could try that.

    Barry


On Oct 20, 2008, at 5:32 PM, Matthew Knepley wrote:

> On Mon, Oct 20, 2008 at 5:18 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>>  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.)
>
> Okay, I always like the idea of limiting domains for simplicity. How
> about treating
> the prefix as a simple string, subject to prepending and appending,  
> but change
> the meaning of match. Now the prefix is interpreted as a regular  
> expression, and
> a match means an RE match. We can find a small library to do just
> this, and I think
> it is much more understandable than ad hoc rules from us.
>
>  Matt
>
>> 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
>>>
>>
>>
>
>
>
> -- 
> 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
>