[petsc-dev] [EXTERNAL] Re: [pflotran-dev: 2211] Readability with CHKERRQ

[Nathan Collier]

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 <gehammo at sandia.gov>
wrote:

>  Either way works for me.
>
>
>
> Glenn
>
>
>
> *From:* pflotran-dev at googlegroups.com [mailto:
> pflotran-dev at googlegroups.com] *On Behalf Of *Nathan Collier
> *Sent:* Monday, July 21, 2014 1:55 PM
> *To:* pflotran-dev at googlegroups.com
> *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 <gehammo at sandia.gov>
> wrote:
>
> That’s doable.
>
>
>
> *From:* Nathan Collier [mailto:nathaniel.collier at gmail.com]
> *Sent:* Monday, July 21, 2014 1:17 PM
>
>
> *To:* Hammond, Glenn E
> *Cc:* Jed Brown; pflotran-dev at googlegroups.com; 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 <gehammo at sandia.gov>
> wrote:
>
> How many of those lines are PETSc call?
>
>
>
> Glenn
>
>
>
> *From:* Nathan Collier [mailto:nathaniel.collier at gmail.com]
> *Sent:* Monday, July 21, 2014 1:13 PM
> *To:* Hammond, Glenn E
> *Cc:* Jed Brown; pflotran-dev at googlegroups.com; 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>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140723/29b7befc/attachment.html>