Added PCFactorGetZeroPivot(), PCFactorGetShiftType(), and PCFactorGetShiftAmount()

Time: .25 hours
Reported-by: Glenn E Hammond <gehammo@sandia.gov>

/sandbox/petsc/petsc.clone-3/src/ksp/pc/impls/factor/lu/lu.c:161:15: warning: comparison between 'MatFactorError' and 'enum <anonymous>' [-Wenum-compare]

Time: .1 hour
Reported-by: nightly tests

Update to patch commit 04545d6dccef0bc76f6a1a6548f816a384daa3de to make it work with master

Now the patch respects the data encapsulation of _p_Mat and does not access into it directly.

Time: .1 ho

Update to patch commit 04545d6dccef0bc76f6a1a6548f816a384daa3de to make it work with master

Now the patch respects the data encapsulation of _p_Mat and does not access into it directly.

Time: .1 hours

show more ...

Merge branch 'master' into barry/fix-successful-numerical-factorization-after-failure/master

The maint patch for the given problem cannot merge cleanly into next due to changes
in the same code in m

Merge branch 'master' into barry/fix-successful-numerical-factorization-after-failure/master

The maint patch for the given problem cannot merge cleanly into next due to changes
in the same code in master (the introduction of MatFactorGetError()) therefor need
to merge in master and use the new construct before merging to next

show more ...

If KSP failed with a zero numerical pivot in the numerical factorization of LU or Cholesky

must set the error flag to zero before the next factorization in PCSetUp_LU/Cholesky so it
does not false t

If KSP failed with a zero numerical pivot in the numerical factorization of LU or Cholesky

must set the error flag to zero before the next factorization in PCSetUp_LU/Cholesky so it
does not false trap that same error again. This error was introduced when we refactored to allow
PCSetUp() to not fail fatally on a zero pivot but instead return error codes in the PC/Mat

Time: 1 hour
Reported-by: Jose E. Roman <jroman@dsic.upv.es>

show more ...

removed a bunch of unneeded inclusions of xxximpl.h which exposed private data where it did not have to be exposed

also made more systematic the inclusion of the base xxximpl.h in the derived yyyimp

removed a bunch of unneeded inclusions of xxximpl.h which exposed private data where it did not have to be exposed

also made more systematic the inclusion of the base xxximpl.h in the derived yyyimpl.h
so the inclusion is done in the include file rather than in each source code that includes it

show more ...

set solvertype for inplace MatxxxFactor()

Fix null output from PCFactorGetMatSolverPackage();
Reported-by: Jose E. Roman <jroman@dsic.upv.es>