January 2018 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] SETERRQ in fortran
by Smith, Barry F. 31 Jan '18

31 Jan '18

> On Jan 31, 2018, at 3:17 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > >>> On Jan 31, 2018, at 3:12 PM, Jed Brown <jed(a)jedbrown.org> 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

1 0

Re: [petsc-dev] SETERRQ in fortran
by Jed Brown 31 Jan '18

31 Jan '18

"Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> On Jan 31, 2018, at 3:12 PM, Jed Brown <jed(a)jedbrown.org> 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?

1 0

Re: [petsc-dev] SETERRQ in fortran
by Smith, Barry F. 31 Jan '18

31 Jan '18

> On Jan 31, 2018, at 3:12 PM, Jed Brown <jed(a)jedbrown.org> 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." <bsmith(a)mcs.anl.gov> writes: > >> No, that is CHKERRQ() >> >> >>> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin <dalcinl(a)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(a)mcs.anl.gov> wrote: >>>> >>>> >>>>> On Jan 5, 2018, at 5:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>> >>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>> >>>>>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>>> >>>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>>> >>>>>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>>>>> >>>>>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>>>>> >>>>>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith(a)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

1 0

Re: [petsc-dev] SETERRQ in fortran
by Jed Brown 31 Jan '18

31 Jan '18

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(a)mcs.anl.gov> writes: > No, that is CHKERRQ() > > >> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin <dalcinl(a)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(a)mcs.anl.gov> wrote: >>> >>> >>>> On Jan 5, 2018, at 5:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>> >>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>> >>>>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>> >>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>> >>>>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>>>> >>>>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>>>> >>>>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith(a)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

1 0

Re: [petsc-dev] SETERRQ in fortran
by Smith, Barry F. 31 Jan '18

31 Jan '18

No, that is CHKERRQ() > On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin <dalcinl(a)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(a)mcs.anl.gov> wrote: >> >> >>> On Jan 5, 2018, at 5:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> >>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>> >>>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>> >>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>> >>>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>>> >>>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>>> >>>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith(a)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

1 0

Re: [petsc-dev] Config failure
by Garth N. Wells 31 Jan '18

31 Jan '18

On 31 January 2018 at 20:37, Satish Balay <balay(a)mcs.anl.gov> wrote: > sorry - fixed now. > > Thanks. > [I thought I tested it before pushing - but apparently not! bad workflow] > > I know you've been discussing this recently, but we've found that lightweight branch testing (we've been using https://circleci.com/) has taken our success rate for full next testing from around 60% to over 90%. It would pick up errors like this one within a minute of pushing to a branch. Garth > Satish > > On Wed, 31 Jan 2018, Garth N. Wells wrote: > > > The green bits here: > > > > https://bitbucket.org/petsc/petsc/commits/b9693abc333a4cb54c29596de4de4a > 2160c61cc0 > > > > ain't proper Python. Breaks config. Not sure how this gets past your > > testing . . . . > > > > Garth > > > >

1 0

petsc/master: mkl_cpardiso.c broken
by Eric Chamberland 31 Jan '18

31 Jan '18

Hi, just to let know that since yesterday or before yesterday, I have errors in mkl_cpardiso.c on petsc/master: http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.01.31.02h00m01… other logs: http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.01.31.02h00m01… http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.01.31.02h00m01… http://www.giref.ulaval.ca/~cmpgiref/petsc-master-debug/2018.01.31.02h00m01… Thanks, Eric

1 0

Re: [petsc-dev] Config failure
by Satish Balay 31 Jan '18

31 Jan '18

sorry - fixed now. [I thought I tested it before pushing - but apparently not! bad workflow] Satish On Wed, 31 Jan 2018, Garth N. Wells wrote: > The green bits here: > > https://bitbucket.org/petsc/petsc/commits/b9693abc333a4cb54c29596de4de4a216… > > ain't proper Python. Breaks config. Not sure how this gets past your > testing . . . . > > Garth >

1 0

Config failure
by Garth N. Wells 31 Jan '18

31 Jan '18

The green bits here: https://bitbucket.org/petsc/petsc/commits/b9693abc333a4cb54c29596de4de4a216… ain't proper Python. Breaks config. Not sure how this gets past your testing . . . . Garth

1 0

Re: [petsc-dev] SETERRQ in fortran
by Lisandro Dalcin 31 Jan '18

31 Jan '18

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(a)mcs.anl.gov> wrote: > > >> On Jan 5, 2018, at 5:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> >>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>> >>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>> >>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>> >>>>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>>>> >>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bourdin(a)lsu.edu> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsmith(a)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

1 0