[petsc-dev] funny mg behavior

[Mark F. Adams]

KSPSetTolerance seems to have worked, the iteration count went down, but -ksp_view is confusing here.  I've been thinking that the "smooths=1 --------------------" means there is one smoothing step, which I now see is not the case.  (I just noticed "maximum iterations=2")

Mark

Down solver (pre-smoother) on level 1 smooths=1 --------------------
    KSP Object:    (mg_levels_1_)     1 MPI processes    
      type: chebychev
        Chebychev: eigenvalue estimates:  min = 0.091254, max = 1.90465
      maximum iterations=2
      tolerances:  relative=1e-05, absolute=1e-50, divergence=10000
      left preconditioning
      using nonzero initial guess
      using NONE norm type for convergence test
    PC Object:    (mg_levels_1_)     1 MPI processes    
      type: jacobi
      linear system matrix = precond matrix:
      Matrix Object:       1 MPI processes      
        type: seqaij
        rows=2445, cols=2445
        total: nonzeros=83025, allocated nonzeros=83025
        total number of mallocs used during MatSetValues calls =0
          using I-node routines: found 815 nodes, limit used is 5
  Up solver (post-smoother) same as down solver (pre-smoother)
  Down solver (pre-smoother) on level 2 smooths=1 --------------------
    KSP Object:    (mg_levels_2_)     1 MPI processes    
      type: chebychev
        Chebychev: eigenvalue estimates:  min = 0.133588, max = 2.34089
      maximum iterations=2
      tolerances:  relative=1e-05, absolute=1e-50, divergence=10000
      left preconditioning
      using nonzero initial guess
      using NONE norm type for convergence test
    PC Object:    (mg_levels_2_)     1 MPI processes    
      type: jacobi
      linear system matrix = precond matrix:
      Matrix Object:       1 MPI processes      
        type: seqaij
        rows=20402, cols=20402
        total: nonzeros=362404, allocated nonzeros=367236
        total number of mallocs used during MatSetValues calls =0
          using I-node routines: found 10201 nodes, limit used is 5
  Up solver (post-smoother) same as down solver (pre-smoother)
  linear system matrix followed by preconditioner matrix:


On Aug 7, 2011, at 7:50 PM, Barry Smith wrote:

> 
> On Aug 7, 2011, at 5:26 PM, Mark F. Adams wrote:
> 
>> I'm finding what looks like strange behavior with respect to setting the number of pre/post smooths in PCMG.  I setup my PCMG with a line:
>> 
>> ierr = PCMGGetSmoother( a_pc, lidx, &smoother ); CHKERRQ(ierr);
>> 
>> [ set it up ... ]
>> 
>> It seems that this method has a side effect of setting the use-same-smoother-for-pre-and-post state, or this is default.
> 
>   This is the default to use the same smoother up and down. 
> 
>> 
>> The problem is that if I try to set the number of smoothing steps with code:
>> 
>> ierr = PCMGSetNumberSmoothDown(a_pc,2); CHKERRQ(ierr);
>> ierr = PCMGSetNumberSmoothUp(a_pc,2); CHKERRQ(ierr);
> 
> 
>> 
>> or command lines:  -pc_mg_smoothdown 2 -pc_mg_smoothup 2
>> 
>> it unsets the use-same-smoother-for-pre-and-post state.
> 
>   Yes, the logic is if you do anything with either Up() or Down() specifically in the name it automatically creates a different up and down, assuming that you want to do something different for each since you are specially 
> setting an up or down. Unfortunately looking at the manual pages I see this is not documented; will fix.
> 
>> Then I get GMRES/ILU as my up (post) smoother (ie, a default solver), with my carefully crafted smoother only used for pre smoothing.
> 
>   Yes, this will screw you up. As you report.
> 
>> Not what I want.
>> 
>> Am I missing something or did a hole form in PETSc's logic at some point?  Perhaps there should be a PCMGSetNumberSmooth and '-pc_mg_smooth n' option that does not have this side effect?
> 
>   There is a way to do what you want. Instead of calling PCMGSetNumberSmoothDown() or PCMGSetNumberSmoothUp() you use PCMGGetSmoother() and then call KSPSetTolerance() on those to change the iterations (not you can pass PETSC_DEFAULT for arguments you do not want changed).  Unfortunately you need to do this for each level, rather than one command. From the command line call -mg_levels_ksp_max_it <it>.   or -mg_levels_1_ksp_max_it <it> for a specific level (in this case 1) only.
> 
>   That said, the current commands are confusing and could possibly be improved.
> 
> 1)    The PCMGSetNumberSmoothDown() and PCMGSetNumberSmoothUp() are redundant and should be removed. Rather one should call PCMGGetSmootherUp() and KSP calls on that and similarly PCMGGetSmootherDown() and KSP calls on that to set different values. Having the PCMGSetNumberSmoothUp/Down() and not PCMGSetNumberSmooth() is confusing.  This is easily fixed
> 
> 2)   The command line arguments -pc_mg_smoothdown 2 -pc_mg_smoothup 2 are not so easily removed. Without them there is no way to set different options for up and down from the command line.  But they don't allow setting other different KSP options for up and down.  I think we need to change the code a bit and have -pc_mg_different_up_down (ugly name) and then if that is triggered it automatically makes  different up and down smoothers whose options are -mg_levels_up_%d_xxxxx and -mg_levels_down_%d_xxxxx 
> 
>  An alternative to these changes is to simply 
> 
> A)  add PCMGSetNumberSmooth(), not an orthogonal operation but clean and simple so maybe better. Note this does not fix the problem that other smoother command line options always affect both up and down so I don't like this one.
> 
> 
>  Thoughts?
> 
>   Barry
> 
> BTW: I know the convention is to call them pre and post smoothers; but I have trouble remembering the positions of pre and post so used down and up instead.
> 
> 
> 
>> 
>> Mark
>> 
>> 
> 
>