Ed,
This is something that requires some code reorganization.
We've always treated the "inability to construct a preconditioner" as a
hard error generating a SETERRQ() regardless of whether the problem came from a
numerical issue (such as zero pivot) or bad user input etc. We need to change
the code to allow treating it as a soft error that can be recovered from but
this means being able to return the information about a failed factorization up
from the matrix implementation level to the matrix interface level to the PC
and then to the KSP. It will take some thought on how to do this well. Can you
add this as an issue on the bitbucket site.
Barry
I tried at one point to generalize the PETSc error management to allow
recovering from errors, much like exceptions in C++, but decided it was too
difficult to organize properly in C so we currently have the model that the
error management is only for hard errors and soft errors need to have regular
code paths to handle them. Unfortunately adding the needed code paths for some
things like zero pivots requires a good amount of thought and new coding.
Another example where lots of plumbing needs to be put in is software recovery
from cases where user function evaluations generate domain errors in, for
example, a matrix-free matrix-vector product.
> On Apr 8, 2015, at 11:08 AM, Ed Bueler <[email protected]> wrote:
>
> Dear PETSc --
>
> Context: I am solving a not very smooth and very nonlinear problem using
> SNES. Robustness is an issue but I think there is no theory to help me, and
> I am stuck mollifying the problem a bit when divergence happens. Thus I deal
> with the returned divergence reason (i.e. SNESConvergedReason) by making the
> problem slightly easier. This deals with DIVERGED_LINE_SEARCH and
> DIVERGED_LINEAR_SOLVE the way I want, for example.
>
> The problem is that sometimes zero pivots occur, either in default (GMRES+ILU
> or GMRES+BJACOBI+sub_ILU) or in domain decomposition (GMRES+ASM+sub_LU).
>
> I want to catch and deal with these zero pivots in the same way, ideally. Is
> there a way to make zero pivot propagate through to generate a new negative
> SNESConvergedReason? Note that DIVERGED_LINEAR_SOLVE would tell me enough;
> it seems to me a zero pivot during application of the preconditioner *is* a
> DIVERGED_LINEAR_SOLVE error anyway.
>
> If not, can I at least catch the zero pivot error so it is not an error (i.e.
> so the program continues), without ignoring all errors? I think I don't want
> to push PetscIgnoreErrorHandler, because I am happy with how other errors are
> handled.
>
> Thanks,
>
> Ed
>
> --
> Ed Bueler
> Dept of Math and Stat and Geophysical Institute
> University of Alaska Fairbanks
> Fairbanks, AK 99775-6660
> 301C Chapman and 410D Elvey
> 907 474-7693 and 907 474-7199 (fax 907 474-5394)
