On Fri, Oct 5, 2012 at 2:33 PM, Zhenglun (Alan) Wei <span dir="ltr"><<a href="mailto:zhenglun.wei@gmail.com" target="_blank">zhenglun.wei@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Dear Dr. Brown, <br>
           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. <br>
           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<br>
      <i>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</i><br>
      <br>
           If I simply use <br>
      <i>mpiexec -np 8 ./ex45 -ksp_monitor_true_residual
        -ksp_converged_reason -log_summary > out</i><br>
      <br>
           Everything works fine. Therefore, I did more tests and found
      out that the "-pc_type exotic" has some problem. </div></blockquote><div><br></div><div>PCEXOTIC is a special purpose, and mostly experimental, method.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Now I changed it
      to "-pc_type gamg"; like, <br>
      <i>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</i></div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><i>
      </i><br>
           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. <br>
            " 0 KSP unpreconditioned resid norm 1.800295456670e+01 true
      resid norm 1.800295456670e+01 ||r(i)||/||b|| 1.000000000000e+00"<br>
           <br>
            However, if I changed the 'ksp_type' from 'fgmres' to 'cg',
      it would give me:<br>
            "0 KSP preconditioned resid norm 1.117293929796e+02 true
      resid norm 1.800293604638e+01 ||r(i)||/||b|| 1.000000000000e+00"<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
      <br>
            The finial question: what are the choice for the <i>'</i>-mg_levels_ksp_type'.
      Are they as the same as 'ksp_type'?</div></blockquote></div><br><div>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.</div>