[petsc-users] 3.5 -> 3.6 Change in MatOrdering Behavior

[Hong]

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 <hzhang at mcs.anl.gov> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160121/55cda276/attachment.html>