<div dir="ltr"><div><div><div>Dear Barry, dear Dave,<br><br></div>THANK YOU! <br></div>You two pointed out the right problem.By using the options you provided (-fieldsplit_0_ksp_type gmres -fieldsplit_0_ksp_pc_side right -fieldsplit_1_ksp_type gmres -fieldsplit_1_ksp_pc_side right), the solver converges in 3 iterations whatever the size of the communicator. <br>All the trick is in the precise resolution of the Schur complement, by using a Krylov method (and not only preonly) *and* applying the preconditioner on the right (so evaluating the convergence on the unpreconditioned residual).<br><br></div><div>@Barry : the difference you see on the nonzero allocations for the different runs is just an artefact : when using more than one proc, we slighly over-estimate the number of non-zero terms. If I run the same problem with the -info option, I get extra information : <br>[2] MatAssemblyEnd_SeqAIJ(): Matrix size: 110 X 110; storage space: 0 unneeded,5048 used<br>[1] MatAssemblyEnd_SeqAIJ(): Matrix size: 271 X 271; storage space: 4249 unneeded,26167 used<br>[0] MatAssemblyEnd_SeqAIJ(): Matrix size: 307 X 307; storage space: 7988 unneeded,31093 used<br>[2] MatAssemblyEnd_SeqAIJ(): Matrix size: 110 X 244; storage space: 0 unneeded,6194 used<br>[1] MatAssemblyEnd_SeqAIJ(): Matrix size: 271 X 233; storage space: 823 unneeded,9975 used<br>[0] MatAssemblyEnd_SeqAIJ(): Matrix size: 307 X 197; storage space: 823 unneeded,8263 used<br></div><div>And 5048+26167+31093+6194+9975+8263=86740 which is the number of exactly estimated nonzero terms for 1 proc.<br><br><br></div><div>Thank you again!<br><br></div><div>Best regards,<br></div><div>Nicolas<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-05 1:36 GMT+01:00 Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There is something wrong with your set up.<br>
<br>
1 process<br>
<br>
total: nonzeros=140616, allocated nonzeros=140616<br>
total: nonzeros=68940, allocated nonzeros=68940<br>
total: nonzeros=3584, allocated nonzeros=3584<br>
total: nonzeros=1000, allocated nonzeros=1000<br>
total: nonzeros=8400, allocated nonzeros=8400<br>
<br>
2 processes<br>
total: nonzeros=146498, allocated nonzeros=146498<br>
total: nonzeros=73470, allocated nonzeros=73470<br>
total: nonzeros=3038, allocated nonzeros=3038<br>
total: nonzeros=1110, allocated nonzeros=1110<br>
total: nonzeros=6080, allocated nonzeros=6080<br>
total: nonzeros=146498, allocated nonzeros=146498<br>
total: nonzeros=73470, allocated nonzeros=73470<br>
total: nonzeros=6080, allocated nonzeros=6080<br>
total: nonzeros=2846, allocated nonzeros=2846<br>
total: nonzeros=86740, allocated nonzeros=94187<br>
<br>
It looks like you are setting up the problem differently in parallel and seq. If it is suppose to be an identical problem then the number nonzeros should be the same in at least the first two matrices.<br>
<span class=""><br>
<br>
<br>
> On Jan 4, 2017, at 3:39 PM, Karin&NiKo <<a href="mailto:niko.karin@gmail.com">niko.karin@gmail.com</a>> wrote:<br>
><br>
</span><span class="">> Dear Petsc team,<br>
><br>
> I am (still) trying to solve Biot's poroelasticity problem :<br>
</span>> <image.png><br>
<span class="">><br>
> I am using a mixed P2-P1 finite element discretization. The matrix of the discretized system in binary format is attached to this email.<br>
><br>
> I am using the fieldsplit framework to solve the linear system. Since I am facing some troubles, I have decided to go back to simple things. Here are the options I am using :<br>
><br>
> -ksp_rtol 1.0e-5<br>
> -ksp_type fgmres<br>
> -pc_type fieldsplit<br>
> -pc_fieldsplit_schur_<wbr>factorization_type full<br>
> -pc_fieldsplit_type schur<br>
> -pc_fieldsplit_schur_<wbr>precondition selfp<br>
> -fieldsplit_0_pc_type lu<br>
> -fieldsplit_0_pc_factor_mat_<wbr>solver_package mumps<br>
> -fieldsplit_0_ksp_type preonly<br>
> -fieldsplit_0_ksp_converged_<wbr>reason<br>
> -fieldsplit_1_pc_type lu<br>
> -fieldsplit_1_pc_factor_mat_<wbr>solver_package mumps<br>
> -fieldsplit_1_ksp_type preonly<br>
> -fieldsplit_1_ksp_converged_<wbr>reason<br>
><br>
> On a single proc, everything runs fine : the solver converges in 3 iterations, according to the theory (see Run-1-proc.txt [contains -log_view]).<br>
><br>
> On 2 procs, the solver converges in 28 iterations (see Run-2-proc.txt).<br>
><br>
> On 3 procs, the solver converges in 91 iterations (see Run-3-proc.txt).<br>
><br>
> I do not understand this behavior : since MUMPS is a parallel direct solver, shouldn't the solver converge in max 3 iterations whatever the number of procs?<br>
><br>
><br>
> Thanks for your precious help,<br>
> Nicolas<br>
><br>
</span>> <Run-1-proc.txt><Run-2-proc.<wbr>txt><Run-3-proc.txt><1_<wbr>Warning.txt><br>
<br>
</blockquote></div><br></div>