[petsc-users] A similar question of "Enquiry regarding log summary results"
Zhenglun (Alan) Wei
zhenglun.wei at gmail.com
Fri Oct 5 14:51:55 CDT 2012
Dear Dr. Brown,
Thank you so much for your help. Your reply is really helpful and
knowledgeable.
sincerely,
Alan
On 10/5/2012 2:42 PM, Jed Brown wrote:
> On Fri, Oct 5, 2012 at 2:33 PM, Zhenglun (Alan) Wei
> <zhenglun.wei at gmail.com <mailto:zhenglun.wei at gmail.com>> wrote:
>
> Dear Dr. Brown,
> Thanks for your reply. I checked my grid partition by output
> the corner points of the local domain. There is no problem
> according to that.
> I ran the same case with smaller grid size with 8 cores and
> find that the code occupy a lot of memory and slow if I use the
> original script file which is
> /mpiexec -np 8 ./ex45 -pc_type exotic -ksp_type fgmres
> -mg_levels_ksp_type gmres -mg_levels_ksp_max_it 1
> -mg_levels_pc_type bjacobi -ksp_rtol 1.0e-7
> -ksp_monitor_true_residual -ksp_converged_reason -log_summary > out/
>
> If I simply use
> /mpiexec -np 8 ./ex45 -ksp_monitor_true_residual
> -ksp_converged_reason -log_summary > out/
>
> Everything works fine. Therefore, I did more tests and found
> out that the "-pc_type exotic" has some problem.
>
>
> PCEXOTIC is a special purpose, and mostly experimental, method.
>
> Now I changed it to "-pc_type gamg"; like,
> /mpiexec -np 8 ./ex45 -pc_type gamg -ksp_type fgmres
> -mg_levels_ksp_type gmres -mg_levels_ksp_max_it 1
> -mg_levels_pc_type bjacobi -ksp_rtol 1.0e-7
> -ksp_monitor_true_residual -ksp_converged_reason -log_summary > out/
>
>
> Add -pc_gamg_agg_nsmooths 1 to the options above and it will likely
> converge much faster (in exchange for somewhat higher setup, but you
> are spending almost no time in setup).
>
> Why are you using GMRES on levels? It will probably go faster if you
> drop all the -mg_levels_* options above (which will use Chebyshev and
> SOR, should converge fast, but has higher setup), perhaps going with
> -mg_levels_ksp_max_it 1 -mg_levels_ksp_type richardson which will
> probably also works fine without the setup cost.
>
> //
> it is super fast now, the log file is attached. However, I
> have another question that it always show that "unpreconditioned "
> although I already put pc_type over there.
> " 0 KSP unpreconditioned resid norm 1.800295456670e+01 true
> resid norm 1.800295456670e+01 ||r(i)||/||b|| 1.000000000000e+00"
>
> However, if I changed the 'ksp_type' from 'fgmres' to 'cg',
> it would give me:
> "0 KSP preconditioned resid norm 1.117293929796e+02 true
> resid norm 1.800293604638e+01 ||r(i)||/||b|| 1.000000000000e+00"
>
>
> This "preconditioned" versus "unpreconditioned" is reporting the norm
> used by the method, not whether preconditioning is being used. Note
> that you can only use CG (or normal GMRES) if the preconditioner is
> linear. Changing/removing the option -mg_levels_ksp_type gmres will
> make your method linear. Note that you can use normal GMRES in
> unpreconditioned norm (-ksp_norm_type unpreconditioned) so you don't
> have to pay for the extra memory and work done by FGMRES.
>
>
> The finial question: what are the choice for the
> /'/-mg_levels_ksp_type'. Are they as the same as 'ksp_type'?
>
>
> Yes, you can also tell this via -help. Usually you want to use a
> stationary method in the smoother, typically chebyshev or richardson.
> A "Krylov" method like GMRES or CG will make the multigrid cycle
> nonlinear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20121005/fa19dfab/attachment.html>
More information about the petsc-users
mailing list