<div dir="ltr">I use proactive <b>point</b> GS which updates the RHS of neighbours instead of updating the variable itself in subsequent iterations. I use natural ordering. I am sure that the matrices are the same for both solvers.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 4:48 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Ok, we need to understand what is algorithmically different between what your code is doing and PETSc is doing.<br>
<br>
From below PETSc is running a symmetric point block SOR with a block size of 5. Are you using a point or point block GS? Are you using any particular ordering of the unknowns in your GS, or just natural ordering? Are you sure the matrices are the same between the two codes? Print them out for a tiny grid and compare.<br>
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Mar 1, 2015, at 4:33 PM, Orxan Shibliyev <<a href="mailto:orxan.shibli@gmail.com">orxan.shibli@gmail.com</a>> wrote:<br>
><br>
> I don't run in parallel. I tried -ksp_richardson -pc_type but still<br>
> cannot get over CFL=5 (with my own GS code CFL=40 was converging).<br>
> Also, lowering damping factor does not help. Default number of<br>
> iterations (10000) does not help as well. -ksp_view outputs:<br>
><br>
> KSP Object: 1 MPI processes<br>
> type: richardson<br>
> Richardson: damping factor=0.5<br>
> maximum iterations=10, initial guess is zero<br>
> tolerances: relative=1e-05, absolute=1e-50, divergence=10000<br>
> left preconditioning<br>
> using PRECONDITIONED norm type for convergence test<br>
> PC Object: 1 MPI processes<br>
> type: sor<br>
> SOR: type = local_symmetric, iterations = 1, local iterations = 1, omega = 1<br>
> linear system matrix = precond matrix:<br>
> Mat Object: 1 MPI processes<br>
> type: seqbaij<br>
> rows=13250, cols=13250, bs=5<br>
> total: nonzeros=261150, allocated nonzeros=1.325e+06<br>
> total number of mallocs used during MatSetValues calls =0<br>
> block size is 5<br>
><br>
> On Fri, Feb 27, 2015 at 4:30 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>><br>
>> Ok, please provide the rest of the information I asked for.<br>
>><br>
>> Barry<br>
>><br>
>>> On Feb 27, 2015, at 2:33 AM, Orxan Shibliyev <<a href="mailto:orxan.shibli@gmail.com">orxan.shibli@gmail.com</a>> wrote:<br>
>>><br>
>>> No. It does not converge at all or iow it diverges.<br>
>>><br>
>>> On Thu, Feb 26, 2015 at 9:36 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>>><br>
>>>> By stability I assume you mean the the GMRES does not converge (or converges too slowly)?<br>
>>>><br>
>>>> The way to improve GMRES convergence is with a preconditioner better suited to your problem. By default PETSc uses GMRES with a block Jacobi preconditioner with one block per process and ILU(0) on each block. For some problems this is fine, but for many problems it will give bad convergence.<br>
>>>><br>
>>>> What do you get for -ksp_view (are you using the default?) Are you running yet in parallel?<br>
>>>><br>
>>>> As a test on one process you can use GS in PETSc as the preconditioner and make sure you get similar convergence to your code. For example -ksp_richardson -pc_type sor on one processor will give you a GS solver.<br>
>>>><br>
>>>> Once we know a bit more about your problem we can suggest better preconditioners.<br>
>>>><br>
>>>> Barry<br>
>>>><br>
>>>><br>
>>>>> On Feb 26, 2015, at 10:25 PM, Orxan Shibliyev <<a href="mailto:orxan.shibli@gmail.com">orxan.shibli@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi<br>
>>>>><br>
>>>>> I tried to solve Ax=b with my own Gauss-Seidel code and Petsc's GMRES.<br>
>>>>> With my GS, for a steady state problem I can set CFL=40 and for<br>
>>>>> unsteady case can set dt=0.1. However, for GMRES I can't set CFL more<br>
>>>>> than 5 and for unsteady case dt more than 0.00001. I need GMRES for<br>
>>>>> parallel computations so I cannot use GS for this purpose. Is there a<br>
>>>>> way to improve the stability of GMRES?<br>
>>>><br>
>><br>
<br>
</div></div></blockquote></div><br></div>