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

[Jed Brown]

Yes, that's the idea.  Glenn, could you please stop dropping the
petsc-dev Cc?  I'd like to hear their input.

Nathan Collier <nathaniel.collier at gmail.com> 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 <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>
>> .
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140721/765d9e43/attachment.sig>