[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