Either way works for me. Glenn
From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Collier Sent: Monday, July 21, 2014 1:55 PM To: [email protected] Cc: Jed Brown; Richard Mills Subject: Re: [EXTERNAL] Re: [pflotran-dev: 2208] Readability with CHKERRQ Ok, I can work on the offending lines and moving things to the end of statement versions. However, did you follow Jed's idea? (Step in here Jed if I missed something). The CHKERRQ(ierr) macro in fortran just calls MPIAbort if ierr is negative. He was saying that the PETSc fortran wrappers could be modified such that upon calling a PETSc function from fortran, a specific value of ierr can be passed as the final argument, say PetscErrAbort. This would signal PETSc to call Abort for you if the PETSc routine produces errors. If you hand it anything other than that, you get the output error code which you could check internally in your code. This way you can avoid ugly CHKERRQ(ierr) entirely if you want. The other PETSc folk would have to agree but if you like the idea I can push that way instead. Nate On Mon, Jul 21, 2014 at 4:19 PM, Hammond, Glenn E <[email protected]<mailto:[email protected]>> wrote: That’s doable. From: Nathan Collier [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, July 21, 2014 1:17 PM To: Hammond, Glenn E Cc: Jed Brown; [email protected]<mailto:[email protected]>; Richard Mills Subject: Re: [EXTERNAL] Re: [pflotran-dev: 2196] Readability with CHKERRQ 255 Nate On Mon, Jul 21, 2014 at 4:14 PM, Hammond, Glenn E <[email protected]<mailto:[email protected]>> wrote: How many of those lines are PETSc call? Glenn From: Nathan Collier [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, July 21, 2014 1:13 PM To: Hammond, Glenn E Cc: Jed Brown; [email protected]<mailto:[email protected]>; Richard Mills Subject: Re: [EXTERNAL] Re: [pflotran-dev: 2196] Readability with CHKERRQ Since the macro is 50 characters in length, we are safe to append if we stick to 80 character lines in PFLOTRAN (assuming the compiler will allow 132 characters). A quick parse of the source code reveals that 4957 lines are wider than 80 characters. So that would be an OK solution if we fix the source. I don't think automatic multi-lining of the source is a good idea though (might be hard to make things look correct). To me this sounds like a labor intensive option that we could divide up. However, if you are serious about the 80 character limit, then we could fix the source, and then apply a check on commits to make sure you do not violate that rule in the future. > Since this doesn't provide error tracing, why can't we use the ierr argument > to make the wrapper do this abort instead? > > call PetscFunctionWithSeveralArgs(a,b,c,d,PetscErrAbort) > > Here, PetscErrAbort would be a special value similar to PETSC_NULL_OBJECT. > If the wrapper sees it, the wrapper aborts instead of returning. Thoughts? Jed, I don't totally follow you here. Are you suggesting that the PETSc fortran wrapper itself could be made to call the Abort internally such that user codes do not need to do anything? If that is what you mean, then user code would have to check codes or configure with --with-errorchecking=0? Nate -- You received this message because you are subscribed to the Google Groups "pflotran-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/pflotran-dev/DF0B2AE3F6166745843F1066C7E2F38E90D9E2C7%40EXMB01.srn.sandia.gov<https://groups.google.com/d/msgid/pflotran-dev/DF0B2AE3F6166745843F1066C7E2F38E90D9E2C7%40EXMB01.srn.sandia.gov?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "pflotran-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/pflotran-dev/CAJdhdcNBKH8XLnraczYqCrzv%3DU%3D4WXs2jFW0NrELjAJsP1%3D-8Q%40mail.gmail.com<https://groups.google.com/d/msgid/pflotran-dev/CAJdhdcNBKH8XLnraczYqCrzv%3DU%3D4WXs2jFW0NrELjAJsP1%3D-8Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
