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