March 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] petsc/petsc added -pc_use_amat option to PCSetFromOptions() (commit b9ee023)
by Shri 24 Mar '13

24 Mar '13

On Mar 23, 2013, at 12:55 PM, Jed Brown wrote: > > On Sat, Mar 23, 2013 at 11:40 AM, Shri <abhyshr(a)mcs.anl.gov> wrote: > I had added -pc_reuse specifically for use with fieldsplit since I wanted only a part of the preconditioner to be built only once, for e.g. -fieldsplit_0_pc_reuse. This would build the preconditioner for fieldsplit 0 only once. I had not added any API for it since it was meant to be experimental feature. If this feature is useful then I can add an API for it otherwise I can take it out. > > If you want to give PCFieldSplit a "reuse" policy, then put the option in fieldsplit.c and have it pass SAME_PRECONDITIONER to the inner KSPSetFromOptions. I would also rather call this "lagging" (for consistency with SNES) instead of "reuse". > > Since "-pc_reuse" is only recognized by PCLU and is implemented in the wrong place for generic use, I would like to delete it. (It's just a couple lines.) Is that okay with you? I am not using it anymore so you can delete it.

1 0

Re: [petsc-dev] too much dynamic loading; a chance to simplify and remove some code?
by Jed Brown 23 Mar '13

23 Mar '13

On Sat, Mar 23, 2013 at 10:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > We currently have -dll_pre/append PetscDLLibraryPre/Append() allowing > users to indicate libraries to open. We don't have a concept of a path of > directories to look for libraries. Conceivably we could introduce a path > and only march through the path opening each library if the requested type > is not found yet. This would mean in the "smallest change from current > source code" implementation that whenever PetscFunctionListFind() (for > types) does not find a request it opens the next library and then looks > again. One issue for that is if the PetscFunctionListFind() is not run on > PETSC_COMM_WORLD, some processes will open more libraries than others; this > makes the "search through the path only as needed" a dangerous thing due to > the parallelism. I'd be inclined to just open all the dynamic libraries in > PetscInitialize() and tell people for performance reasons they may want to > limit the path for "big runs". > > > > Since we won't be searching through the libraries for symbols we can > get rid of the prepend,append stuff as well and just have a command line > option for opening libraries. Yup, sounds good. I don't like searching because of the collective load problem. We could add PetscDLLibraryOpenTree() that would recursively open subdirectories and load all the shared libraries. This would let an application selectively load any plugins they were interested in as automatically as possible.

1 0

Re: [petsc-dev] too much dynamic loading; a chance to simplify and remove some code?
by Barry Smith 23 Mar '13

23 Mar '13

On Mar 23, 2013, at 10:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 23, 2013, at 9:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> >> On Sat, Mar 23, 2013 at 8:37 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> We could >> >> 1) keep things the way they are (one could continue to use --ts_type [libraryname:]functionname) >> 2) pass the flag false to PetscFunctionListFind() for all the XXXSetType() calls so that only string names of registered types can be used for constructors not constructor function names (removing support for using --ts_type [libraryname:]functionname) >> 3) Strip all support for alternatively search of the executable and libraries for a function name when the requested string name of the type is not found from PetscFunctionListFind() (simplifying unneeded code) >> >> A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus always store the function pointer in the function list, rather than just the string name. >> (simplify unneeded code and remove confusing code) >> >> What is required for a shared library to implement an XCreate_Y() function? Surely it must (a) be linked to PETSc, thus able to call PETSc functions, and (b) really intend that XCreate_Y be an entry point for this purpose. >> >> Given these two assumptions, I think it is very reasonable for the shared library to call XRegister("y",XCreate_Y); >> >> Now how should we get those shared libraries loaded? Pretty much all plugin or dynamic loading systems that I'm aware of would place it in a search path. > > We currently have -dll_pre/append PetscDLLibraryPre/Append() allowing users to indicate libraries to open. We don't have a concept of a path of directories to look for libraries. Conceivably we could introduce a path and only march through the path opening each library if the requested type is not found yet. This would mean in the "smallest change from current source code" implementation that whenever PetscFunctionListFind() (for types) does not find a request it opens the next library and then looks again. One issue for that is if the PetscFunctionListFind() is not run on PETSC_COMM_WORLD, some processes will open more libraries than others; this makes the "search through the path only as needed" a dangerous thing due to the parallelism. I'd be inclined to just open all the dynamic libraries in PetscInitialize() and tell people for performance reasons they may want to limit the path for "big runs". > Since we won't be searching through the libraries for symbols we can get rid of the prepend,append stuff as well and just have a command line option for opening libraries. > > > > > >> Now do we always load all the shared libraries to make sure we have a complete list? That's possible, but the number of loads can be significant. Think of Emacs as an example. It provides two constructs >> >> (require 'feature "filename") >> >> (autoload 'symbol-name "filename" "Documentation string") >> >> The first case is analogous to calling PetscDLLibraryOpen(). The second is roughly being provided by the ability to use arbitrary strings, which is not collision-free. I think replacing it with an "autoload" mechanism would be sufficient. >

1 0

Re: [petsc-dev] too much dynamic loading; a chance to simplify and remove some code?
by Barry Smith 23 Mar '13

23 Mar '13

On Mar 23, 2013, at 9:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Sat, Mar 23, 2013 at 8:37 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > We could > > 1) keep things the way they are (one could continue to use --ts_type [libraryname:]functionname) > 2) pass the flag false to PetscFunctionListFind() for all the XXXSetType() calls so that only string names of registered types can be used for constructors not constructor function names (removing support for using --ts_type [libraryname:]functionname) > 3) Strip all support for alternatively search of the executable and libraries for a function name when the requested string name of the type is not found from PetscFunctionListFind() (simplifying unneeded code) > > A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus always store the function pointer in the function list, rather than just the string name. > (simplify unneeded code and remove confusing code) > > What is required for a shared library to implement an XCreate_Y() function? Surely it must (a) be linked to PETSc, thus able to call PETSc functions, and (b) really intend that XCreate_Y be an entry point for this purpose. > > Given these two assumptions, I think it is very reasonable for the shared library to call XRegister("y",XCreate_Y); > > Now how should we get those shared libraries loaded? Pretty much all plugin or dynamic loading systems that I'm aware of would place it in a search path. We currently have -dll_pre/append PetscDLLibraryPre/Append() allowing users to indicate libraries to open. We don't have a concept of a path of directories to look for libraries. Conceivably we could introduce a path and only march through the path opening each library if the requested type is not found yet. This would mean in the "smallest change from current source code" implementation that whenever PetscFunctionListFind() (for types) does not find a request it opens the next library and then looks again. One issue for that is if the PetscFunctionListFind() is not run on PETSC_COMM_WORLD, some processes will open more libraries than others; this makes the "search through the path only as needed" a dangerous thing due to the parallelism. I'd be inclined to just open all the dynamic libraries in PetscInitialize() and tell people for performance reasons they may want to limit the path for "big runs". > Now do we always load all the shared libraries to make sure we have a complete list? That's possible, but the number of loads can be significant. Think of Emacs as an example. It provides two constructs > > (require 'feature "filename") > > (autoload 'symbol-name "filename" "Documentation string") > > The first case is analogous to calling PetscDLLibraryOpen(). The second is roughly being provided by the ability to use arbitrary strings, which is not collision-free. I think replacing it with an "autoload" mechanism would be sufficient.

1 0

Re: [petsc-dev] too much dynamic loading; a chance to simplify and remove some code?
by Jed Brown 23 Mar '13

23 Mar '13

On Sat, Mar 23, 2013 at 8:37 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > We could > > 1) keep things the way they are (one could continue to use --ts_type > [libraryname:]functionname) > 2) pass the flag false to PetscFunctionListFind() for all the XXXSetType() > calls so that only string names of registered types can be used for > constructors not constructor function names (removing support for using > --ts_type [libraryname:]functionname) > 3) Strip all support for alternatively search of the executable and > libraries for a function name when the requested string name of the type is > not found from PetscFunctionListFind() (simplifying unneeded code) > > A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus > always store the function pointer in the function list, rather than just > the string name. > (simplify unneeded code and remove confusing code) > What is required for a shared library to implement an XCreate_Y() function? Surely it must (a) be linked to PETSc, thus able to call PETSc functions, and (b) really intend that XCreate_Y be an entry point for this purpose. Given these two assumptions, I think it is very reasonable for the shared library to call XRegister("y",XCreate_Y); Now how should we get those shared libraries loaded? Pretty much all plugin or dynamic loading systems that I'm aware of would place it in a search path. Now do we always load all the shared libraries to make sure we have a complete list? That's possible, but the number of loads can be significant. Think of Emacs as an example. It provides two constructs (require 'feature "filename") (autoload 'symbol-name "filename" "Documentation string") The first case is analogous to calling PetscDLLibraryOpen(). The second is roughly being provided by the ability to use arbitrary strings, which is not collision-free. I think replacing it with an "autoload" mechanism would be sufficient.

1 0

too much dynamic loading; a chance to simplify and remove some code?
by Barry Smith 23 Mar '13

23 Mar '13

Consider the following behavior ~/Src/petsc/src/ts/examples/tutorials barry/fix-dynamic $ ./ex7 -ts_type KSPCreate [0]PETSC ERROR: --------------------- Error Message ------------------------------------ [0]PETSC ERROR: Null argument, when expecting valid pointer! [0]PETSC ERROR: Null Pointer: Parameter # 2! [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Petsc Development GIT revision: 4e2e63373ef067af348e1d051da38b259e4d3643 GIT Date: 2013-03-21 12:36:44 -0500 [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: ./ex7 on a arch-dynamic named Barrys-MacBook-Pro.local by barrysmith Thu Mar 21 21:57:22 2013 [0]PETSC ERROR: Libraries linked from /Users/barrysmith/Src/PETSc/arch-dynamic/lib [0]PETSC ERROR: Configure run at Thu Mar 21 21:30:07 2013 [0]PETSC ERROR: Configure options --download-mpich --with-shared-libraries --with-dynamic-loading --with-single-library=false [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: KSPCreate() line 727 in /Users/barrysmith/Src/PETSc/src/ksp/ksp/interface/itcreate.c [0]PETSC ERROR: TSSetType() line 67 in /Users/barrysmith/Src/PETSc/src/ts/interface/tsreg.c [0]PETSC ERROR: TSSetTypeFromOptions() line 43 in /Users/barrysmith/Src/PETSc/src/ts/interface/ts.c [0]PETSC ERROR: TSSetFromOptions() line 112 in /Users/barrysmith/Src/PETSc/src/ts/interface/ts.c [0]PETSC ERROR: main() line 95 in src/ts/examples/tutorials/ex7.c This happens because all the different XXXSetType() routines call PetscFunctionListFind() with the flag to alternatively search the executable and dynamic libraries for functions passing the name passed it. The original plan was so that users at runtime could load their own custom versions, for example -ts_type mydynamiclib:TSCreate_MyCoolTS. In the past I've run -ts_type rows and gotten the same crash because my libraries happened to have a function named rows. Thus one can indicate constructors in two ways (Barry doesn't like two ways to do anything:-)), by the string name if the constructor function was registered with XXXRegister() or if dynamic libraries are enabled, directly by the name of the constructor function. Just to add a little more complexity, if PETSc is built with --with-dynamic-loading when functions are registered with PetscFunctionListAdd() the string name of the function is kept in the list, but not the actual function pointer. Then, if PetscFunctionListFind() locates the registered string name, the function pointer is dynamically loaded using the string version of the function. Also when opening a dynamic library, PETSc automatically calls a function within that the library that __can__ register any types whose constructors are in that library. Thus if all available types are registered in all dynamic libraries then the support for directly indicating the constructor function name is not needed (though perhaps useful?). We could 1) keep things the way they are (one could continue to use --ts_type [libraryname:]functionname) 2) pass the flag false to PetscFunctionListFind() for all the XXXSetType() calls so that only string names of registered types can be used for constructors not constructor function names (removing support for using --ts_type [libraryname:]functionname) 3) Strip all support for alternatively search of the executable and libraries for a function name when the requested string name of the type is not found from PetscFunctionListFind() (simplifying unneeded code) A) Remove the XXXRegisterDynamic() keeping only XXXRegister() and thus always store the function pointer in the function list, rather than just the string name. (simplify unneeded code and remove confusing code) What say you, Barry

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Dave Nystrom 23 Mar '13

23 Mar '13

Thanks. I mistakenly sent the log files to petsc-dev. Sorry about that. I did a resend and sent them to petsc-maint. Dave Karl Rupp writes: > Hi Dave, > > thanks for the log-files and the testing. CMake hangs during it's > startup and thus runs into a timeout. Maybe this is related to the bug > Jed found in CMake 2.8.10.2, I have no other explanation why this hangs. > I'll try to reproduce this as soon as I' at a CUDA-enabled machine again. > > Best regards, > Karli > > > > On 03/23/2013 06:49 PM, Dave Nystrom wrote: > > Hi Karli, > > > > Still does not seem to work. Attached are the logs from the latest attempt. > > > > Cheers, > > > > Dave > > > > > > > > > > Karl Rupp writes: > > > Hi again, > > > > > > I've found the cause of the issue, namely an overly tight timeout during > > > the CMake initialization. Dave, could you please rerun reconfigure and > > > make in the latest `next`? > > > > > > Thanks and best regards, > > > Karli > > > > > > > > > > > > On 03/20/2013 07:31 PM, Dave Nystrom wrote: > > > > Hi Karli, > > > > > > > > Just now seeing this. I did my build from a clean slate. > > > > > > > > Thanks, > > > > > > > > Dave > > > > > > > > Karl Rupp writes: > > > > > Hi Dave, > > > > > > > > > > I also found that in some occasions one should issue > > > > > $> rm -rf PETSC_ARCH/CMake* > > > > > prior to running a reconfigure in order to circumvent a bug [1] in CMake. > > > > > > > > > > @Jed, Matt: The current cmakeboot.py removes > > > > > PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even > > > > > exist on my machine (CMake 2.8.7). Can we instead just delete the whole > > > > > CMakeFiles-folder and probably CMakeCache.txt? > > > > > > > > > > Best regards, > > > > > Karli > > > > > > > > > > [1] http://www.mail-archive.com/[email protected]/msg44765.html > > > > > > > > > > > > > > > > > > > > On 03/20/2013 10:17 AM, Nystrom, William D wrote: > > > > > > Hi Karli, > > > > > > > > > > > > I ran a test build last night and it failed. It was a relatively simple configuration where > > > > > > I was downloading mpich and cmake and building with threads, cuda and the txpetscgpu > > > > > > package. I was building on a Fedora 17 machine with Cuda 5. The failure seem to be > > > > > > associated with cmake. When I get home this evening, I could send you the configure > > > > > > and make logs. I did not have time this morning before leaving for work. I wanted to > > > > > > give you some early feedback even though the logs will have to wait till this evening. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Dave > > > > > > > > > > > > -- > > > > > > Dave Nystrom > > > > > > LANL HPC-5 > > > > > > Phone: 505-667-7913 > > > > > > Email: wdn(a)lanl.gov > > > > > > Smail: Mail Stop B272 > > > > > > Group HPC-5 > > > > > > Los Alamos National Laboratory > > > > > > Los Alamos, NM 87545 > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > > > > > > Sent: Tuesday, March 19, 2013 4:04 PM > > > > > > To: petsc-dev(a)mcs.anl.gov > > > > > > Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > perfect, thanks! > > > > > > I should add that a reconfigure is needed. It won't work with re-running > > > > > > make only. > > > > > > > > > > > > Best regards, > > > > > > Karli > > > > > > > > > > > > > > > > > > On 03/19/2013 04:59 PM, Nystrom, William D wrote: > > > > > >> Hi Karli, > > > > > >> > > > > > >> I will try this soon and report back when I have results. > > > > > >> > > > > > >> Thanks, > > > > > >> > > > > > >> Dave > > > > > >> > > > > > >> ________________________________________ > > > > > >> From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > > > > > >> Sent: Tuesday, March 19, 2013 3:58 PM > > > > > >> To: For users of the development version of PETSc > > > > > >> Subject: [petsc-dev] CMake-assisted CUDA builds ready > > > > > >> > > > > > >> Dear all, > > > > > >> > > > > > >> I just merged the CMake-based builds for CUDA-packages into 'next', > > > > > >> reducing compilation times considerably compared to the old legacy > > > > > >> builds. While the legacy builds print something like > > > > > >> 'libfast in <DIR>' > > > > > >> the new CMake-based builds print the usual percentage counters in front. > > > > > >> > > > > > >> Any feedback on the proper functionality (both positive and negative) > > > > > >> are appreciated. > > > > > >> > > > > > >> Thanks and best regards, > > > > > >> Karli > > > > > >> > > > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Karl Rupp 23 Mar '13

23 Mar '13

Hi Dave, thanks for the log-files and the testing. CMake hangs during it's startup and thus runs into a timeout. Maybe this is related to the bug Jed found in CMake 2.8.10.2, I have no other explanation why this hangs. I'll try to reproduce this as soon as I' at a CUDA-enabled machine again. Best regards, Karli On 03/23/2013 06:49 PM, Dave Nystrom wrote: > Hi Karli, > > Still does not seem to work. Attached are the logs from the latest attempt. > > Cheers, > > Dave > > > > > Karl Rupp writes: > > Hi again, > > > > I've found the cause of the issue, namely an overly tight timeout during > > the CMake initialization. Dave, could you please rerun reconfigure and > > make in the latest `next`? > > > > Thanks and best regards, > > Karli > > > > > > > > On 03/20/2013 07:31 PM, Dave Nystrom wrote: > > > Hi Karli, > > > > > > Just now seeing this. I did my build from a clean slate. > > > > > > Thanks, > > > > > > Dave > > > > > > Karl Rupp writes: > > > > Hi Dave, > > > > > > > > I also found that in some occasions one should issue > > > > $> rm -rf PETSC_ARCH/CMake* > > > > prior to running a reconfigure in order to circumvent a bug [1] in CMake. > > > > > > > > @Jed, Matt: The current cmakeboot.py removes > > > > PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even > > > > exist on my machine (CMake 2.8.7). Can we instead just delete the whole > > > > CMakeFiles-folder and probably CMakeCache.txt? > > > > > > > > Best regards, > > > > Karli > > > > > > > > [1] http://www.mail-archive.com/[email protected]/msg44765.html > > > > > > > > > > > > > > > > On 03/20/2013 10:17 AM, Nystrom, William D wrote: > > > > > Hi Karli, > > > > > > > > > > I ran a test build last night and it failed. It was a relatively simple configuration where > > > > > I was downloading mpich and cmake and building with threads, cuda and the txpetscgpu > > > > > package. I was building on a Fedora 17 machine with Cuda 5. The failure seem to be > > > > > associated with cmake. When I get home this evening, I could send you the configure > > > > > and make logs. I did not have time this morning before leaving for work. I wanted to > > > > > give you some early feedback even though the logs will have to wait till this evening. > > > > > > > > > > Thanks, > > > > > > > > > > Dave > > > > > > > > > > -- > > > > > Dave Nystrom > > > > > LANL HPC-5 > > > > > Phone: 505-667-7913 > > > > > Email: wdn(a)lanl.gov > > > > > Smail: Mail Stop B272 > > > > > Group HPC-5 > > > > > Los Alamos National Laboratory > > > > > Los Alamos, NM 87545 > > > > > > > > > > > > > > > ________________________________________ > > > > > From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > > > > > Sent: Tuesday, March 19, 2013 4:04 PM > > > > > To: petsc-dev(a)mcs.anl.gov > > > > > Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready > > > > > > > > > > Hi Dave, > > > > > > > > > > perfect, thanks! > > > > > I should add that a reconfigure is needed. It won't work with re-running > > > > > make only. > > > > > > > > > > Best regards, > > > > > Karli > > > > > > > > > > > > > > > On 03/19/2013 04:59 PM, Nystrom, William D wrote: > > > > >> Hi Karli, > > > > >> > > > > >> I will try this soon and report back when I have results. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Dave > > > > >> > > > > >> ________________________________________ > > > > >> From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > > > > >> Sent: Tuesday, March 19, 2013 3:58 PM > > > > >> To: For users of the development version of PETSc > > > > >> Subject: [petsc-dev] CMake-assisted CUDA builds ready > > > > >> > > > > >> Dear all, > > > > >> > > > > >> I just merged the CMake-based builds for CUDA-packages into 'next', > > > > >> reducing compilation times considerably compared to the old legacy > > > > >> builds. While the legacy builds print something like > > > > >> 'libfast in <DIR>' > > > > >> the new CMake-based builds print the usual percentage counters in front. > > > > >> > > > > >> Any feedback on the proper functionality (both positive and negative) > > > > >> are appreciated. > > > > >> > > > > >> Thanks and best regards, > > > > >> Karli > > > > >> > > > > > > > > > > > > >

1 0

Re: [petsc-dev] petsc/petsc added -pc_use_amat option to PCSetFromOptions() (commit b9ee023)
by Jed Brown 23 Mar '13

23 Mar '13

On Sat, Mar 23, 2013 at 11:40 AM, Shri <abhyshr(a)mcs.anl.gov> wrote: > I had added -pc_reuse specifically for use with fieldsplit since I wanted > only a part of the preconditioner to be built only once, for e.g. > -fieldsplit_0_pc_reuse. This would build the preconditioner for fieldsplit > 0 only once. I had not added any API for it since it was meant to be > experimental feature. If this feature is useful then I can add an API for > it otherwise I can take it out. If you want to give PCFieldSplit a "reuse" policy, then put the option in fieldsplit.c and have it pass SAME_PRECONDITIONER to the inner KSPSetFromOptions. I would also rather call this "lagging" (for consistency with SNES) instead of "reuse". Since "-pc_reuse" is only recognized by PCLU and is implemented in the wrong place for generic use, I would like to delete it. (It's just a couple lines.) Is that okay with you?

1 0

Re: [petsc-dev] petsc/petsc added -pc_use_amat option to PCSetFromOptions() (commit b9ee023)
by Shri 23 Mar '13

23 Mar '13

Jed, I had added -pc_reuse specifically for use with fieldsplit since I wanted only a part of the preconditioner to be built only once, for e.g. -fieldsplit_0_pc_reuse. This would build the preconditioner for fieldsplit 0 only once. I had not added any API for it since it was meant to be experimental feature. If this feature is useful then I can add an API for it otherwise I can take it out. Shri On Mar 23, 2013, at 11:25 AM, Jed Brown wrote: > > On Fri, Mar 22, 2013 at 10:14 AM, Mark F. Adams <mark.adams(a)columbia.edu> wrote: > I thought the primary mission of options_left was to catch spelling mistakes. > >> (This is also useful if a PC logically ought to pay attention to this option, but isn't.) What about making PCSetUseAmat() use PetscTryMethod() and move the check of "-pc_use_amat" into each implementation? >> > > I agree with Barry that it should be high level and make it there for any PC to use if they want. > >> Do we really want to leave the confusing option in place for all the PCs that don't have inner solvers? > > It just doesn't seem that bad to me. > > Okay, okay, I'll stick with the simple thing. > > What about "-pc_reuse"? It is only referenced in src/ksp/pc/impls/factor/lu/lu.c and it doesn't have an API. Can it be removed entirely? I thought we were using SAME_PRECONDITIONER for this sort of thing.

1 0