new thoughts on dynamic libraries support
When I added the PetscDLLibraryRegister_petsc() approach
I never fixed the pfstring to use that model.
This is all easily fixed I think, in fact adding the
PetscDLLibraryRegister_petsc()
will likely make it better than what it was.
Barry
On Oct 20, 2008, at 5:16 PM, Lisandro Dalcin wrote:
> No, Barry, I was not clear enough.
>
> AFAIK, PFSTRING is broken at the time you want to actually create a PF
> of type PFSTRING. This PF type is implemented by compiling on-the-fly
> a new dynamic library called 'libpescdlib.so' (using a template file
> src/vec/pf/impls/string/cstringbase.c and calling 'make' via popen
> somewhere inside $TMP dir).
>
> The current implementation approach has three problems:
>
> 1) It only works if PETSc compiled --with-dynamic. But this could work
> even if PETSc is compiled with static libs, though that would require
> some extra cares (users executables should be built with appropriate
> flags for exporting symblols, like passing to the linker the flags
> '-Xlinker -export-dynamic' when building executables).
>
> 2) If you look at src/vec/pf/impls/string/cstringbase.c, there is no
> function 'PetscDLLibraryRegister_petscdlib' exported. Then the call to
> PetscDLLibrarySym() in FStringCreateFunction() will fail.
>
> 3) Even if the above issues are fixed, PETSc opens dynamic libraries
> with RTLD_GLOBAL flags and then caches them in DLLibrariesLoaded list.
> Then I'm not sure if this will let you create more than ONE PFSTRING.
> If extra care is taken by using a mktemp-like routine, we still could
> have issues with the RTLD_GLOBAL (though I'm not sure).
>
> As you see, the PFSTRING implementation is somewhat broken, and this
> was never noticed because there are no tests for PFSTRING.
>
> BTW, You are completely right! Libraries (and specially dynamic) are
> really overwhelming ;-)
>
>
> On Mon, Oct 20, 2008 at 6:34 PM, Barry Smith
> wrote:
>>
>> On Oct 20, 2008, at 1:49 PM, Lisandro Dalcin wrote:
>>>
>>> PetscDLLibraryRegister_NAME. If the symbol is not exported, then
>>> PetscDLLibraryOpen() fails!! BTW, Because of this constraint,
>>> PFSTRING implementation is currently broken.
>>>
>>
>> I don't understand why this would be. The PF stuff is in the Vec
>> library.
>>
>> PetscErrorCode PETSCVEC_DLLEXPORT
>> PetscDLLibraryRegister_petscvec(const char
>> path[])
>> {
>> PetscErrorCode ierr;
>>
>> ierr = PetscInitializeNoArguments(); if (ierr) return 1;
>>
>> PetscFunctionBegin;
>> /*
>> If we got here then PETSc was properly loaded
>> */
>> ierr = ISInitializePackage(path);CHKERRQ(ierr);
>> ierr = VecInitializePackage(path);CHKERRQ(ierr);
>> ierr = PFInitializePackage(path);CHKERRQ(ierr);
>> PetscFunctionReturn(0);
>> }
>>
>> The PF is suppose to work in the same way as the IS, I'm guessing
>> the IS
>> works properly?
>>
>> Thanks
>>
>> Barry
>>
>>>
>>
>>
>
>
>
> --
> 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
>
I'm going to work on PETSc's dynamic libraries support
On Fri, Oct 17, 2008 at 8:25 PM, Barry Smith wrote: > > On Oct 17, 2008, at 5:51 PM, Lisandro Dalcin wrote: > >> On Fri, Oct 17, 2008 at 4:47 PM, Barry Smith wrote: >>> I guess it is ok to add them, but I hate to add stuff, you know. >>> >> >> Just to make it clear, I'm not actually adding stuff. > > I understand this. I still don't like adding PETSc functions unless they > are really adding some value. If the use of dlopen() currently in PETSc > is just replaced by PetscDLOpen() I don't see it as worthwhile, Well, you surely agree that making the code base cleaner and amenable for future extension is always worthwhile, right? > it is only > worthwhile if you plan to use PetscDLOpen() in other places as well > (and those other places also have to have a valid reason to exist distinct > from the current use). > Indeed, and that's my intention. I want PETSc to be able to dlopen() and dlsym() dynamic libraries completely unrelated to PETSc. As you may guess, I want so dlopen() the Python library for bootstrapping the loading of petsc4py. Other use case in core PETSc: The PF implementation of type 'string' is currently broken in petsc-dev. Unfortunatelly, I do not see any testcases for PF of type 'string', so the problems never showed up. If you want to know the details, just ask. A you said below, libraries (and specially dynamic ones) are complex!!! At this point, fixing PFSTRING is a low priority for me. > I know I am being a bit anal, but I believe 99% of people who do numerical > computing are overwhelmed by complexity of libraries (and this is why > some nice C++ math libraries are not used by many people) and I think > PETSc is successful because we try very hard not to add stuff unless it is > crucial. Indeed. > Numerical computing people are also stupid, in that complexity > of a part of the library they will never use (like sys) does not make the > software > harder to use for them but they irrationally cannot see this and think the > package is too complex. I really agree with you here. But we cannot stop the process of improving and cleaning up the code base just because of the opinions of those users, right?. Perhaps we can (in the near future) move many uninsteresting stuff in petsc.h and petscsys.h to some new xxximpl.h headers inside include/private? Whould that help a bit? -- 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
need review of two patches
Barry (or someone), could you please review this two patches for
BuildSystem and config/PETSc? In short, the intentions are the
following:
1) Make BuildSystem/config/setCompilers.py set 'dynamicLibraries'
regardeless of PETSc's configure options. Then, if dlopening is
available, the 'dynamicLibraries' will be true even if petsc is
configured to be built with static libraries.
2) add PETSC_{HAVE|USE}_{SHARED|DYNAMIC}_LIBRARIES. The 'HAVE' means
the platform support it, the 'USE' means PETSc is configured to use it
(note: if USE_DINAMIC is defined, then USE_SHARED is also defined).
Hope this is not confusing!
3) Some extra checks for Windows DLL API and dlopen API.
--
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
-- next part --
A non-text attachment was scrubbed...
Name: BuildSystem.diff
Type: text/x-patch
Size: 2030 bytes
Desc: not available
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081020/f5c024d0/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: config_PETSc.diff
Type: text/x-patch
Size: 2915 bytes
Desc: not available
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081020/f5c024d0/attachment-0001.bin>
new thoughts on dynamic libraries support
After thinking hard how to follow Barry's concerns about "not add new stuff", perhaps we could do things as to make 'private' the PetscDLOpen/PetscDLClose low-level wrappers to platform's DLL API's. But this would requiere some small changes to the way PetscDLLibraryOpen() currently works. For PetscDLLibraryOpen() to success, the dynamic library currently have two requisites: 1) The library must me named libNAME[.???] , i.e. the filename must begin with 'lib' prefix, but the extension (eg: .so / .dll / whatever) is optional !!. If the filename does not start with 'lib', then PetscDLLibraryOpen() fails!!. 2) The dynamic library must export a function PetscDLLibraryRegister_NAME. If the symbol is not exported, then PetscDLLibraryOpen() fails!! BTW, Because of this constraint, PFSTRING implementation is currently broken. If Barry agree to make (1) and (2) optional (perhaps making appropriate PetscInfo calls), then I would accept to make my new PetscDLOpen/PetscDLClose stuff truly private to the src/sys/dll directory. If (1) and (2) are not made optional, then the PetscDLLibraryXXX() API is not general enough. It would not be possible to dlopen almost any library unrelated to PETSc. But PetscDLLibraryXXX() has some other nice features, like automatic file retrieval, and automatic register-in-linked-list of oppened libraries, that it would be great to make this higher-level API usable in more general cases. -- 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
new thoughts on dynamic libraries support
On Oct 20, 2008, at 1:49 PM, Lisandro Dalcin wrote: > After thinking hard how to follow Barry's concerns about "not add new > stuff", perhaps we could do things as to make 'private' the > PetscDLOpen/PetscDLClose low-level wrappers to platform's DLL API's. > But this would requiere some small changes to the way > PetscDLLibraryOpen() currently works. > > For PetscDLLibraryOpen() to success, the dynamic library currently > have two requisites: > > 1) The library must me named libNAME[.???] , i.e. the filename must > begin with 'lib' prefix, but the extension (eg: .so / .dll / whatever) > is optional !!. If the filename does not start with 'lib', then > PetscDLLibraryOpen() fails!!. It is fine to make the lib optional. > > > 2) The dynamic library must export a function > PetscDLLibraryRegister_NAME. If the symbol is not exported, then > PetscDLLibraryOpen() fails!! This is also ok, but in a PetscInfo() warning if it does not have such a symbol. > BTW, Because of this constraint, > PFSTRING implementation is currently broken. > > If Barry agree to make (1) and (2) optional (perhaps making > appropriate PetscInfo calls), then I would accept to make my new > PetscDLOpen/PetscDLClose stuff truly private to the src/sys/dll > directory. > > If (1) and (2) are not made optional, then the PetscDLLibraryXXX() API > is not general enough. It would not be possible to dlopen almost any > library unrelated to PETSc. But PetscDLLibraryXXX() has some other > nice features, like automatic file retrieval, and automatic > register-in-linked-list of oppened libraries, that it would be great > to make this higher-level API usable in more general cases. > > > > > -- > 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 >
need review of two patches
Lisandro,
Looks ok to me, go ahead and stick them in. If problems come up
we'll deal
with them.
Barry
On Oct 20, 2008, at 11:21 AM, Lisandro Dalcin wrote:
> Barry (or someone), could you please review this two patches for
> BuildSystem and config/PETSc? In short, the intentions are the
> following:
>
> 1) Make BuildSystem/config/setCompilers.py set 'dynamicLibraries'
> regardeless of PETSc's configure options. Then, if dlopening is
> available, the 'dynamicLibraries' will be true even if petsc is
> configured to be built with static libraries.
>
> 2) add PETSC_{HAVE|USE}_{SHARED|DYNAMIC}_LIBRARIES. The 'HAVE' means
> the platform support it, the 'USE' means PETSc is configured to use it
> (note: if USE_DINAMIC is defined, then USE_SHARED is also defined).
> Hope this is not confusing!
>
> 3) Some extra checks for Windows DLL API and dlopen API.
>
>
> --
> 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
>
Independently configuring down & up smoothers in PCMG
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. 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 __, 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 >
new thoughts on dynamic libraries support
On Oct 20, 2008, at 1:49 PM, Lisandro Dalcin wrote:
>
> PetscDLLibraryRegister_NAME. If the symbol is not exported, then
> PetscDLLibraryOpen() fails!! BTW, Because of this constraint,
> PFSTRING implementation is currently broken.
>
I don't understand why this would be. The PF stuff is in the Vec
library.
PetscErrorCode PETSCVEC_DLLEXPORT
PetscDLLibraryRegister_petscvec(const char path[])
{
PetscErrorCode ierr;
ierr = PetscInitializeNoArguments(); if (ierr) return 1;
PetscFunctionBegin;
/*
If we got here then PETSc was properly loaded
*/
ierr = ISInitializePackage(path);CHKERRQ(ierr);
ierr = VecInitializePackage(path);CHKERRQ(ierr);
ierr = PFInitializePackage(path);CHKERRQ(ierr);
PetscFunctionReturn(0);
}
The PF is suppose to work in the same way as the IS, I'm guessing the
IS works properly?
Thanks
Barry
>
Independently configuring down & up smoothers in PCMG
On Mon, Oct 20, 2008 at 4:18 PM, Barry Smith 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 __, 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
new thoughts on dynamic libraries support
No, Barry, I was not clear enough.
AFAIK, PFSTRING is broken at the time you want to actually create a PF
of type PFSTRING. This PF type is implemented by compiling on-the-fly
a new dynamic library called 'libpescdlib.so' (using a template file
src/vec/pf/impls/string/cstringbase.c and calling 'make' via popen
somewhere inside $TMP dir).
The current implementation approach has three problems:
1) It only works if PETSc compiled --with-dynamic. But this could work
even if PETSc is compiled with static libs, though that would require
some extra cares (users executables should be built with appropriate
flags for exporting symblols, like passing to the linker the flags
'-Xlinker -export-dynamic' when building executables).
2) If you look at src/vec/pf/impls/string/cstringbase.c, there is no
function 'PetscDLLibraryRegister_petscdlib' exported. Then the call to
PetscDLLibrarySym() in FStringCreateFunction() will fail.
3) Even if the above issues are fixed, PETSc opens dynamic libraries
with RTLD_GLOBAL flags and then caches them in DLLibrariesLoaded list.
Then I'm not sure if this will let you create more than ONE PFSTRING.
If extra care is taken by using a mktemp-like routine, we still could
have issues with the RTLD_GLOBAL (though I'm not sure).
As you see, the PFSTRING implementation is somewhat broken, and this
was never noticed because there are no tests for PFSTRING.
BTW, You are completely right! Libraries (and specially dynamic) are
really overwhelming ;-)
On Mon, Oct 20, 2008 at 6:34 PM, Barry Smith wrote:
>
> On Oct 20, 2008, at 1:49 PM, Lisandro Dalcin wrote:
>>
>> PetscDLLibraryRegister_NAME. If the symbol is not exported, then
>> PetscDLLibraryOpen() fails!! BTW, Because of this constraint,
>> PFSTRING implementation is currently broken.
>>
>
> I don't understand why this would be. The PF stuff is in the Vec library.
>
> PetscErrorCode PETSCVEC_DLLEXPORT PetscDLLibraryRegister_petscvec(const char
> path[])
> {
> PetscErrorCode ierr;
>
> ierr = PetscInitializeNoArguments(); if (ierr) return 1;
>
> PetscFunctionBegin;
> /*
> If we got here then PETSc was properly loaded
> */
> ierr = ISInitializePackage(path);CHKERRQ(ierr);
> ierr = VecInitializePackage(path);CHKERRQ(ierr);
> ierr = PFInitializePackage(path);CHKERRQ(ierr);
> PetscFunctionReturn(0);
> }
>
> The PF is suppose to work in the same way as the IS, I'm guessing the IS
> works properly?
>
> Thanks
>
> Barry
>
>>
>
>
--
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
Independently configuring down & up smoothers in PCMG
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 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.) Barry On Oct 20, 2008, at 4:56 PM, Matthew Knepley wrote: > On Mon, Oct 20, 2008 at 4:18 PM, Barry Smith > 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 __, 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 >
Independently configuring down & up smoothers in PCMG
On Mon, Oct 20, 2008 at 5:18 PM, Barry Smith 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 > > 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 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 __, 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 i
Independently configuring down & up smoothers in PCMG
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 > 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 >> >> 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 >>> 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 __, 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
