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
