PETSc developers, I tried implementing a system for automatically increasing MUMPS ICNTL(14), along the lines described in this recent thread. If SNESSolve returns ierr .ne. 0 due to MUMPS error -9, I call SNESDestroy, re-initialize SNES, call MatMumpsSetIcntl with a larger value of ICNTL(14), call SNESSolve again, and repeat as needed. The procedure works, but the peak memory required (as measured by the HPC system) is 50%-100% higher if the MUMPS solve has to be repeated compared to when MUMPS works on the 1st try (by starting with a large ICNTL(14)), even though SNESDestroy is called in between the attempts. Are there some PETSc or MUMPS structures which would not be deallocated immediately by SNESDestroy? If so, how do I deallocate them?
Thanks, Matt Landreman On Tue, Sep 15, 2015 at 7:47 AM, David Knezevic <[email protected]> wrote: > On Tue, Sep 15, 2015 at 7:29 PM, Matthew Knepley <[email protected]> > wrote: > >> On Tue, Sep 15, 2015 at 4:30 AM, David Knezevic < >> [email protected]> wrote: >> >>> In some cases, I get MUMPS error -9, i.e.: >>> [2]PETSC ERROR: Error reported by MUMPS in numerical factorization >>> phase: INFO(1)=-9, INFO(2)=98927 >>> >>> This is easily fixed by re-running the executable with >>> -mat_mumps_icntl_14 on the commandline. >>> >>> However, I would like to update my code in order to do this >>> automatically, i.e. detect the -9 error and re-run with the appropriate >>> option. Is there a recommended way to do this? It seems to me that I could >>> do this with a PETSc error handler (e.g. PetscPushErrorHandler) in order to >>> call a function that sets the appropriate option and solves again, is that >>> right? Are there any examples that illustrate this type of thing? >>> >> >> I would not use the error handler. I would just check the ierr return >> code from the solver. I think you need the >> INFO output, for which you can use MatMumpsGetInfo(). >> > > > OK, that sounds good (and much simpler than what I had in mind), thanks > for the help! > > David > >
