Independently configuring down & up smoothers in PCMG

[Matthew Knepley]

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