[petsc-users] Call multiple error handler

[Florian Lindner]

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.


> 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
>