<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dave,<br>
<br>
I am using a 2D decomposition, so if I increase the number of
levels, I have to decrease the number of processors I am using<br>
in order to have enough grid points per processor for the multigrid
to work.<br>
<br>
Michele<br>
<br>
<div class="moz-cite-prefix">On 10/02/2013 03:05 PM, Dave May wrote:<br>
</div>
<blockquote
cite="mid:CAJ98EDo84sXF7pUyCxyV_6DjOAk8AiiZWn5jLHUaOtqVmW=6AA@mail.gmail.com"
type="cite">And why are you fixed on 5 levels?<br>
<br>
On Wednesday, 2 October 2013, Barry Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Something is wrong, you should be getting better convergence.
Please answer my other email.<br>
<br>
<br>
On Oct 2, 2013, at 1:10 PM, Michele Rosso <<a
moz-do-not-send="true" href="javascript:;" onclick="_e(event,
'cvml', 'mrosso@uci.edu')">mrosso@uci.edu</a>> wrote:<br>
<br>
> Thank you all for your contribution.<br>
> So far the fastest solution is still the initial one
proposed by Jed in an earlier round:<br>
><br>
> -ksp_atol 1e-9 -ksp_monitor_true_residual -ksp_view
-log_summary -mg_coarse_pc_factor_mat_solver_package
superlu_dist<br>
> -mg_coarse_pc_type lu -mg_levels_ksp_max_it 3
-mg_levels_ksp_type richardson -options_left -pc_mg_galerkin<br>
> -pc_mg_levels 5 -pc_mg_log -pc_type mg<br>
><br>
> where I used -mg_levels_ksp_max_it 3 as Barry suggested
instead of -mg_levels_ksp_max_it 1.<br>
> I attached the diagnostics for this case. Any further idea?<br>
> Thank you,<br>
><br>
> Michele<br>
><br>
><br>
> On 10/01/2013 11:44 PM, Barry Smith wrote:<br>
>> On Oct 2, 2013, at 12:28 AM, Jed Brown <<a
moz-do-not-send="true" href="javascript:;" onclick="_e(event,
'cvml', 'jedbrown@mcs.anl.gov')">jedbrown@mcs.anl.gov</a>>
wrote:<br>
>><br>
>>> "Mark F. Adams" <<a moz-do-not-send="true"
href="javascript:;" onclick="_e(event, 'cvml',
'mfadams@lbl.gov')">mfadams@lbl.gov</a>> writes:<br>
>>>> run3.txt uses:<br>
>>>><br>
>>>> -ksp_type richardson<br>
>>>><br>
>>>> This is bad and I doubt anyone recommended it
intentionally.<br>
>> Hell this is normal multigrid without a Krylov
accelerator. Under normal circumstances with geometric multigrid
this should be fine, often the best choice.<br>
>><br>
>>> I would have expected FGMRES, but Barry likes
Krylov smoothers and<br>
>>> Richardson is one of a few methods that can
tolerate nonlinear<br>
>>> preconditioners.<br>
>>><br>
>>>> You also have, in this file,<br>
>>>><br>
>>>> -mg_levels_ksp_type gmres<br>
>>>><br>
>>>> did you or the recommenders mean<br>
>>>><br>
>>>> -mg_levels_ksp_type richardson ???<br>
>>>><br>
>>>> you are using gmres here, which forces you to
use fgmres in the outer solver. This is a safe thing to use you
if you apply your BCa symmetrically with a low order
discretization then<br>
>>>><br>
>>>> -ksp_type cg<br>
>>>> -mg_levels_ksp_type richardson<br>
>>>> -mg_levels_pc_type sor<br>
>>>><br>
>>>> is what I'd recommend.<br>
>>> I thought that was tried in an earlier round.<br>
>>><br>
>>> I don't understand why SOR preconditioning in the
Krylov smoother is so<br>
>>> drastically more expensive than BJacobi/ILU and why
SOR is called so<br>
>>> many more times even though the number of outer
iterations<br>
>>><br>
>>> bjacobi: PCApply 322 1.0 4.1021e+01
1.0 6.44e+09 1.0 3.0e+07 1.6e+03 4.5e+04 74 86 98 88 92
28160064317351226 20106<br>
>>> bjacobi: KSPSolve 46 1.0 4.6268e+01
1.0 7.52e+09 1.0 3.0e+07 1.8e+03 4.8e+04 83100100 99 99
31670065158291309 20800<br>
>>><br>
>>> sor: PCApply 1132 1.0 1.5532e+02
1.0 2.30e+10 1.0 1.0e+08 1.6e+03 1.6e+05 69 88 99 88 93
21871774317301274 18987<br>
>>> sor: KSPSolve 201 1.0 1.7101e+02
1.0 2.63e+10 1.0 1.1e+08 1.8e+03 1.7e+05 75100100 99 98
24081775248221352 19652<br>
>><br>
><br>
> <best.txt><br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>