Paul: It might be caused by our changes in default shift strategy. We previously used '-pc_factor_shift_type NONZERO' for ilu, then changed to '-pc_factor_shift_type NONE'. For your test, I get ./ex10 -f0 test.mat -rhs 0 -pc_type asm -pc_asm_overlap 12 -sub_pc_type ilu -sub_pc_factor_mat_ordering_type 1wd -sub_pc_factor_levels 4 -ksp_converged_reason -sub_pc_factor_shift_type NONZERO
Linear solve converged due to CONVERGED_RTOL iterations 2 Number of iterations = 2 Residual norm 0.0116896 with '-sub_pc_factor_shift_type INBLOCKS': Linear solve converged due to CONVERGED_RTOL iterations 2 Number of iterations = 2 Residual norm 0.00603736 I guess your previous run might use one of these options. Hong Thanks Hong, > > On Thu, Jan 21, 2016 at 12:16 PM, Hong <[email protected]> wrote: > >> Paul : >> Using petsc-dev (we recently added feature for better displaying >> convergence behavior), >> > > OK, good to know, thanks. > > >> I found that '-sub_pc_factor_mat_ordering_type 1wd' causes zero pivot: >> > > I figured it was something along these lines. So, just so I'm clear, > likely this zero pivot was always there with this mat ordering (i.e. no mat > ordering bits actually changed between 3.5 and 3.6) and this is a > reflection of increased consistency checking in the newer PETSc? > > Thanks much, > > Paul >
