[petsc-users] traceback & error handling

Andreas Mang andreas at ices.utexas.edu
Mon Dec 19 16:30:07 CST 2016


Hey Satish:

Thanks for your help. I did not mention this, but it’s both for intel compilers (modules intel15 and intel17). I have not checked in detail. I think I’ll opt for your second suggestion. I do not want to introduce compiler specific defines excessively throughout my code.

Considering the error handling: Sorry for not being precise. I am referring to any of the examples in the documentation (I did not check all, obviously). Here are two:

http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/examples/tutorials/ex1.c.html <http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/pc/examples/tutorials/ex1.c.html>

or a more sophisticated one:

http://www.mcs.anl.gov/petsc/petsc-current/src/tao/bound/examples/tutorials/plate2.c.html <http://www.mcs.anl.gov/petsc/petsc-current/src/tao/bound/examples/tutorials/plate2.c.html>

None of these examples for user routines contain any CHKERRQ calls anymore.

A

[Metainfo: A student asked me why I use these; I explained and referred him to the documentation; we then discovered that the examples do not use the error handling any longer]



> On Dec 19, 2016, at 4:09 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> PETSc code doesn't use classes - so we don't see this isssue.
> 
> One way to fix this is:
> 
> #undef #undef __FUNCT__
> 
> #if (__INTEL_COMPILER)
> #define __FUNCT__ “ClassName::FunctionName”
> #else
> #define __FUNCT__ “FunctionName”
> #endif
> 
> Alternative is to not do this check For compiles that define __func__
> [like intel, gcc] __FUNCT__ is not used anyway. So perhaps the following
> will work? [without having to modify petsc include files]
> 
> #undef PetscCheck__FUNCT__
> #define PetscCheck__FUNCT__()
> 
> Wrt CHKERRQ() - which code are you refering to?
> 
> Satish
> 
> On Mon, 19 Dec 2016, Andreas Mang wrote:
> 
>> Hey guys:
>> 
>> I have some problems with the error handling. On my local machine (where I debug) I get a million warning messages if I do
>> 
>> #undef __FUNCT__
>> #define __FUNCT__ “ClassName::FunctionName”
>> 
>> (i.e., file.cpp:XXX: __FUNCT__=“ClassName::FunctionName" does not agree with __func__=“FunctionName”)
>> 
>> If I run the same code using intel15 compilers it’s the opposite (which I discovered just now). That is, I get an error for
>> 
>> #undef __FUNCT__
>> #define __FUNCT__ “FunctionName”
>> 
>> (i.e., file.cpp:XXX: __FUNCT__=“FunctionName" does not agree with __func__=“ClassName::FunctionName”)
>> 
>> I do like the error handling by PETSc. I think it’s quite helpful. Obviously, I can write my own stack trace but why bother if it’s already there. I did check your online documentation and I could no longer find these definitions in your code. So, should I just remove all of these definitions? Is there a quick fix? Is this depreciated? 
>> 
>> 
>> Second of all, I saw you do no longer use error handling in your examples at all, i.e.,
>> 
>> ierr = FunctionCall(); CHKERRQ(ierr);
>> 
>> and friends have vanished. Why is that? Is it just to keep the examples simple or are you moving away from using these Macros for error handling.
>> 
>> I hope I did not miss any changes in this regard in one of your announcements. I could not find anything in the documentation.
>> 
>> Thanks
>> Andreas
>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20161219/2400f293/attachment.html>


More information about the petsc-users mailing list