[petsc-users] traceback & error handling

[Matthew Knepley]

On Mon, Dec 19, 2016 at 4:30 PM, Andreas Mang <andreas at ices.utexas.edu>
wrote:

> 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
>
> or a more sophisticated one:
>
> 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]
>

Barry wrote a script that strips out the error checking from the HTML.
Follow the link at the top to raw source:


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

and it has error checking.

   Matt


>
>

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


-- 
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/20161219/a71d40ab/attachment.html>