[petsc-users] Call multiple error handler

[Matthew Knepley]

On Wed, Jan 11, 2017 at 7:00 AM, Florian Lindner <mailinglists at xgm.de>
wrote:

> Hey,
>
> Am 10.01.2017 um 14:20 schrieb Barry Smith:
> >
> > I do not understand what you mean. I hope this is C.
>
> Yes, I'm talking about C(++).
>
> I'm using PETSc functions like that:
>
>   ierr = ISDestroy(&ISlocal); CHKERRV(ierr);
>
> Unfortunately that is not alway possible, e.g. in this function:
>
> std::pair<PetscInt, PetscInt> Vector::ownerRange()
> {
>   PetscInt range_start, range_end;
>   VecGetOwnershipRange(vector, &range_start, &range_end);
>   return std::make_pair(range_start, range_end);
> }
>
> CHKERRV would returns void, CHKERRQ returns an int (iirc). Neither is
> possible here. But that is not my main issue here.
>
> For non PETSc related functions, I do not use CHKERRV and alike.
>
> >
> > By default when an error is detected PetscError using
> PetscTraceBackErrorHandler returns up the stack printing the
> > function/line number then returning to the next function which prints
> the function/line number until it gets up to
> > the function main where it calls MPI_Abort.
>
> Ok, we use petsc like that:
>
> void myFunc() {
>    PetscErrorCode ierr = 0;
>    ierr = MatMultTranspose(_matrixA, in, Au); CHKERRV(ierr);
>    [... no further error checking ...]
> }
>
> with the standard error handler this gives a nice traceback, but the
> application continues to run.
>
> With a PetscPushErrorHandler(&PetscMPIAbortErrorHandler, nullptr); above
> these lines, that gives no traceback, just
>
> [0]PETSC ERROR: MatMult() line 2244 in /home/florian/software/petsc/
> src/mat/interface/matrix.c
>     Null Object: Parameter # 1
>
> and the application aborts.
>
> I want to combine these two traits. Print a nice traceback like the first
> example, then abort, like the second example.
>

The problematic part of this strategy is that you want the handler to
"know" where it is. Right now, the handler has no
idea where the top of the stack is, it just executes some action. In the
normal case, it adds a line to the sack and returns.
In the latter, it aborts.

If you want different behavior, one option is to change the check at the
level which you think is the top. So, at the uppermost
check of a PETSc function, you use CHKERRA instead.

  Thanks,

     Matt


>
> > Now if one of the functions in the stack of functions is a user function
> that DOES NOT check a return code with
> > CHKERRQ(ierr) then bad stuff happens because PetscError will print part
> of the stack of functions but then the user
> > code (that ignores the error code) continues running generally causing
> bad and confusing things to happen.  This is
> > why we recommend always using CHKERRQ() in user code.
> >
> > From the perspective of PETSc error handling there really isn't any
> difference between user code and PETSc code.
>
> I understand that. But changing our application so that every function
> returns an error code and is checked using
> CHKERR* is not an option. The PETSc code is buried deeply in the framework.
>
>
> >> However, I want my application to be aborted with the
> PetscMPIAbortErrorHandler when an error occures.
> >
> > Do you mean that in your code when you detect an error you want
> SETERRQ() to call PetscMPIAbortErrorHandler()  but in
> > PETSc code you want it to try to return through the stack printing the
> PETSc function/line numbers? You can do this
> > by making your own macro mySETERRQ() that is defined to be a call to
> PetscMPIAbortErrorHandler and using mySETERRQ()
> > to mark errors in your code.  Though I do not recommend this, better to
> use CHKERRQ() in your code and get error
> > tracebacks for PETSc code and your code.
>
> Ok, I'll keep that option in mind...
>
> Best,
> Florian
>
> >> On Jan 10, 2017, at 6:42 AM, Florian Lindner <mailinglists at xgm.de>
> wrote:
> >>
> >> Hello,
> >>
> >> I really enjoy the verbosity (line number) of the default
> PetscTraceBackErrorHandler. However, I want my
> >> application to be aborted with the PetscMPIAbortErrorHandler when an
> error occures.
> >>
> >> Can I instruct PETSc to call first one handler, then another one?
> >>
> >> Thanks, Florian
> >
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170111/1adbf1d7/attachment.html>