April 2012 - petsc-dev - mailman3.cels.anl.gov

MatCreate from Fortran
by Alexander Grayver 05 Apr '12

05 Apr '12

Since last time I pulled petsc-dev (2 months) something probably changed with matrices creation of so, now I can't do it from Fortran: /home/main_mod.F90:(.text+0x4a3): undefined reference to `matcreatempiaij_' /home/main_mod.F90:(.text+0x5979): undefined reference to `matcreatempidense_' /home/main_mod.F90:(.text+0x59de): undefined reference to `matcreatempiaij_' Same program compiles just fine with: Using Petsc Development HG revision: 7c3c3f8c0d65b793aea33c138419de755b591ca7 HG Date: Thu Feb 09 14:42:30 2012 -0600 Something from my side or...? -- Regards, Alexander

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Jed Brown 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 19:17, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > And this makes a difference how? I just wanted to clarify the current state. It was very annoying to check whether the matrix type was one for which MatSetBlockSize() could be called, so I made it always safe. (That was quite a while ago.) I don't have a problem with your proposed restructuring.

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Barry Smith 04 Apr '12

04 Apr '12

On Apr 4, 2012, at 9:16 PM, Jed Brown wrote: > On Sat, Mar 31, 2012 at 20:03, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > For non-blocked matrices you can call MatSetBlockSize() anytime (as with vectors changing the blocksize later will also change the block size of any other vectors/matrices that share the layout) , for blocked matrices you CANNOT ever call MatSetBlockSize() and must set it with the appropriate preallocation routine. > > Not quite. You can set the block size for BAIJ, but it just checks that it matches the block size used for preallocation and errors if not. And this makes a difference how?

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Jed Brown 04 Apr '12

04 Apr '12

On Sat, Mar 31, 2012 at 20:03, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > For non-blocked matrices you can call MatSetBlockSize() anytime (as with > vectors changing the blocksize later will also change the block size of any > other vectors/matrices that share the layout) , for blocked matrices you > CANNOT ever call MatSetBlockSize() and must set it with the appropriate > preallocation routine. Not quite. You can set the block size for BAIJ, but it just checks that it matches the block size used for preallocation and errors if not.

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Barry Smith 04 Apr '12

04 Apr '12

No one has commented. If no one shouts I will start modifying towards Matt's suggested approach. Barry On Mar 31, 2012, at 10:03 PM, Barry Smith wrote: > > I'd like to see us come to a resolution to the issue of setting block sizes for Vecs and Mats . Also could we decide on the order (and how much flexibility there can be) in the order the creation and set routines are called. > > Back ground and current situation: > ---------------------------------------------- > > Currently you can call VecSetType(), VecSetBlockSize(), and VecSetSize() in any order and you can change the block size anytime (since the layout of the vector is likely shared by other vectors there is a very bad side affect of changing the block size later since it may affect many vectors.) There is no VecSetUp(). > > Currently you can call MatSetType(), MatSetSize()* in either order. For non-blocked matrices you can call MatSetBlockSize() anytime (as with vectors changing the blocksize later will also change the block size of any other vectors/matrices that share the layout) , for blocked matrices you CANNOT ever call MatSetBlockSize() and must set it with the appropriate preallocation routine. For all matrices one must either call > MatSetUp() or MatXXXSetPreallocation() before use. > > The convenience routines VecCreateSeq(), VecCreateMPI() etc do not have a way of passing in block size > > The convenience routines for non-block matrices MatCreateSeq/MPIAIJ() do not have a way of passing in block size. The blocksize must be passed in for the block matrix convenience routines. > > Goals of reorganization: > --------------------------------- > > Eliminate situation where changing Vec or Mat blocksize "late" changes block size of other vectors/matrices (a very bad thing) > > Make things more consistent between block and nonblock matrices and vectors > > Not make allowed usage patterns overly rigid > > Not have lots of complicated logic in implementation code > > Possible approaches: > ------------------------------ > > Matt's suggestion from a while ago we never followed up on: REQUIRE MatSetBlockSize() to be called ONLY before MatSetUp() or MatXXXSetPreallocation() and remove blocksize argument in MatXXXSetPreallocation(). Similarly we could require VecSetBlockSize() to be called ONLY before VecSetUp() (blocksize default to 1 if not set before SetUp() is reached.) > > If we do this it solves the problems of changing blocksizes later affecting other objects and has a nice consistency. Also no complicated "remembering logic" > > It means we cannot do VecCreateSeq(), VecSetBlockSize(). We could add block size to all the convenience routines, drawback change to many user codes or just say tough, you want to set the blocksize don't use the convenience routines. > > Introduces VecSetUp() possibly, both good consistent with Mat, and bad, more complicated for everyone > > Lisandro's 1st suggestion: Allow VecSetBlockSize() to be called anytime, and same with MatSetBlockSize() for non-block matrices but create a new Layout object so doesn't mess up the other vectors/matrices/ > > Maximum flexibility power to user, good. > > Inconsistent between different matrix types, could be confusing bad > > Lisandro's 2nd suggestion: Allow VecSetBlockSize() and MatSetBlockSize() to be called "just a tiny bit later than creation" (for example before VecDuplicate/MatGetVecs() etc are done so the layout is not yet shared. > > A bit more flexibility to the user (they can use VecCreateSeq() and then immediately set the block size, we don't need to change VecCreateSeq()) but maybe confusing in "how long" one can delay changing the block size > > Inconsistent between different matrix types, could be confusing bad > > More logic in code to see if it is still "safe" to change the block size > > > Barry's feelings: > ----------------------- > > I like the Matt approach. I am not sure about changing the bindings for the convenience routines. > > Barry > > * MATSEQDENSE has this strange ability to call MatSetSize() later if it does not expand beyond its original maximum size; this is so special and perverse I'd like to remove it but LAPACKy folks like this feature. > > On Mar 30, 2012, at 12:44 PM, Lisandro Dalcin wrote: > >> On 30 March 2012 19:34, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>> On Mar 30, 2012, at 11:07 AM, Lisandro Dalcin wrote: >>> >>>> On 30 March 2012 19:00, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >>>>> >> >>> >>> I think this can be done by having VecSetBlockSize() simple error out it if the map->bs != -1 and new block size not equals current block size. >>> >> >> Are you sure? How are we going to support the usage below?: >> >> VecCreateSeq(comm,n,&vec) >> VecSetBlockSize(vec,bs) >> >> We cannot certainly have a long-living vec with bs=-1, right? >> >> >> -- >> Lisandro Dalcin >> --------------- >> CIMEC (INTEC/CONICET-UNL) >> Predio CONICET-Santa Fe >> Colectora RN 168 Km 472, Paraje El Pozo >> 3000 Santa Fe, Argentina >> Tel: +54-342-4511594 (ext 1011) >> Tel/Fax: +54-342-4511169 >

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Jed Brown 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 06:38, Mark F. Adams <mark.adams(a)columbia.edu> wrote: > Linear solve did not converge due to DIVERGED_INDEFINITE_MAT iterations 8 > I'm surprised it made it as far as it did. I don't think there is anything to do about this except to leave the convergence tolerance on so it can bail early.

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Mark F. Adams 04 Apr '12

04 Apr '12

On Apr 3, 2012, at 7:16 PM, Barry Smith wrote: > > On Apr 3, 2012, at 5:40 PM, Mark F. Adams wrote: > >> >> On Apr 3, 2012, at 5:05 PM, Barry Smith wrote: >> >>> >>> >>> So? >>> >>> 1) You get lucky and CG gives you a zero residual right off the bat while GMRES does not. >> >> I don't quite understand the CG results. I assume that CG applies the preconditioner before the iteration (I recall seeing that in the code at one point) and so it never sees a residual. > > Since with CG Norm_none turns off computation of norms the monitor number printed is meaningless (happens to be zero so you see zero). I suppose we could error out if norm_none is used with monitor > >> GMRES seems to have different behavior ... > > GMRES ignores the norm_none option since the algorithm needs the norm so it is computed and is printed out with monitoring. > >> CG also seems to stop after 7 iterations. Not clear why that happens (max its is set to 10). > > You could run with -ksp_converged_reason or in the debugger to see why it is stopping at 7. > [0]PCSetUp_GAMG 2 levels, grid complexity = 1.00391 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 1 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 2 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 3 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 4 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 5 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 6 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 7 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 Linear solve did not converge due to DIVERGED_INDEFINITE_MAT iterations 8 Perhaps the beta went below zero .... >> >>> >>> 2) "I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. " But doesn't GMRES compute the norms always? So why not have the GMRES version still kick out early if the norm reduces by same 10^10 before it ran out of its? (Since the norm is "free" for GMRES there is no harm done, and good things occasionly like your case below. >>> >> >> I use this code: >> >> ierr = KSPSetNormType( eksp, KSP_NORM_NONE ); CHKERRQ(ierr); >> ierr = KSPSetOptionsPrefix(eksp,((PetscObject)pc)->prefix);CHKERRQ(ierr); >> ierr = KSPAppendOptionsPrefix( eksp, "gamg_est_"); CHKERRQ(ierr); >> ierr = KSPSetFromOptions( eksp ); CHKERRQ(ierr); >> >> So I assume that the KSP_NORM_NONE turns off convergence checking. > > PetscErrorCode KSPDefaultConverged(KSP ksp,PetscInt n,PetscReal rnorm,KSPConvergedReason *reason,void *ctx) > { > PetscErrorCode ierr; > KSPDefaultConvergedCtx *cctx = (KSPDefaultConvergedCtx*) ctx; > KSPNormType normtype; > > PetscFunctionBegin; > PetscValidHeaderSpecific(ksp,KSP_CLASSID,1); > PetscValidPointer(reason,4); > *reason = KSP_CONVERGED_ITERATING; > > ierr = KSPGetNormType(ksp,&normtype);CHKERRQ(ierr); > if (normtype == KSP_NORM_NONE) SETERRQ(((PetscObject)ksp)->comm,PETSC_ERR_ARG_WRONGSTATE,"Use KSPSkipConverged() with KSPNormType of KSP_NORM_NONE"); > > So I do not understand why it isn't generating that error message for you? Are you using KSPSkipConverged in the code or something. No > Another use for the debugger to see what convergence test it is using and what norm type > It is not hitting KSPDefaultConverged in the eigen estimate. Does KSP_NORM_NONE switch to a different converged method ... Mark > Barry > >> >> Mark >> >> >>> Barry >>> >>> >>> On Apr 3, 2012, at 3:46 PM, Mark F. Adams wrote: >>> >>>> Sorry false alarm. >>>> >>>> Running in KSP tutorials (this creates a GASM PC that is just one block with the whole domain): >>>> >>>> ./ex54 -ne 5 -pc_type gamg -pc_gamg_type agg -pc_gamg_agg_nsmooths 1 -pc_gamg_verbose 2 -pc_gamg_use_agg_gasm -mat_coarsen_type hem -pc_gamg_square_graph false -mg_levels_sub_pc_type lu -gamg_est_ksp_type gmres -options_left -ksp_monitor -gamg_est_ksp_monitor_singular_value -gamg_est_ksp_view >>>> >>>> I get: >>>> >>>> 0 KSP Residual norm 6.446415297424e+01 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 1 KSP Residual norm 2.366096117202e-14 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 2 KSP Residual norm 1.540964857879e-14 % max 1.693380955892e+00 min 7.781997678493e-01 max/min 2.176023465763e+00 >>>> 3 KSP Residual norm 1.241326996942e-14 % max 2.530597391197e+00 min 7.364405777662e-01 max/min 3.436254692636e+00 >>>> 4 KSP Residual norm 1.063574617851e-14 % max 3.476067169257e+00 min 7.236790329140e-01 max/min 4.803327181195e+00 >>>> 5 KSP Residual norm 9.458672353406e-15 % max 4.436589616128e+00 min 7.159721822673e-01 max/min 6.196594959987e+00 >>>> 6 KSP Residual norm 8.601272732515e-15 % max 5.409099625105e+00 min 7.111665034107e-01 max/min 7.605953878822e+00 >>>> 7 KSP Residual norm 7.941524085286e-15 % max 6.390434791698e+00 min 7.078275282801e-01 max/min 9.028237157187e+00 >>>> 8 KSP Residual norm 7.413487448731e-15 % max 7.377240678599e+00 min 7.053779875665e-01 max/min 1.045856378939e+01 >>>> 9 KSP Residual norm 6.978470326179e-15 % max 8.367510521210e+00 min 7.035029387897e-01 max/min 1.189406619339e+01 >>>> 10 KSP Residual norm 6.612020575839e-15 % max 9.360078579306e+00 min 7.020212846961e-01 max/min 1.333304101080e+01 >>>> >>>> The problem is that I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. Here they would have stopped the iterations and all would have been good. >>>> >>>> BTW, CG does this: >>>> >>>> 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 1 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 2 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 3 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 4 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 5 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 6 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 7 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> PCSetUp_GAMG PC setup max eigen=1.000000e+00 min=0.000000e+00 on level 1 (N=36) >>>> >>>> Is it using a preconditioned norm perhaps.... >>>> >>>> Mark >>>> >>>> On Apr 3, 2012, at 2:06 PM, Barry Smith wrote: >>>> >>>>> >>>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type gmres -ksp_monitor_singular_value >>>>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>>> 1 KSP Residual norm 2.708628636814e-10 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>>> Number of iterations = 1 >>>>> Residual norm 2.36559e-11 >>>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type fgmres -ksp_monitor_singular_value >>>>> 0 KSP Residual norm 7.410897708964e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>>> 1 KSP Residual norm 2.157675690523e-11 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>>>> Number of iterations = 1 >>>>> Residual norm 2.26094e-11 >>>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type cg -ksp_monitor_singular_value >>>>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>>> 1 KSP Residual norm 3.135993325987e-10 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>>>> Number of iterations = 1 >>>>> Residual norm 2.22684e-11 >>>>> >>>>> Mark, >>>>> >>>>> Could you provide the exact specifications on how you obtained this bad highest eigen estimate? What code you ran with what options? >>>>> >>>>> Thanks >>>>> >>>>> barry >>>>> >>>>> >>>>> On Mar 30, 2012, at 10:22 AM, Mark F. Adams wrote: >>>>> >>>>>> I've had problems with GMRES and eigen estimates in the past but I now have a smoking gun. It seems that if you give GMRES an operator preconditioned with LU (ie, the preconditioned operator is the identity) GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a prefect max=1.0, min=0.0. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Mark >>>>> >>>>> >>>> >>> >>> >> > >

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Barry Smith 03 Apr '12

03 Apr '12

On Apr 3, 2012, at 5:40 PM, Mark F. Adams wrote: > > On Apr 3, 2012, at 5:05 PM, Barry Smith wrote: > >> >> >> So? >> >> 1) You get lucky and CG gives you a zero residual right off the bat while GMRES does not. > > I don't quite understand the CG results. I assume that CG applies the preconditioner before the iteration (I recall seeing that in the code at one point) and so it never sees a residual. Since with CG Norm_none turns off computation of norms the monitor number printed is meaningless (happens to be zero so you see zero). I suppose we could error out if norm_none is used with monitor > GMRES seems to have different behavior ... GMRES ignores the norm_none option since the algorithm needs the norm so it is computed and is printed out with monitoring. > CG also seems to stop after 7 iterations. Not clear why that happens (max its is set to 10). You could run with -ksp_converged_reason or in the debugger to see why it is stopping at 7. > >> >> 2) "I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. " But doesn't GMRES compute the norms always? So why not have the GMRES version still kick out early if the norm reduces by same 10^10 before it ran out of its? (Since the norm is "free" for GMRES there is no harm done, and good things occasionly like your case below. >> > > I use this code: > > ierr = KSPSetNormType( eksp, KSP_NORM_NONE ); CHKERRQ(ierr); > ierr = KSPSetOptionsPrefix(eksp,((PetscObject)pc)->prefix);CHKERRQ(ierr); > ierr = KSPAppendOptionsPrefix( eksp, "gamg_est_"); CHKERRQ(ierr); > ierr = KSPSetFromOptions( eksp ); CHKERRQ(ierr); > > So I assume that the KSP_NORM_NONE turns off convergence checking. PetscErrorCode KSPDefaultConverged(KSP ksp,PetscInt n,PetscReal rnorm,KSPConvergedReason *reason,void *ctx) { PetscErrorCode ierr; KSPDefaultConvergedCtx *cctx = (KSPDefaultConvergedCtx*) ctx; KSPNormType normtype; PetscFunctionBegin; PetscValidHeaderSpecific(ksp,KSP_CLASSID,1); PetscValidPointer(reason,4); *reason = KSP_CONVERGED_ITERATING; ierr = KSPGetNormType(ksp,&normtype);CHKERRQ(ierr); if (normtype == KSP_NORM_NONE) SETERRQ(((PetscObject)ksp)->comm,PETSC_ERR_ARG_WRONGSTATE,"Use KSPSkipConverged() with KSPNormType of KSP_NORM_NONE"); So I do not understand why it isn't generating that error message for you? Are you using KSPSkipConverged in the code or something. Another use for the debugger to see what convergence test it is using and what norm type Barry > > Mark > > >> Barry >> >> >> On Apr 3, 2012, at 3:46 PM, Mark F. Adams wrote: >> >>> Sorry false alarm. >>> >>> Running in KSP tutorials (this creates a GASM PC that is just one block with the whole domain): >>> >>> ./ex54 -ne 5 -pc_type gamg -pc_gamg_type agg -pc_gamg_agg_nsmooths 1 -pc_gamg_verbose 2 -pc_gamg_use_agg_gasm -mat_coarsen_type hem -pc_gamg_square_graph false -mg_levels_sub_pc_type lu -gamg_est_ksp_type gmres -options_left -ksp_monitor -gamg_est_ksp_monitor_singular_value -gamg_est_ksp_view >>> >>> I get: >>> >>> 0 KSP Residual norm 6.446415297424e+01 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 1 KSP Residual norm 2.366096117202e-14 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 2 KSP Residual norm 1.540964857879e-14 % max 1.693380955892e+00 min 7.781997678493e-01 max/min 2.176023465763e+00 >>> 3 KSP Residual norm 1.241326996942e-14 % max 2.530597391197e+00 min 7.364405777662e-01 max/min 3.436254692636e+00 >>> 4 KSP Residual norm 1.063574617851e-14 % max 3.476067169257e+00 min 7.236790329140e-01 max/min 4.803327181195e+00 >>> 5 KSP Residual norm 9.458672353406e-15 % max 4.436589616128e+00 min 7.159721822673e-01 max/min 6.196594959987e+00 >>> 6 KSP Residual norm 8.601272732515e-15 % max 5.409099625105e+00 min 7.111665034107e-01 max/min 7.605953878822e+00 >>> 7 KSP Residual norm 7.941524085286e-15 % max 6.390434791698e+00 min 7.078275282801e-01 max/min 9.028237157187e+00 >>> 8 KSP Residual norm 7.413487448731e-15 % max 7.377240678599e+00 min 7.053779875665e-01 max/min 1.045856378939e+01 >>> 9 KSP Residual norm 6.978470326179e-15 % max 8.367510521210e+00 min 7.035029387897e-01 max/min 1.189406619339e+01 >>> 10 KSP Residual norm 6.612020575839e-15 % max 9.360078579306e+00 min 7.020212846961e-01 max/min 1.333304101080e+01 >>> >>> The problem is that I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. Here they would have stopped the iterations and all would have been good. >>> >>> BTW, CG does this: >>> >>> 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 1 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 2 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 3 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 4 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 5 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 6 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 7 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> PCSetUp_GAMG PC setup max eigen=1.000000e+00 min=0.000000e+00 on level 1 (N=36) >>> >>> Is it using a preconditioned norm perhaps.... >>> >>> Mark >>> >>> On Apr 3, 2012, at 2:06 PM, Barry Smith wrote: >>> >>>> >>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type gmres -ksp_monitor_singular_value >>>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 1 KSP Residual norm 2.708628636814e-10 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> Number of iterations = 1 >>>> Residual norm 2.36559e-11 >>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type fgmres -ksp_monitor_singular_value >>>> 0 KSP Residual norm 7.410897708964e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 1 KSP Residual norm 2.157675690523e-11 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>>> Number of iterations = 1 >>>> Residual norm 2.26094e-11 >>>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type cg -ksp_monitor_singular_value >>>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>>> 1 KSP Residual norm 3.135993325987e-10 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>>> Number of iterations = 1 >>>> Residual norm 2.22684e-11 >>>> >>>> Mark, >>>> >>>> Could you provide the exact specifications on how you obtained this bad highest eigen estimate? What code you ran with what options? >>>> >>>> Thanks >>>> >>>> barry >>>> >>>> >>>> On Mar 30, 2012, at 10:22 AM, Mark F. Adams wrote: >>>> >>>>> I've had problems with GMRES and eigen estimates in the past but I now have a smoking gun. It seems that if you give GMRES an operator preconditioned with LU (ie, the preconditioned operator is the identity) GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a prefect max=1.0, min=0.0. >>>>> >>>>> Any thoughts? >>>>> >>>>> Mark >>>> >>>> >>> >> >> >

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Mark F. Adams 03 Apr '12

03 Apr '12

On Apr 3, 2012, at 5:21 PM, Jed Brown wrote: > On Tue, Apr 3, 2012 at 14:05, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > 2) "I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. " But doesn't GMRES compute the norms always? So why not have the GMRES version still kick out early if the norm reduces by same 10^10 before it ran out of its? (Since the norm is "free" for GMRES there is no harm done, and good things occasionly like your case below. > > Yeah, though this is an ideal scenario for TSQR-based GMRES in which case we would have done several iterations with one reduction. You will still have the norms, but I guess we will need to check them and decide which estimates to use. So I guess no problem at this point, but something to keep in mind with spectral estimates using TSQR-based or pipelined (latency-tolerant) GMRES. > > Mark, because CG runs in a norm that is stronger with respect to low frequencies/weaker with respect to high frequencies, but we only want an accurate estimate of the highest eigenvalue, I would expect GMRES to give this estimate sooner. Do you not observe this? Good question. Here is a run with 3 levels so there are two eigen estimates. You are correct, GMRES does converge a little faster for the max and a little slower for the min. And CG seems to insist on printing a zero residual. I guess this is just a result of avoiding norms. Mark CG: ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>./ex54 -ne 135 -pc_type gamg -pc_gamg_type agg -pc_gamg_agg_nsmooths 1 -gamg_est_ksp_type cg -gamg_est_ksp_monitor_singular_value 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 1 KSP Residual norm 0.000000000000e+00 % max 2.677871971586e-01 min 2.677871971586e-01 max/min 1.000000000000e+00 2 KSP Residual norm 0.000000000000e+00 % max 1.178406447035e+00 min 2.782878721360e-02 max/min 4.234487252321e+01 3 KSP Residual norm 0.000000000000e+00 % max 1.295357743832e+00 min 1.289180496594e-02 max/min 1.004791607734e+02 4 KSP Residual norm 0.000000000000e+00 % max 1.377111224506e+00 min 8.245185509227e-03 max/min 1.670200413277e+02 5 KSP Residual norm 0.000000000000e+00 % max 1.416668985429e+00 min 6.233944059431e-03 max/min 2.272508338098e+02 6 KSP Residual norm 0.000000000000e+00 % max 1.437446869526e+00 min 5.139451386677e-03 max/min 2.796887763647e+02 7 KSP Residual norm 0.000000000000e+00 % max 1.451987912145e+00 min 4.353879932532e-03 max/min 3.334928694968e+02 8 KSP Residual norm 0.000000000000e+00 % max 1.461212123742e+00 min 3.836419697129e-03 max/min 3.808791110200e+02 9 KSP Residual norm 0.000000000000e+00 % max 1.468428563039e+00 min 3.443446852826e-03 max/min 4.264414773335e+02 10 KSP Residual norm 0.000000000000e+00 % max 1.473917390061e+00 min 3.155959145931e-03 max/min 4.670267648939e+02 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 1 KSP Residual norm 0.000000000000e+00 % max 3.731463368297e-01 min 3.731463368297e-01 max/min 1.000000000000e+00 2 KSP Residual norm 0.000000000000e+00 % max 1.140795712107e+00 min 7.606975601408e-02 max/min 1.499670528582e+01 3 KSP Residual norm 0.000000000000e+00 % max 1.246715143294e+00 min 4.723095576523e-02 max/min 2.639614471262e+01 4 KSP Residual norm 0.000000000000e+00 % max 1.304492706010e+00 min 3.548816479478e-02 max/min 3.675852818972e+01 5 KSP Residual norm 0.000000000000e+00 % max 1.339064891066e+00 min 2.928974832799e-02 max/min 4.571786947674e+01 6 KSP Residual norm 0.000000000000e+00 % max 1.364719855308e+00 min 2.585356504039e-02 max/min 5.278652492125e+01 7 KSP Residual norm 0.000000000000e+00 % max 1.383366179924e+00 min 2.423653250617e-02 max/min 5.707772675699e+01 8 KSP Residual norm 0.000000000000e+00 % max 1.397180344396e+00 min 2.360451873573e-02 max/min 5.919122351268e+01 9 KSP Residual norm 0.000000000000e+00 % max 1.411141928238e+00 min 2.338719976968e-02 max/min 6.033821672262e+01 10 KSP Residual norm 0.000000000000e+00 % max 1.421660786467e+00 min 2.330914344796e-02 max/min 6.099154993152e+01 GMRES: ~/Codes/petsc-dev/src/ksp/ksp/examples/tutorials>./ex54 -ne 135 -pc_type gamg -pc_gamg_type agg -pc_gamg_agg_nsmooths 1 -gamg_est_ksp_type gmres -gamg_est_ksp_monitor_singular_value 0 KSP Residual norm 1.273195256718e+04 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 1 KSP Residual norm 1.105116503803e+04 % max 5.381869113825e-01 min 5.381869113825e-01 max/min 1.000000000000e+00 2 KSP Residual norm 1.072035851222e+04 % max 1.198853107985e+00 min 1.128336750138e-01 max/min 1.062495844293e+01 3 KSP Residual norm 1.040578603788e+04 % max 1.310149119205e+00 min 4.889198675168e-02 max/min 2.679680672129e+01 4 KSP Residual norm 1.008271525691e+04 % max 1.385046534385e+00 min 2.794700407793e-02 max/min 4.955974996542e+01 5 KSP Residual norm 9.750140943634e+03 % max 1.420473714424e+00 min 1.875174857832e-02 max/min 7.575153370318e+01 6 KSP Residual norm 9.411807961244e+03 % max 1.439921821395e+00 min 1.387796837899e-02 max/min 1.037559520294e+02 7 KSP Residual norm 9.086106432868e+03 % max 1.453546997206e+00 min 1.093316796595e-02 max/min 1.329483825488e+02 8 KSP Residual norm 8.751995357843e+03 % max 1.462345097587e+00 min 8.917066518085e-03 max/min 1.639939653497e+02 9 KSP Residual norm 8.415392503374e+03 % max 1.469281241117e+00 min 7.482031676039e-03 max/min 1.963746352241e+02 10 KSP Residual norm 8.055020510666e+03 % max 1.474568667828e+00 min 6.374839697111e-03 max/min 2.313107055062e+02 0 KSP Residual norm 3.418335802887e+04 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 1 KSP Residual norm 2.716382450945e+04 % max 6.064797825097e-01 min 6.064797825097e-01 max/min 1.000000000000e+00 2 KSP Residual norm 2.382340806549e+04 % max 1.166216020692e+00 min 1.546654696000e-01 max/min 7.540248147875e+00 3 KSP Residual norm 2.048023676521e+04 % max 1.257700703560e+00 min 8.148891675652e-02 max/min 1.543400935514e+01 4 KSP Residual norm 1.743857244361e+04 % max 1.313218000974e+00 min 5.610179228991e-02 max/min 2.340777268198e+01 5 KSP Residual norm 1.474980880589e+04 % max 1.344309319181e+00 min 4.280428232291e-02 max/min 3.140595394264e+01 6 KSP Residual norm 1.182847619123e+04 % max 1.369057924040e+00 min 3.409813951386e-02 max/min 4.015051681876e+01 7 KSP Residual norm 8.561286364831e+03 % max 1.384773801525e+00 min 2.854304939538e-02 max/min 4.851527187384e+01 8 KSP Residual norm 5.288348832980e+03 % max 1.397116352802e+00 min 2.549931586128e-02 max/min 5.479034654900e+01 9 KSP Residual norm 2.172952130623e+03 % max 1.407520362981e+00 min 2.415200955394e-02 max/min 5.827756733192e+01 10 KSP Residual norm 9.782158609491e+02 % max 1.412688603202e+00 min 2.394214391587e-02 max/min 5.900426495498e+01

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Mark F. Adams 03 Apr '12

03 Apr '12

On Apr 3, 2012, at 5:05 PM, Barry Smith wrote: > > > So? > > 1) You get lucky and CG gives you a zero residual right off the bat while GMRES does not. I don't quite understand the CG results. I assume that CG applies the preconditioner before the iteration (I recall seeing that in the code at one point) and so it never sees a residual. GMRES seems to have different behavior ... CG also seems to stop after 7 iterations. Not clear why that happens (max its is set to 10). > > 2) "I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. " But doesn't GMRES compute the norms always? So why not have the GMRES version still kick out early if the norm reduces by same 10^10 before it ran out of its? (Since the norm is "free" for GMRES there is no harm done, and good things occasionly like your case below. > I use this code: ierr = KSPSetNormType( eksp, KSP_NORM_NONE ); CHKERRQ(ierr); ierr = KSPSetOptionsPrefix(eksp,((PetscObject)pc)->prefix);CHKERRQ(ierr); ierr = KSPAppendOptionsPrefix( eksp, "gamg_est_"); CHKERRQ(ierr); ierr = KSPSetFromOptions( eksp ); CHKERRQ(ierr); So I assume that the KSP_NORM_NONE turns off convergence checking. Mark > Barry > > > On Apr 3, 2012, at 3:46 PM, Mark F. Adams wrote: > >> Sorry false alarm. >> >> Running in KSP tutorials (this creates a GASM PC that is just one block with the whole domain): >> >> ./ex54 -ne 5 -pc_type gamg -pc_gamg_type agg -pc_gamg_agg_nsmooths 1 -pc_gamg_verbose 2 -pc_gamg_use_agg_gasm -mat_coarsen_type hem -pc_gamg_square_graph false -mg_levels_sub_pc_type lu -gamg_est_ksp_type gmres -options_left -ksp_monitor -gamg_est_ksp_monitor_singular_value -gamg_est_ksp_view >> >> I get: >> >> 0 KSP Residual norm 6.446415297424e+01 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 1 KSP Residual norm 2.366096117202e-14 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 2 KSP Residual norm 1.540964857879e-14 % max 1.693380955892e+00 min 7.781997678493e-01 max/min 2.176023465763e+00 >> 3 KSP Residual norm 1.241326996942e-14 % max 2.530597391197e+00 min 7.364405777662e-01 max/min 3.436254692636e+00 >> 4 KSP Residual norm 1.063574617851e-14 % max 3.476067169257e+00 min 7.236790329140e-01 max/min 4.803327181195e+00 >> 5 KSP Residual norm 9.458672353406e-15 % max 4.436589616128e+00 min 7.159721822673e-01 max/min 6.196594959987e+00 >> 6 KSP Residual norm 8.601272732515e-15 % max 5.409099625105e+00 min 7.111665034107e-01 max/min 7.605953878822e+00 >> 7 KSP Residual norm 7.941524085286e-15 % max 6.390434791698e+00 min 7.078275282801e-01 max/min 9.028237157187e+00 >> 8 KSP Residual norm 7.413487448731e-15 % max 7.377240678599e+00 min 7.053779875665e-01 max/min 1.045856378939e+01 >> 9 KSP Residual norm 6.978470326179e-15 % max 8.367510521210e+00 min 7.035029387897e-01 max/min 1.189406619339e+01 >> 10 KSP Residual norm 6.612020575839e-15 % max 9.360078579306e+00 min 7.020212846961e-01 max/min 1.333304101080e+01 >> >> The problem is that I turn off norms for this -- its in the eigen estimate -- because I don't usually want them. Here they would have stopped the iterations and all would have been good. >> >> BTW, CG does this: >> >> 0 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 1 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 2 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 3 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 4 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 5 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 6 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> 7 KSP Residual norm 0.000000000000e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >> PCSetUp_GAMG PC setup max eigen=1.000000e+00 min=0.000000e+00 on level 1 (N=36) >> >> Is it using a preconditioned norm perhaps.... >> >> Mark >> >> On Apr 3, 2012, at 2:06 PM, Barry Smith wrote: >> >>> >>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type gmres -ksp_monitor_singular_value >>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 1 KSP Residual norm 2.708628636814e-10 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> Number of iterations = 1 >>> Residual norm 2.36559e-11 >>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type fgmres -ksp_monitor_singular_value >>> 0 KSP Residual norm 7.410897708964e+00 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 1 KSP Residual norm 2.157675690523e-11 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>> Number of iterations = 1 >>> Residual norm 2.26094e-11 >>> barry-smiths-macbook-pro:tutorials barrysmith$ ./ex10 -f0 ~/Datafiles/Matrices/arco1 -pc_type lu -ksp_type cg -ksp_monitor_singular_value >>> 0 KSP Residual norm 2.544968574075e+03 % max 1.000000000000e+00 min 1.000000000000e+00 max/min 1.000000000000e+00 >>> 1 KSP Residual norm 3.135993325987e-10 % max 9.999999999999e-01 min 9.999999999999e-01 max/min 1.000000000000e+00 >>> Number of iterations = 1 >>> Residual norm 2.22684e-11 >>> >>> Mark, >>> >>> Could you provide the exact specifications on how you obtained this bad highest eigen estimate? What code you ran with what options? >>> >>> Thanks >>> >>> barry >>> >>> >>> On Mar 30, 2012, at 10:22 AM, Mark F. Adams wrote: >>> >>>> I've had problems with GMRES and eigen estimates in the past but I now have a smoking gun. It seems that if you give GMRES an operator preconditioned with LU (ie, the preconditioned operator is the identity) GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a prefect max=1.0, min=0.0. >>>> >>>> Any thoughts? >>>> >>>> Mark >>> >>> >> > >

1 0