Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

https://bitbucket.org/petsc/petsc/pull-requests/852/change-fortran-seterra-and-seterrq-to-be/diff

"Smith, Barry F."  writes:

>> On Jan 31, 2018, at 3:17 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 31, 2018, at 3:12 PM, Jed Brown  wrote:
 
 I think his point is that Fortran has a one-line if statement (no then
 and no endif), which simplifies the macro and usage.
 
 if (cond) SETERRQ(...)
>>> 
>>>   That doesn't work because the SETERRQ() has both the call to the error 
>>> handler followed by a return which is two lines in Fortran.
>> 
>> Ah, right.  Would it make sense for PetscError to call MPI_Abort when
>> called in this context?
>
>   I don't think so. We want the traceback stack from Fortran as well as C, 
> hence we want to return and not just abort.
>
>Your proposed change (of pulling out the endif) is fine with me, I don't 
> think there are viable alternatives.
>
>   Barry

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 31, 2018, at 3:17 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 31, 2018, at 3:12 PM, Jed Brown  wrote:
>>> 
>>> I think his point is that Fortran has a one-line if statement (no then
>>> and no endif), which simplifies the macro and usage.
>>> 
>>> if (cond) SETERRQ(...)
>> 
>>   That doesn't work because the SETERRQ() has both the call to the error 
>> handler followed by a return which is two lines in Fortran.
> 
> Ah, right.  Would it make sense for PetscError to call MPI_Abort when
> called in this context?

  I don't think so. We want the traceback stack from Fortran as well as C, 
hence we want to return and not just abort.

   Your proposed change (of pulling out the endif) is fine with me, I don't 
think there are viable alternatives.

  Barry

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

"Smith, Barry F."  writes:

>> On Jan 31, 2018, at 3:12 PM, Jed Brown  wrote:
>> 
>> I think his point is that Fortran has a one-line if statement (no then
>> and no endif), which simplifies the macro and usage.
>> 
>>  if (cond) SETERRQ(...)
>
>That doesn't work because the SETERRQ() has both the call to the error 
> handler followed by a return which is two lines in Fortran.

Ah, right.  Would it make sense for PetscError to call MPI_Abort when
called in this context?

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 31, 2018, at 3:12 PM, Jed Brown  wrote:
> 
> I think his point is that Fortran has a one-line if statement (no then
> and no endif), which simplifies the macro and usage.
> 
>  if (cond) SETERRQ(...)

   That doesn't work because the SETERRQ() has both the call to the error 
handler followed by a return which is two lines in Fortran.

> 
> "Smith, Barry F."  writes:
> 
>>  No, that is CHKERRQ()
>> 
>> 
>>> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin  wrote:
>>> 
>>> Maybe I'm missing something, but maybe this define is all what you need?
>>> 
>>> #define SETERRQ(ierr) if (ierr/=0) call PetscError(comm,ierr,0,"message")
>>> 
>>> program main
>>> integer ierr,comm
>>> call something(ierr); SETERRQ(ierr)
>>> end program main
>>> 
>>> 
>>> 
>>> On 6 January 2018 at 02:33, Smith, Barry F.  wrote:
 
 
> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  
>>> wrote:
>>> 
>>> 
>>> 
 On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
 wrote:
 
 
 It's changed a bit.  It is better but you need to understand how 
 the new one works, so take a few minutes to see how it works 
 before converting.
>>> Got it.
>>> An example or a link to the fortran macro definition from the man 
>>> page would be nice
>>> I am confused about the rationale for putting the endif in the 
>>> macro, though.
>> 
>> It matches the C paradigm
> 
> Hardly.
 
 It matches the paradigm as close as can be reasonable done.
 
 I debated putting the then into the macros also.
 
> #define SETERRQ(c,ierr,s)  then ;call 
> PetscError(c,ierr,0,s);return;endif
 
 So usage would be
 
   if (bad) SETERRQ();
 
 would that be better.
>>> 
>>> No, Fortran isn't C.
>>> 
>>> if (bad) then
>>>   SETERRQ(...)
>>> endif
>>> 
>>> It doesn't get used so much from Fortran that we need to conceal the
>>> language constructs.
>> 
>> It will, eventually I want all Fortran examples/tests to have checks on 
>> every call (like with have in C).
> 
> CHKERRQ does the if internally, so it also has the endif.
 
 What is the relevance of this statement.
> 
> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
> SETERRQ is used a median of zero times and an average of less than 1 in
> the C examples.
 
  I am not sure why you are saying this. My resistance to change has 
 nothing to do with how often it is used.
 
  I am leaning to changing it but don't want to until all the test harness 
 branches etc get into master. So it will be a few days.
 
> 
>>> 
 
 
> This Fortran:
> 
> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
> 
> This would be like writing this C
> 
> #define SETERRQ(c,ierr,s) return PetscError(...); }
> 
> to be used like
> 
> if (BAD) { SETERRQ(comm, ierr, "why")
> 
> which is just bananas and still not as gross as the Fortran.  You 
> might
> not have noticed this because SETERRQ is not called from any of 
> PETSc's
> Fortran examples.
 
 But SETERRA() is and has the same pattern.
>>> 
>>> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
>>> The endif isn't going to kill anyone and pulling it out of the macro
>>> will make it easier to understand and avoid the circus antics when used
>>> in any context other than a positive conditional with no else clause.
>> 
>> I'll take this under advisement. Of course in our examples the endif 
>> will ALWAYS be on the same line as the rest. Using three lines for a 
>> SETERRQ() is ugly.
>> 
>> 
>>> 
> 
>>> Beside not having unmatched if / end if in my code, in a select 
>>> case construct, I have to write something as ugly as
>>> 
>>> select case (i)
>>>   case(1)
>>>   !do something
>>>   case(2)
>>>   !do something else
>>>   case default
>>>   if (0 == 

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

I think his point is that Fortran has a one-line if statement (no then
and no endif), which simplifies the macro and usage.

  if (cond) SETERRQ(...)

"Smith, Barry F."  writes:

>   No, that is CHKERRQ()
>
>
>> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin  wrote:
>> 
>> Maybe I'm missing something, but maybe this define is all what you need?
>> 
>> #define SETERRQ(ierr) if (ierr/=0) call PetscError(comm,ierr,0,"message")
>> 
>> program main
>>  integer ierr,comm
>>  call something(ierr); SETERRQ(ierr)
>> end program main
>> 
>> 
>> 
>> On 6 January 2018 at 02:33, Smith, Barry F.  wrote:
>>> 
>>> 
 On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
 
 "Smith, Barry F."  writes:
 
>> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
 
 "Smith, Barry F."  writes:
 
>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
>> 
>> 
>> 
>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
>>> wrote:
>>> 
>>> 
>>> It's changed a bit.  It is better but you need to understand how 
>>> the new one works, so take a few minutes to see how it works before 
>>> converting.
>> Got it.
>> An example or a link to the fortran macro definition from the man 
>> page would be nice
>> I am confused about the rationale for putting the endif in the 
>> macro, though.
> 
> It matches the C paradigm
 
 Hardly.
>>> 
>>> It matches the paradigm as close as can be reasonable done.
>>> 
>>> I debated putting the then into the macros also.
>>> 
 #define SETERRQ(c,ierr,s)  then ;call 
 PetscError(c,ierr,0,s);return;endif
>>> 
>>> So usage would be
>>> 
>>>if (bad) SETERRQ();
>>> 
>>> would that be better.
>> 
>> No, Fortran isn't C.
>> 
>> if (bad) then
>>SETERRQ(...)
>> endif
>> 
>> It doesn't get used so much from Fortran that we need to conceal the
>> language constructs.
> 
>  It will, eventually I want all Fortran examples/tests to have checks on 
> every call (like with have in C).
 
 CHKERRQ does the if internally, so it also has the endif.
>>> 
>>>  What is the relevance of this statement.
 
 SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
 SETERRQ is used a median of zero times and an average of less than 1 in
 the C examples.
>>> 
>>>   I am not sure why you are saying this. My resistance to change has 
>>> nothing to do with how often it is used.
>>> 
>>>   I am leaning to changing it but don't want to until all the test harness 
>>> branches etc get into master. So it will be a few days.
>>> 
 
>> 
>>> 
>>> 
 This Fortran:
 
 #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
 
 This would be like writing this C
 
 #define SETERRQ(c,ierr,s) return PetscError(...); }
 
 to be used like
 
 if (BAD) { SETERRQ(comm, ierr, "why")
 
 which is just bananas and still not as gross as the Fortran.  You might
 not have noticed this because SETERRQ is not called from any of PETSc's
 Fortran examples.
>>> 
>>>  But SETERRA() is and has the same pattern.
>> 
>> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
>> The endif isn't going to kill anyone and pulling it out of the macro
>> will make it easier to understand and avoid the circus antics when used
>> in any context other than a positive conditional with no else clause.
> 
>  I'll take this under advisement. Of course in our examples the endif 
> will ALWAYS be on the same line as the rest. Using three lines for a 
> SETERRQ() is ugly.
> 
> 
>> 
 
>> Beside not having unmatched if / end if in my code, in a select case 
>> construct, I have to write something as ugly as
>> 
>> select case (i)
>>case(1)
>>!do something
>>case(2)
>>!do something else
>>case default
>>if (0 == 0) then
>>
>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>> end select
>> 
> What is ugly about this ? except that you put the SETERRQ on a new 
> line which you did not need to do.
 
 Reread the above code.  Requiring the dummy opening if statement is 
 nuts.

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

  No, that is CHKERRQ()


> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin  wrote:
> 
> Maybe I'm missing something, but maybe this define is all what you need?
> 
> #define SETERRQ(ierr) if (ierr/=0) call PetscError(comm,ierr,0,"message")
> 
> program main
>  integer ierr,comm
>  call something(ierr); SETERRQ(ierr)
> end program main
> 
> 
> 
> On 6 January 2018 at 02:33, Smith, Barry F.  wrote:
>> 
>> 
>>> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
> 
> 
> 
>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
>> wrote:
>> 
>> 
>> It's changed a bit.  It is better but you need to understand how the 
>> new one works, so take a few minutes to see how it works before 
>> converting.
> Got it.
> An example or a link to the fortran macro definition from the man 
> page would be nice
> I am confused about the rationale for putting the endif in the macro, 
> though.
 
 It matches the C paradigm
>>> 
>>> Hardly.
>> 
>> It matches the paradigm as close as can be reasonable done.
>> 
>> I debated putting the then into the macros also.
>> 
>>> #define SETERRQ(c,ierr,s)  then ;call 
>>> PetscError(c,ierr,0,s);return;endif
>> 
>> So usage would be
>> 
>>if (bad) SETERRQ();
>> 
>> would that be better.
> 
> No, Fortran isn't C.
> 
> if (bad) then
>SETERRQ(...)
> endif
> 
> It doesn't get used so much from Fortran that we need to conceal the
> language constructs.
 
  It will, eventually I want all Fortran examples/tests to have checks on 
 every call (like with have in C).
>>> 
>>> CHKERRQ does the if internally, so it also has the endif.
>> 
>>  What is the relevance of this statement.
>>> 
>>> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
>>> SETERRQ is used a median of zero times and an average of less than 1 in
>>> the C examples.
>> 
>>   I am not sure why you are saying this. My resistance to change has nothing 
>> to do with how often it is used.
>> 
>>   I am leaning to changing it but don't want to until all the test harness 
>> branches etc get into master. So it will be a few days.
>> 
>>> 
> 
>> 
>> 
>>> This Fortran:
>>> 
>>> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>>> 
>>> This would be like writing this C
>>> 
>>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>>> 
>>> to be used like
>>> 
>>> if (BAD) { SETERRQ(comm, ierr, "why")
>>> 
>>> which is just bananas and still not as gross as the Fortran.  You might
>>> not have noticed this because SETERRQ is not called from any of PETSc's
>>> Fortran examples.
>> 
>>  But SETERRA() is and has the same pattern.
> 
> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
> The endif isn't going to kill anyone and pulling it out of the macro
> will make it easier to understand and avoid the circus antics when used
> in any context other than a positive conditional with no else clause.
 
  I'll take this under advisement. Of course in our examples the endif will 
 ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() 
 is ugly.
 
 
> 
>>> 
> Beside not having unmatched if / end if in my code, in a select case 
> construct, I have to write something as ugly as
> 
> select case (i)
>case(1)
>!do something
>case(2)
>!do something else
>case default
>if (0 == 0) then
>
> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
> end select
> 
 What is ugly about this ? except that you put the SETERRQ on a new 
 line which you did not need to do.
>>> 
>>> Reread the above code.  Requiring the dummy opening if statement is 
>>> nuts.
>> 
>> Agreed. He should not use SETERRQ() in this case, should call the error 
>> functions directly)
>> 
>>> 
 How do you want to write it so it is prettier?
>>> 
>>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>>> thus needs the closing too (so it's as intended).  Also 

Re: [petsc-dev] SETERRQ in fortran

[Lisandro Dalcin]

Maybe I'm missing something, but maybe this define is all what you need?

#define SETERRQ(ierr) if (ierr/=0) call PetscError(comm,ierr,0,"message")

program main
  integer ierr,comm
  call something(ierr); SETERRQ(ierr)
end program main



On 6 January 2018 at 02:33, Smith, Barry F.  wrote:
>
>
>> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
>>
>> "Smith, Barry F."  writes:
>>
 On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:

 "Smith, Barry F."  writes:

>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>>
>> "Smith, Barry F."  writes:
>>
 On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:



> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
> wrote:
>
>
> It's changed a bit.  It is better but you need to understand how the 
> new one works, so take a few minutes to see how it works before 
> converting.
 Got it.
 An example or a link to the fortran macro definition from the man page 
 would be nice
 I am confused about the rationale for putting the endif in the macro, 
 though.
>>>
>>> It matches the C paradigm
>>
>> Hardly.
>
>  It matches the paradigm as close as can be reasonable done.
>
>  I debated putting the then into the macros also.
>
>> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
>
>  So usage would be
>
> if (bad) SETERRQ();
>
> would that be better.

 No, Fortran isn't C.

 if (bad) then
 SETERRQ(...)
 endif

 It doesn't get used so much from Fortran that we need to conceal the
 language constructs.
>>>
>>>   It will, eventually I want all Fortran examples/tests to have checks on 
>>> every call (like with have in C).
>>
>> CHKERRQ does the if internally, so it also has the endif.
>
>   What is the relevance of this statement.
>>
>> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
>> SETERRQ is used a median of zero times and an average of less than 1 in
>> the C examples.
>
>I am not sure why you are saying this. My resistance to change has nothing 
> to do with how often it is used.
>
>I am leaning to changing it but don't want to until all the test harness 
> branches etc get into master. So it will be a few days.
>
>>

>
>
>> This Fortran:
>>
>> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>>
>> This would be like writing this C
>>
>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>>
>> to be used like
>>
>> if (BAD) { SETERRQ(comm, ierr, "why")
>>
>> which is just bananas and still not as gross as the Fortran.  You might
>> not have noticed this because SETERRQ is not called from any of PETSc's
>> Fortran examples.
>
>   But SETERRA() is and has the same pattern.

 It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
 The endif isn't going to kill anyone and pulling it out of the macro
 will make it easier to understand and avoid the circus antics when used
 in any context other than a positive conditional with no else clause.
>>>
>>>   I'll take this under advisement. Of course in our examples the endif will 
>>> ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() 
>>> is ugly.
>>>
>>>

>>
 Beside not having unmatched if / end if in my code, in a select case 
 construct, I have to write something as ugly as

 select case (i)
 case(1)
 !do something
 case(2)
 !do something else
 case default
 if (0 == 0) then
 
 SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
 end select

>>> What is ugly about this ? except that you put the SETERRQ on a new line 
>>> which you did not need to do.
>>
>> Reread the above code.  Requiring the dummy opening if statement is nuts.
>
>  Agreed. He should not use SETERRQ() in this case, should call the error 
> functions directly)
>
>>
>>> How do you want to write it so it is prettier?
>>
>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>> thus needs the closing too (so it's as intended).  Also note that your
>> first reply to Blaise was talking about CHKERRQ when he was asking about
>> SETERRQ.
>
>   Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
> me of anything.
>



-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical 

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

  Ok, thanks for figuring it out.



> On Jan 31, 2018, at 1:04 PM, Balay, Satish  wrote:
> 
> 
> The current code needs the following fix for --with-errorchecking=0.
> But since this code is likely to be changed - I won't push this..
> 
> Satish
> 
> ---
> 
> diff --git a/include/petsc/finclude/petscsys.h 
> b/include/petsc/finclude/petscsys.h
> index e5d5cb5f09..ce0170b0c4 100644
> --- a/include/petsc/finclude/petscsys.h
> +++ b/include/petsc/finclude/petscsys.h
> @@ -201,8 +201,8 @@
> #define CHKERRA(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call 
> MPIU_Abort(MPI_COMM_SELF,ierr);endif
> #define CHKMEMQ call chkmemfortran(__LINE__,__FILE__,ierr)
> #else
> -#define SETERRQ(c,ierr,s)
> -#define SETERRA(c,ierr,s)
> +#define SETERRQ(c,ierr,s) ;endif
> +#define SETERRA(c,ierr,s) ;endif
> #define CHKERRQ(ierr)
> #define CHKERRA(c,ierr)
> #define CHKMEMQ

Re: [petsc-dev] SETERRQ in fortran

[Satish Balay]

The current code needs the following fix for --with-errorchecking=0.
But since this code is likely to be changed - I won't push this..

Satish

---

diff --git a/include/petsc/finclude/petscsys.h 
b/include/petsc/finclude/petscsys.h
index e5d5cb5f09..ce0170b0c4 100644
--- a/include/petsc/finclude/petscsys.h
+++ b/include/petsc/finclude/petscsys.h
@@ -201,8 +201,8 @@
 #define CHKERRA(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call 
MPIU_Abort(MPI_COMM_SELF,ierr);endif
 #define CHKMEMQ call chkmemfortran(__LINE__,__FILE__,ierr)
 #else
-#define SETERRQ(c,ierr,s)
-#define SETERRA(c,ierr,s)
+#define SETERRQ(c,ierr,s) ;endif
+#define SETERRA(c,ierr,s) ;endif
 #define CHKERRQ(ierr)
 #define CHKERRA(c,ierr)
 #define CHKMEMQ

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 31, 2018, at 7:21 AM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
> 
> 
> 
>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
>> wrote:
>> 
>> 
>> It's changed a bit.  It is better but you need to understand how the 
>> new one works, so take a few minutes to see how it works before 
>> converting.
> Got it.
> An example or a link to the fortran macro definition from the man 
> page would be nice 
> I am confused about the rationale for putting the endif in the macro, 
> though.
 
 It matches the C paradigm
>>> 
>>> Hardly.
>> 
>> It matches the paradigm as close as can be reasonable done.
>> 
>> I debated putting the then into the macros also.
>> 
>>> #define SETERRQ(c,ierr,s)  then ;call 
>>> PetscError(c,ierr,0,s);return;endif
>> 
>> So usage would be 
>> 
>>if (bad) SETERRQ(); 
>> 
>> would that be better.
> 
> No, Fortran isn't C.
> 
> if (bad) then
>SETERRQ(...)
> endif
> 
> It doesn't get used so much from Fortran that we need to conceal the
> language constructs.
 
  It will, eventually I want all Fortran examples/tests to have checks on 
 every call (like with have in C).
>>> 
>>> CHKERRQ does the if internally, so it also has the endif.
>> 
>>  What is the relevance of this statement.
> 
> "checks on every call" are relevant to CHKERRQ, not SETERRQ.  CHKERRQ is
> self-contained because it includes the entire if-then-endif.
> 
>>> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
>>> SETERRQ is used a median of zero times and an average of less than 1 in
>>> the C examples.
>> 
>>   I am not sure why you are saying this. My resistance to change has nothing 
>> to do with how often it is used. 
> 
> I thought you were concerned with the clutter of
> 
>  if (cond) then SETERRQ(...); endif
> 
> instead of
> 
>  if (cond) then SETERRQ(...)
> 
>>   I am leaning to changing it but don't want to until all the test harness 
>> branches etc get into master. So it will be a few days.
> 
> Okay to make this change now?

   Feel free to make the change.

> 
>>> 
> 
>> 
>> 
>>> This Fortran:
>>> 
>>> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>>> 
>>> This would be like writing this C
>>> 
>>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>>> 
>>> to be used like
>>> 
>>> if (BAD) { SETERRQ(comm, ierr, "why")
>>> 
>>> which is just bananas and still not as gross as the Fortran.  You might
>>> not have noticed this because SETERRQ is not called from any of PETSc's
>>> Fortran examples.
>> 
>>  But SETERRA() is and has the same pattern.
> 
> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
> The endif isn't going to kill anyone and pulling it out of the macro
> will make it easier to understand and avoid the circus antics when used
> in any context other than a positive conditional with no else clause.
 
  I'll take this under advisement. Of course in our examples the endif will 
 ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() 
 is ugly.
 
 
> 
>>> 
> Beside not having unmatched if / end if in my code, in a select case 
> construct, I have to write something as ugly as
> 
> select case (i)
>   case(1) 
>   !do something
>   case(2)
>   !do something else
>   case default
>   if (0 == 0) then
>   
> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
> end select
> 
 What is ugly about this ? except that you put the SETERRQ on a new 
 line which you did not need to do.
>>> 
>>> Reread the above code.  Requiring the dummy opening if statement is 
>>> nuts.
>> 
>> Agreed. He should not use SETERRQ() in this case, should call the error 
>> functions directly)
>> 
>>> 
 How do you want to write it so it is prettier?
>>> 
>>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>>> thus needs the closing too 

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

"Smith, Barry F."  writes:

>> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
 
 "Smith, Barry F."  writes:
 
>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
 
 
 
> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  
> wrote:
> 
> 
> It's changed a bit.  It is better but you need to understand how the 
> new one works, so take a few minutes to see how it works before 
> converting.
 Got it.
 An example or a link to the fortran macro definition from the man page 
 would be nice 
 I am confused about the rationale for putting the endif in the macro, 
 though.
>>> 
>>> It matches the C paradigm
>> 
>> Hardly.
> 
>  It matches the paradigm as close as can be reasonable done.
> 
>  I debated putting the then into the macros also.
> 
>> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
> 
>  So usage would be 
> 
> if (bad) SETERRQ(); 
> 
> would that be better.
 
 No, Fortran isn't C.
 
 if (bad) then
 SETERRQ(...)
 endif
 
 It doesn't get used so much from Fortran that we need to conceal the
 language constructs.
>>> 
>>>   It will, eventually I want all Fortran examples/tests to have checks on 
>>> every call (like with have in C).
>> 
>> CHKERRQ does the if internally, so it also has the endif.
>
>   What is the relevance of this statement.

"checks on every call" are relevant to CHKERRQ, not SETERRQ.  CHKERRQ is
self-contained because it includes the entire if-then-endif.

>> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
>> SETERRQ is used a median of zero times and an average of less than 1 in
>> the C examples.
>
>I am not sure why you are saying this. My resistance to change has nothing 
> to do with how often it is used. 

I thought you were concerned with the clutter of

  if (cond) then SETERRQ(...); endif

instead of

  if (cond) then SETERRQ(...)

>I am leaning to changing it but don't want to until all the test harness 
> branches etc get into master. So it will be a few days.

Okay to make this change now?

>> 
 
> 
> 
>> This Fortran:
>> 
>> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>> 
>> This would be like writing this C
>> 
>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>> 
>> to be used like
>> 
>> if (BAD) { SETERRQ(comm, ierr, "why")
>> 
>> which is just bananas and still not as gross as the Fortran.  You might
>> not have noticed this because SETERRQ is not called from any of PETSc's
>> Fortran examples.
> 
>   But SETERRA() is and has the same pattern.
 
 It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
 The endif isn't going to kill anyone and pulling it out of the macro
 will make it easier to understand and avoid the circus antics when used
 in any context other than a positive conditional with no else clause.
>>> 
>>>   I'll take this under advisement. Of course in our examples the endif will 
>>> ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() 
>>> is ugly.
>>> 
>>> 
 
>> 
 Beside not having unmatched if / end if in my code, in a select case 
 construct, I have to write something as ugly as
 
 select case (i)
case(1) 
!do something
case(2)
!do something else
case default
if (0 == 0) then

 SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
 end select
 
>>> What is ugly about this ? except that you put the SETERRQ on a new line 
>>> which you did not need to do.
>> 
>> Reread the above code.  Requiring the dummy opening if statement is nuts.
> 
>  Agreed. He should not use SETERRQ() in this case, should call the error 
> functions directly)
> 
>> 
>>> How do you want to write it so it is prettier?
>> 
>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>> thus needs the closing too (so it's as intended).  Also note that your
>> first reply to Blaise was talking about CHKERRQ when he was asking about
>> SETERRQ.
> 
>   Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
> me of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 5, 2018, at 5:00 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
>>> 
>>> 
>>> 
 On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
 
 
 It's changed a bit.  It is better but you need to understand how the 
 new one works, so take a few minutes to see how it works before 
 converting.
>>> Got it.
>>> An example or a link to the fortran macro definition from the man page 
>>> would be nice 
>>> I am confused about the rationale for putting the endif in the macro, 
>>> though.
>> 
>> It matches the C paradigm
> 
> Hardly.
 
  It matches the paradigm as close as can be reasonable done.
 
  I debated putting the then into the macros also.
 
> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
 
  So usage would be 
 
 if (bad) SETERRQ(); 
 
 would that be better.
>>> 
>>> No, Fortran isn't C.
>>> 
>>> if (bad) then
>>> SETERRQ(...)
>>> endif
>>> 
>>> It doesn't get used so much from Fortran that we need to conceal the
>>> language constructs.
>> 
>>   It will, eventually I want all Fortran examples/tests to have checks on 
>> every call (like with have in C).
> 
> CHKERRQ does the if internally, so it also has the endif.

  What is the relevance of this statement.
> 
> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
> SETERRQ is used a median of zero times and an average of less than 1 in
> the C examples.

   I am not sure why you are saying this. My resistance to change has nothing 
to do with how often it is used. 

   I am leaning to changing it but don't want to until all the test harness 
branches etc get into master. So it will be a few days.

> 
>>> 
 
 
> This Fortran:
> 
> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
> 
> This would be like writing this C
> 
> #define SETERRQ(c,ierr,s) return PetscError(...); }
> 
> to be used like
> 
> if (BAD) { SETERRQ(comm, ierr, "why")
> 
> which is just bananas and still not as gross as the Fortran.  You might
> not have noticed this because SETERRQ is not called from any of PETSc's
> Fortran examples.
 
   But SETERRA() is and has the same pattern.
>>> 
>>> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
>>> The endif isn't going to kill anyone and pulling it out of the macro
>>> will make it easier to understand and avoid the circus antics when used
>>> in any context other than a positive conditional with no else clause.
>> 
>>   I'll take this under advisement. Of course in our examples the endif will 
>> ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() is 
>> ugly.
>> 
>> 
>>> 
> 
>>> Beside not having unmatched if / end if in my code, in a select case 
>>> construct, I have to write something as ugly as
>>> 
>>> select case (i)
>>> case(1) 
>>> !do something
>>> case(2)
>>> !do something else
>>> case default
>>> if (0 == 0) then
>>> 
>>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>>> end select
>>> 
>> What is ugly about this ? except that you put the SETERRQ on a new line 
>> which you did not need to do.
> 
> Reread the above code.  Requiring the dummy opening if statement is nuts.
 
  Agreed. He should not use SETERRQ() in this case, should call the error 
 functions directly)
 
> 
>> How do you want to write it so it is prettier?
> 
> SETERRQ should not include that endif.  CHKERRQ has the opening if and
> thus needs the closing too (so it's as intended).  Also note that your
> first reply to Blaise was talking about CHKERRQ when he was asking about
> SETERRQ.
 
   Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
 me of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

"Smith, Barry F."  writes:

>> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
 
 "Smith, Barry F."  writes:
 
>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
>> 
>> 
>> 
>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
>>> 
>>> 
>>> It's changed a bit.  It is better but you need to understand how the 
>>> new one works, so take a few minutes to see how it works before 
>>> converting.
>> Got it.
>> An example or a link to the fortran macro definition from the man page 
>> would be nice 
>> I am confused about the rationale for putting the endif in the macro, 
>> though.
> 
> It matches the C paradigm
 
 Hardly.
>>> 
>>>   It matches the paradigm as close as can be reasonable done.
>>> 
>>>   I debated putting the then into the macros also.
>>> 
 #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
>>> 
>>>   So usage would be 
>>> 
>>>  if (bad) SETERRQ(); 
>>> 
>>>  would that be better.
>> 
>> No, Fortran isn't C.
>> 
>>  if (bad) then
>>  SETERRQ(...)
>>  endif
>> 
>> It doesn't get used so much from Fortran that we need to conceal the
>> language constructs.
>
>It will, eventually I want all Fortran examples/tests to have checks on 
> every call (like with have in C).

CHKERRQ does the if internally, so it also has the endif.

SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
SETERRQ is used a median of zero times and an average of less than 1 in
the C examples.

>> 
>>> 
>>> 
 This Fortran:
 
 #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
 
 This would be like writing this C
 
 #define SETERRQ(c,ierr,s) return PetscError(...); }
 
 to be used like
 
 if (BAD) { SETERRQ(comm, ierr, "why")
 
 which is just bananas and still not as gross as the Fortran.  You might
 not have noticed this because SETERRQ is not called from any of PETSc's
 Fortran examples.
>>> 
>>>But SETERRA() is and has the same pattern.
>> 
>> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
>> The endif isn't going to kill anyone and pulling it out of the macro
>> will make it easier to understand and avoid the circus antics when used
>> in any context other than a positive conditional with no else clause.
>
>I'll take this under advisement. Of course in our examples the endif will 
> ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() is 
> ugly.
>
>
>> 
 
>> Beside not having unmatched if / end if in my code, in a select case 
>> construct, I have to write something as ugly as
>> 
>> select case (i)
>>  case(1) 
>>  !do something
>>  case(2)
>>  !do something else
>>  case default
>>  if (0 == 0) then
>>  
>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>> end select
>> 
> What is ugly about this ? except that you put the SETERRQ on a new line 
> which you did not need to do.
 
 Reread the above code.  Requiring the dummy opening if statement is nuts.
>>> 
>>>   Agreed. He should not use SETERRQ() in this case, should call the error 
>>> functions directly)
>>> 
 
> How do you want to write it so it is prettier?
 
 SETERRQ should not include that endif.  CHKERRQ has the opening if and
 thus needs the closing too (so it's as intended).  Also note that your
 first reply to Blaise was talking about CHKERRQ when he was asking about
 SETERRQ.
>>> 
>>>Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
>>> me of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 5, 2018, at 4:18 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>>> 
>>> "Smith, Barry F."  writes:
>>> 
> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
> 
> 
> 
>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
>> 
>> 
>> It's changed a bit.  It is better but you need to understand how the new 
>> one works, so take a few minutes to see how it works before converting.
> Got it.
> An example or a link to the fortran macro definition from the man page 
> would be nice 
> I am confused about the rationale for putting the endif in the macro, 
> though.
 
 It matches the C paradigm
>>> 
>>> Hardly.
>> 
>>   It matches the paradigm as close as can be reasonable done.
>> 
>>   I debated putting the then into the macros also.
>> 
>>> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
>> 
>>   So usage would be 
>> 
>>  if (bad) SETERRQ(); 
>> 
>>  would that be better.
> 
> No, Fortran isn't C.
> 
>  if (bad) then
>  SETERRQ(...)
>  endif
> 
> It doesn't get used so much from Fortran that we need to conceal the
> language constructs.

   It will, eventually I want all Fortran examples/tests to have checks on 
every call (like with have in C).
> 
>> 
>> 
>>> This Fortran:
>>> 
>>> #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>>> 
>>> This would be like writing this C
>>> 
>>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>>> 
>>> to be used like
>>> 
>>> if (BAD) { SETERRQ(comm, ierr, "why")
>>> 
>>> which is just bananas and still not as gross as the Fortran.  You might
>>> not have noticed this because SETERRQ is not called from any of PETSc's
>>> Fortran examples.
>> 
>>But SETERRA() is and has the same pattern.
> 
> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
> The endif isn't going to kill anyone and pulling it out of the macro
> will make it easier to understand and avoid the circus antics when used
> in any context other than a positive conditional with no else clause.

   I'll take this under advisement. Of course in our examples the endif will 
ALWAYS be on the same line as the rest. Using three lines for a SETERRQ() is 
ugly.


> 
>>> 
> Beside not having unmatched if / end if in my code, in a select case 
> construct, I have to write something as ugly as
> 
> select case (i)
>   case(1) 
>   !do something
>   case(2)
>   !do something else
>   case default
>   if (0 == 0) then
>   
> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
> end select
> 
 What is ugly about this ? except that you put the SETERRQ on a new line 
 which you did not need to do.
>>> 
>>> Reread the above code.  Requiring the dummy opening if statement is nuts.
>> 
>>   Agreed. He should not use SETERRQ() in this case, should call the error 
>> functions directly)
>> 
>>> 
 How do you want to write it so it is prettier?
>>> 
>>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>>> thus needs the closing too (so it's as intended).  Also note that your
>>> first reply to Blaise was talking about CHKERRQ when he was asking about
>>> SETERRQ.
>> 
>>Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
>> me of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

"Smith, Barry F."  writes:

>> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
>> 
>> "Smith, Barry F."  writes:
>> 
 On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
 
 
 
> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
> 
> 
> It's changed a bit.  It is better but you need to understand how the new 
> one works, so take a few minutes to see how it works before converting.
 Got it.
 An example or a link to the fortran macro definition from the man page 
 would be nice 
 I am confused about the rationale for putting the endif in the macro, 
 though.
>>> 
>>>  It matches the C paradigm
>> 
>> Hardly.
>
>It matches the paradigm as close as can be reasonable done.
>
>I debated putting the then into the macros also.
>
>> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif
>
>So usage would be 
>
>   if (bad) SETERRQ(); 
>
>   would that be better.

No, Fortran isn't C.

  if (bad) then
  SETERRQ(...)
  endif

It doesn't get used so much from Fortran that we need to conceal the
language constructs.

>
>
>>  This Fortran:
>> 
>>  #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
>> 
>> This would be like writing this C
>> 
>>  #define SETERRQ(c,ierr,s) return PetscError(...); }
>> 
>> to be used like
>> 
>>  if (BAD) { SETERRQ(comm, ierr, "why")
>> 
>> which is just bananas and still not as gross as the Fortran.  You might
>> not have noticed this because SETERRQ is not called from any of PETSc's
>> Fortran examples.
>
> But SETERRA() is and has the same pattern.

It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
The endif isn't going to kill anyone and pulling it out of the macro
will make it easier to understand and avoid the circus antics when used
in any context other than a positive conditional with no else clause.

>> 
 Beside not having unmatched if / end if in my code, in a select case 
 construct, I have to write something as ugly as
 
 select case (i)
case(1) 
!do something
case(2)
!do something else
case default
if (0 == 0) then

 SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
 end select
 
>>>  What is ugly about this ? except that you put the SETERRQ on a new line 
>>> which you did not need to do.
>> 
>> Reread the above code.  Requiring the dummy opening if statement is nuts.
>
>Agreed. He should not use SETERRQ() in this case, should call the error 
> functions directly)
>
>> 
>>>  How do you want to write it so it is prettier?
>> 
>> SETERRQ should not include that endif.  CHKERRQ has the opening if and
>> thus needs the closing too (so it's as intended).  Also note that your
>> first reply to Blaise was talking about CHKERRQ when he was asking about
>> SETERRQ.
>
> Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced 
> me of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 5, 2018, at 12:45 PM, Jed Brown  wrote:
> 
> "Smith, Barry F."  writes:
> 
>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
>>> 
>>> 
>>> 
 On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
 
 
 It's changed a bit.  It is better but you need to understand how the new 
 one works, so take a few minutes to see how it works before converting.
>>> Got it.
>>> An example or a link to the fortran macro definition from the man page 
>>> would be nice 
>>> I am confused about the rationale for putting the endif in the macro, 
>>> though.
>> 
>>  It matches the C paradigm
> 
> Hardly.

   It matches the paradigm as close as can be reasonable done.

   I debated putting the then into the macros also.

> #define SETERRQ(c,ierr,s)  then ;call PetscError(c,ierr,0,s);return;endif

   So usage would be 

  if (bad) SETERRQ(); 

  would that be better.



>  This Fortran:
> 
>  #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif
> 
> This would be like writing this C
> 
>  #define SETERRQ(c,ierr,s) return PetscError(...); }
> 
> to be used like
> 
>  if (BAD) { SETERRQ(comm, ierr, "why")
> 
> which is just bananas and still not as gross as the Fortran.  You might
> not have noticed this because SETERRQ is not called from any of PETSc's
> Fortran examples.

But SETERRA() is and has the same pattern.

> 
>>> Beside not having unmatched if / end if in my code, in a select case 
>>> construct, I have to write something as ugly as
>>> 
>>> select case (i)
>>> case(1) 
>>> !do something
>>> case(2)
>>> !do something else
>>> case default
>>> if (0 == 0) then
>>> 
>>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>>> end select
>>> 
>>  What is ugly about this ? except that you put the SETERRQ on a new line 
>> which you did not need to do.
> 
> Reread the above code.  Requiring the dummy opening if statement is nuts.

   Agreed. He should not use SETERRQ() in this case, should call the error 
functions directly)

> 
>>  How do you want to write it so it is prettier?
> 
> SETERRQ should not include that endif.  CHKERRQ has the opening if and
> thus needs the closing too (so it's as intended).  Also note that your
> first reply to Blaise was talking about CHKERRQ when he was asking about
> SETERRQ.

Hmm, I'm not sure about. Oh well, it doesn't matter. You have convinced me 
of anything. 

Re: [petsc-dev] SETERRQ in fortran

[Jed Brown]

"Smith, Barry F."  writes:

>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
>> 
>> 
>> 
>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
>>> 
>>> 
>>> It's changed a bit.  It is better but you need to understand how the new 
>>> one works, so take a few minutes to see how it works before converting.
>> Got it.
>> An example or a link to the fortran macro definition from the man page would 
>> be nice 
>> I am confused about the rationale for putting the endif in the macro, though.
>
>   It matches the C paradigm

Hardly.  This Fortran:

  #define SETERRQ(c,ierr,s)  ;call PetscError(c,ierr,0,s);return;endif

This would be like writing this C

  #define SETERRQ(c,ierr,s) return PetscError(...); }

to be used like

  if (BAD) { SETERRQ(comm, ierr, "why")

which is just bananas and still not as gross as the Fortran.  You might
not have noticed this because SETERRQ is not called from any of PETSc's
Fortran examples.

>> Beside not having unmatched if / end if in my code, in a select case 
>> construct, I have to write something as ugly as
>> 
>> select case (i)
>>  case(1) 
>>  !do something
>>  case(2)
>>  !do something else
>>  case default
>>  if (0 == 0) then
>>  
>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>> end select
>> 
>   What is ugly about this ? except that you put the SETERRQ on a new line 
> which you did not need to do.

Reread the above code.  Requiring the dummy opening if statement is nuts.

>   How do you want to write it so it is prettier?

SETERRQ should not include that endif.  CHKERRQ has the opening if and
thus needs the closing too (so it's as intended).  Also note that your
first reply to Blaise was talking about CHKERRQ when he was asking about
SETERRQ.

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin  wrote:
> 
> 
> 
>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
>> 
>> 
>> It's changed a bit.  It is better but you need to understand how the new one 
>> works, so take a few minutes to see how it works before converting.
> Got it.
> An example or a link to the fortran macro definition from the man page would 
> be nice 
> I am confused about the rationale for putting the endif in the macro, though.

  It matches the C paradigm

> Beside not having unmatched if / end if in my code, in a select case 
> construct, I have to write something as ugly as
> 
> select case (i)
>   case(1) 
>   !do something
>   case(2)
>   !do something else
>   case default
>   if (0 == 0) then
>   
> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
> end select
> 
  What is ugly about this ? except that you put the SETERRQ on a new line which 
you did not need to do.

  How do you want to write it so it is prettier?


  Barry

> Am I missing something again?
> 
> Blaise
> 
> 
>> 
>> Use CHKERRA() for main Fortran problem and CHKERRQ() for subroutines.
>> 
>> Also look at their definitions to see how the if () business is handled. 
>> 
>> Barry
>> 
>> 
>>> On Jan 4, 2018, at 2:02 PM, Matthew Knepley  wrote:
>>> 
>>> On Thu, Jan 4, 2018 at 2:42 PM, Blaise A Bourdin  wrote:
>>> Hi,
>>> 
>>> Is SETERRQ still available in fortran? I notice that it is not used in any 
>>> of the example, but the man page still mentions fortran. Using it in a 
>>> fortran code leads to compiler errors.
>>> Am I doing something wrong?
>>> 
>>> I see it here:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpetsc%2Fsrc%2Fc925fbded0167f274f0216824a05edb59a5721f5%2Finclude%2Fpetsc%2Ffinclude%2Fpetscsys.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23petscsys.h-197=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=R6xnRLTzelnxPz39tkA0warCI%2BUFt%2FAnM8haZbjANQA%3D=0
>>> 
>>> I think its complaining about the 'return;endif'
>>> 
>>> Matt
>>> 
>>> MacBookGray:F90 $ cat TestSETERRQ.F90
>>> Program TestSETERRQ
>>> #include 
>>>  Use petsc
>>> 
>>>  Implicit NONE
>>>  PetscInt   :: ierr
>>>  Character(len=256) :: IOBuffer
>>> 
>>>  Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
>>>  write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
>>>  SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>>  call foo()
>>>  Call PetscFinalize(ierr)
>>> Contains
>>>   subroutine foo()
>>>  Character(len=256) :: IOBuffer
>>> 
>>>  write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
>>>  SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>>   end subroutine foo
>>> End Program TestSETERRQ
>>> 
>>> MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
>>> mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
>>> -I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include 
>>> -I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
>>> TestSETERRQ.F90:11:61:
>>> 
>>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>>1
>>> Error: Expecting END PROGRAM statement at (1)
>>> TestSETERRQ.F90:19:65:
>>> 
>>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>>1
>>> Error: Expecting END SUBROUTINE statement at (1)
>>> make: [TestSETERRQ.o] Error 1 (ignored)
>>> 
>>> 
>>> Blaise
>>> 
>>> --
>>> Department of Mathematics and Center for Computation & Technology
>>> Louisiana State University, Baton Rouge, LA 70803, USA
>>> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
>>> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.math.lsu.edu%2F~bourdin=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=DM5ZtUYkEBxwU%2FVS7eHC8dF%2Fw2w9aSbP9l8YvL3Nj6o%3D=0
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> What most experimenters take for granted before they begin their 
>>> experiments is infinitely more interesting than any results to which their 
>>> experiments lead.
>>> -- Norbert Wiener
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cse.buffalo.edu%2F~knepley%2F=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=99K5TljrSNkF7MGImBkWQTjXCUt%2BdwB8XAHB%2FQztQZY%3D=0
>> 
> 
> -- 
> Department of Mathematics and Center for Computation & Technology
> Louisiana State University, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
> http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] SETERRQ in fortran

[Blaise A Bourdin]

> On Jan 4, 2018, at 3:16 PM, Smith, Barry F.  wrote:
> 
> 
>  It's changed a bit.  It is better but you need to understand how the new one 
> works, so take a few minutes to see how it works before converting.
Got it.
An example or a link to the fortran macro definition from the man page would be 
nice 
I am confused about the rationale for putting the endif in the macro, though.
Beside not having unmatched if / end if in my code, in a select case construct, 
I have to write something as ugly as

select case (i)
case(1) 
!do something
case(2)
!do something else
case default
if (0 == 0) then

SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
end select

Am I missing something again?

Blaise


> 
>  Use CHKERRA() for main Fortran problem and CHKERRQ() for subroutines.
> 
>  Also look at their definitions to see how the if () business is handled. 
> 
>  Barry
> 
> 
>> On Jan 4, 2018, at 2:02 PM, Matthew Knepley  wrote:
>> 
>> On Thu, Jan 4, 2018 at 2:42 PM, Blaise A Bourdin  wrote:
>> Hi,
>> 
>> Is SETERRQ still available in fortran? I notice that it is not used in any 
>> of the example, but the man page still mentions fortran. Using it in a 
>> fortran code leads to compiler errors.
>> Am I doing something wrong?
>> 
>> I see it here:
>> 
>>  
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpetsc%2Fsrc%2Fc925fbded0167f274f0216824a05edb59a5721f5%2Finclude%2Fpetsc%2Ffinclude%2Fpetscsys.h%3Fat%3Dmaster%26fileviewer%3Dfile-view-default%23petscsys.h-197=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=R6xnRLTzelnxPz39tkA0warCI%2BUFt%2FAnM8haZbjANQA%3D=0
>> 
>> I think its complaining about the 'return;endif'
>> 
>>  Matt
>> 
>> MacBookGray:F90 $ cat TestSETERRQ.F90
>> Program TestSETERRQ
>> #include 
>>   Use petsc
>> 
>>   Implicit NONE
>>   PetscInt   :: ierr
>>   Character(len=256) :: IOBuffer
>> 
>>   Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
>>   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>   call foo()
>>   Call PetscFinalize(ierr)
>> Contains
>>subroutine foo()
>>   Character(len=256) :: IOBuffer
>> 
>>   write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
>>   SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>>end subroutine foo
>> End Program TestSETERRQ
>> 
>> MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
>> mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
>> -I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include 
>> -I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
>> TestSETERRQ.F90:11:61:
>> 
>>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>> 1
>> Error: Expecting END PROGRAM statement at (1)
>> TestSETERRQ.F90:19:65:
>> 
>>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>> 1
>> Error: Expecting END SUBROUTINE statement at (1)
>> make: [TestSETERRQ.o] Error 1 (ignored)
>> 
>> 
>> Blaise
>> 
>> --
>> Department of Mathematics and Center for Computation & Technology
>> Louisiana State University, Baton Rouge, LA 70803, USA
>> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
>> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.math.lsu.edu%2F~bourdin=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=DM5ZtUYkEBxwU%2FVS7eHC8dF%2Fw2w9aSbP9l8YvL3Nj6o%3D=0
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> What most experimenters take for granted before they begin their experiments 
>> is infinitely more interesting than any results to which their experiments 
>> lead.
>> -- Norbert Wiener
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cse.buffalo.edu%2F~knepley%2F=02%7C01%7Cbourdin%40lsu.edu%7C9e126b88c4de4bb5b1c108d553b87d8a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C636506974199979974=99K5TljrSNkF7MGImBkWQTjXCUt%2BdwB8XAHB%2FQztQZY%3D=0
> 

-- 
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

Re: [petsc-dev] SETERRQ in fortran

[Smith, Barry F.]

  It's changed a bit.  It is better but you need to understand how the new one 
works, so take a few minutes to see how it works before converting.

  Use CHKERRA() for main Fortran problem and CHKERRQ() for subroutines.

  Also look at their definitions to see how the if () business is handled. 

  Barry


> On Jan 4, 2018, at 2:02 PM, Matthew Knepley  wrote:
> 
> On Thu, Jan 4, 2018 at 2:42 PM, Blaise A Bourdin  wrote:
> Hi,
> 
> Is SETERRQ still available in fortran? I notice that it is not used in any of 
> the example, but the man page still mentions fortran. Using it in a fortran 
> code leads to compiler errors.
> Am I doing something wrong?
> 
> I see it here:
> 
>   
> https://bitbucket.org/petsc/petsc/src/c925fbded0167f274f0216824a05edb59a5721f5/include/petsc/finclude/petscsys.h?at=master=file-view-default#petscsys.h-197
> 
> I think its complaining about the 'return;endif'
> 
>   Matt
> 
> MacBookGray:F90 $ cat TestSETERRQ.F90
> Program TestSETERRQ
> #include 
>Use petsc
> 
>Implicit NONE
>PetscInt   :: ierr
>Character(len=256) :: IOBuffer
> 
>Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
>write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>call foo()
>Call PetscFinalize(ierr)
> Contains
> subroutine foo()
>Character(len=256) :: IOBuffer
> 
>write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
> end subroutine foo
> End Program TestSETERRQ
> 
> MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
> mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
> -I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include 
> -I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
> TestSETERRQ.F90:11:61:
> 
> SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>  1
> Error: Expecting END PROGRAM statement at (1)
> TestSETERRQ.F90:19:65:
> 
> SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>  1
> Error: Expecting END SUBROUTINE statement at (1)
> make: [TestSETERRQ.o] Error 1 (ignored)
> 
> 
> Blaise
> 
> --
> Department of Mathematics and Center for Computation & Technology
> Louisiana State University, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
> http://www.math.lsu.edu/~bourdin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/

Re: [petsc-dev] SETERRQ in fortran

[Matthew Knepley]

On Thu, Jan 4, 2018 at 2:42 PM, Blaise A Bourdin  wrote:

> Hi,
>
> Is SETERRQ still available in fortran? I notice that it is not used in any
> of the example, but the man page still mentions fortran. Using it in a
> fortran code leads to compiler errors.
> Am I doing something wrong?
>

I see it here:


https://bitbucket.org/petsc/petsc/src/c925fbded0167f274f0216824a05edb59a5721f5/include/petsc/finclude/petscsys.h?at=master=file-view-default#petscsys.h-197

I think its complaining about the 'return;endif'

  Matt

MacBookGray:F90 $ cat TestSETERRQ.F90
> Program TestSETERRQ
> #include 
>Use petsc
>
>Implicit NONE
>PetscInt   :: ierr
>Character(len=256) :: IOBuffer
>
>Call PetscInitialize(PETSC_NULL_CHARACTER, ierr);CHKERRA(ierr)
>write(IOBuffer,'("This is a test ierr = ",I2,"\n")') ierr
>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>call foo()
>Call PetscFinalize(ierr)
> Contains
> subroutine foo()
>Character(len=256) :: IOBuffer
>
>write(IOBuffer,'("This is a test ierr = ",I2,"\n")') 42
>SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
> end subroutine foo
> End Program TestSETERRQ
>
> MacBookGray:F90 $ make -f makefile.TestSETERRQ TestSETERRQ
> mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
> -I/opt/HPC/petsc-next/include -I/opt/HPC/petsc-next/Darwin-gcc7.2-g/include
> -I/opt/X11/include-o TestSETERRQ.o TestSETERRQ.F90
> TestSETERRQ.F90:11:61:
>
> SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>  1
> Error: Expecting END PROGRAM statement at (1)
> TestSETERRQ.F90:19:65:
>
> SETERRQ(PETSC_COMM_SELF,PETSC_ERR_FILE_UNEXPECTED,IOBuffer)
>  1
> Error: Expecting END SUBROUTINE statement at (1)
> make: [TestSETERRQ.o] Error 1 (ignored)
>
>
> Blaise
>
> --
> Department of Mathematics and Center for Computation & Technology
> Louisiana State University, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~
> bourdin
>
>
>
>
>
>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/