All, I will fix the multiline PETSc calls and change CHKERRQ to be end-of-line. This we will need anyway because we lag in the version of PETSc we support.
If/when we add what Jed proposes to PETSc, then I can remove the checks entirely. Nate On Mon, Jul 21, 2014 at 5:21 PM, Hammond, Glenn E <[email protected]> wrote: > 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]> > wrote: > > That’s doable. > > > > *From:* Nathan Collier [mailto:[email protected]] > *Sent:* Monday, July 21, 2014 1:17 PM > > > *To:* Hammond, Glenn E > *Cc:* Jed Brown; [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]> > wrote: > > How many of those lines are PETSc call? > > > > Glenn > > > > *From:* Nathan Collier [mailto:[email protected]] > *Sent:* Monday, July 21, 2014 1:13 PM > *To:* Hammond, Glenn E > *Cc:* Jed Brown; [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> > . > > -- > 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/DF0B2AE3F6166745843F1066C7E2F38E90D9E34B%40EXMB01.srn.sandia.gov > <https://groups.google.com/d/msgid/pflotran-dev/DF0B2AE3F6166745843F1066C7E2F38E90D9E34B%40EXMB01.srn.sandia.gov?utm_medium=email&utm_source=footer> > . >
