On Mon, Dec 19, 2016 at 4:30 PM, Andreas Mang <[email protected]> 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 <[email protected]> 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
