Independently configuring down & up smoothers in PCMG

Tue Oct 21 00:06:19 CDT 2008

On Mon, Oct 20, 2008 at 10:13 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   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.
>

Perhaps  /usr/include/regex.h would help ? (don't know if it is portable enough)

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

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594