So are you saying that MKL_Padiso is returning inf/nan in the solution but a return code less than or equal to zero? - that's correct
Is this expected behavior of MKL Pardiso? - from what I can see, that does appear to be the expected behavior of Pardiso. I mean I guess it has solved the system correctly. Thanks Mark for the suggestion, that seems like a reasonable solution. Chris On Thu, Jul 11, 2024, 13:53 Barry Smith <bsm...@petsc.dev> wrote: > > We don't by default, for example, check the norm of the solution > returned by an external direct solver due to the added expense. > > We do check the error condition returned by MKL Pardiso with > > PetscCheck(mat_mkl_pardiso->err >= 0, PETSC_COMM_SELF, PETSC_ERR_LIB, > "Error reported by MKL PARDISO: err=%d. Please check manual", > mat_mkl_pardiso->err); > > except (I don't know why) in MatDestroy_MKL_PARDISO() > > So are you saying that MKL_Padiso is returning inf/nan in the solution but > a return code less than or equal to zero? Is this expected behavior of MKL > Pardiso? > > > > On Jul 10, 2024, at 5:01 PM, Chris Hewson <ch...@resfrac.com> wrote: > > This Message Is From an External Sender > This message came from outside your organization. > Hi There, > > We have a matrix that is singular and trying to solve it. We first use an > iterative solve with KSPBCGS, the solution vector is nan values and the > converged reason from PETSc of KSP_DIVERGED_NANORINF, that's great and what > I would expect. > > Sometimes in our program we redo a failed solve using the MKL Pardiso > solver, when the same matrix and vectors get put into that solver which is > a KSPPREONLY, I get KSP_CONVERGED_ITS as a converged reason and solution > vector with nan values in it. > > Stepping through the PETSc calls, I see that the external call to Pardiso > doesn't return an error for this, so not really the fault of PETSc, but > curious if y'all have seen this before or a solution/workaround to this? > > *Chris Hewson* > Senior Reservoir Simulation Engineer > ResFrac > +1.587.575.9792 > > >
