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
>
