<div>The issue is your fieldsplit_1 solve. You are applying mumps to an approximate Schur complement - not the true Schur complement. Seemingly the approximation is dependent on the communicator size.</div><div><br></div><div>If you want to see iteration counts of 2, independent of mesh size and communicator size you need to solve the true Schur complement system (fieldsplit_1) to a specified tolerance (Erik 1e-10) - don't use preonly.</div><div><br></div><div>In practice you probably don't want to iterate on the Schur complement either as it is likely too expensive. If you provided fieldsplit with a spectrally equivalent approximation to S, iteration counts would be larger than two, but they would be independent of the number of elements and comm size</div><div><br></div><div>Thanks,</div><div>  Dave</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote"><div>On Wed, 4 Jan 2017 at 22:39, Karin&NiKo <<a href="mailto:niko.karin@gmail.com">niko.karin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Dear Petsc team,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I am (still) trying to solve Biot's poroelasticity problem :</div><div class="gmail_msg"> <img class="m_2175880395486641380m_461426253857996911gmail-CToWUd gmail_msg" alt="Images intégrées 1" src="cid:ii_158f8fd5ddeb7876" style="width:409px;max-width:100%"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I am using a mixed P2-P1 finite element discretization. The matrix of the discretized system in binary format is attached to this email.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 : </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-ksp_rtol 1.0e-5<br class="gmail_msg">-ksp_type fgmres<br class="gmail_msg">-pc_type fieldsplit<br class="gmail_msg">-pc_fieldsplit_schur_factorization_type full<br class="gmail_msg">-pc_fieldsplit_type schur<br class="gmail_msg">-pc_fieldsplit_schur_precondition selfp<br class="gmail_msg">-fieldsplit_0_pc_type lu<br class="gmail_msg">-fieldsplit_0_pc_factor_mat_solver_package mumps<br class="gmail_msg">-fieldsplit_0_ksp_type preonly<br class="gmail_msg">-fieldsplit_0_ksp_converged_reason<br class="gmail_msg">-fieldsplit_1_pc_type lu<br class="gmail_msg">-fieldsplit_1_pc_factor_mat_solver_package mumps<br class="gmail_msg">-fieldsplit_1_ksp_type preonly<br class="gmail_msg">-fieldsplit_1_ksp_converged_reason<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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]).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On 2 procs, the solver converges in 28 iterations (see Run-2-proc.txt).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On 3 procs, the solver converges in 91 iterations (see Run-3-proc.txt).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for your precious help,</div><div class="gmail_msg">Nicolas</div></div><br><br></div><br class="gmail_msg"></div><br><br></blockquote></div></div>