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
>>
>>
>
>
