[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." <bsmith at mcs.anl.gov> writes:

>   No, that is CHKERRQ()
>
>
>> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin <dalcinl at gmail.com> 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. <bsmith at mcs.anl.gov> wrote:
>>> 
>>> 
>>>> On Jan 5, 2018, at 5:00 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>> 
>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>>> 
>>>>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>> 
>>>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>>>>> 
>>>>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>>>> 
>>>>>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>>>>>>> 
>>>>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith at mcs.anl.gov> 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 Sciences & Engineering (CEMSE)
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>> 
>> 4700 King Abdullah University of Science and Technology
>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>> http://www.kaust.edu.sa
>> 
>> Office Phone: +966 12 808-0459