Yes, that's the idea. Glenn, could you please stop dropping the petsc-dev Cc? I'd like to hear their input.
Nathan Collier <[email protected]> writes: > 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> >> . >>
pgpm9CicUdaFL.pgp
Description: PGP signature
