[petsc-dev] PetscUse/TryMethod

[Barry Smith]

  I would say it is not reasonable for the package developers in the xsdk ecosystem to expect that they can just continue to use another HPC package for multiple years without doing some minimal amount of work to keep up with the other packages' new releases. If we had this attitude with the external packages PETSc uses we would have to stop using most of the packages/*.py. Yes, it is a constant race to keep up the versions in packages/*.py and requires some effort but if you want to play in this game that is a race you have to remain in. And it goes way beyond HPC, to say you do software development but don't need to manage constant change in everything is an oxymoron. There was never a golden age of computing where things didn't change rapidly, pretending there was or can be is not productive. Of course, we want to minimize public change, but having a goal of no public change is not a realistic or even desirable goal.

> Just noticed - CHKERRQ() got removed from fortran interface - breaking pflotran

This was just a oversight, easily fixed. 

> On Apr 3, 2022, at 11:13 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> 
> Note this  is not just 'users should update their code' issue.
> - all packages (that use petsc) would need to do this update
> - and this update doesn't always happen - so pakages will stay at old release - some might not
> - so now we cant build PETSc with both these packages together.
> 
> this type of change causes major issues in xsdk ecosystem (depends on how many direct/indirect dependencies are on the given package)
> 
> Just noticed - CHKERRQ() got removed from fortran interface - breaking pflotran
> 
> https://gitlab.com/xsdk-project/spack-xsdk/-/jobs/2285145624
> 
> [also CHKERRABORT]. Perhaps they can be added back in.
> 
> $ git diff release-3.16..release include/petsc/finclude/petscsys.h
> diff --git a/include/petsc/finclude/petscsys.h b/include/petsc/finclude/petscsys.h
> <snip>
> #define SETERRABORT(c,ierr,s)  call PetscError(c,ierr,0,s); call MPI_Abort(c,ierr)
> -#define CHKERRQ(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);return;endif
> +#define PetscCall(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);return;endif
> #define CHKERRA(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPIU_Abort(PETSC_COMM_SELF,ierr);endif
> -#define CHKERRABORT(c,ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPI_Abort(c,ierr);endif
> +#define PetscCallAbort(c,ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPI_Abort(c,ierr);endif
> #define CHKMEMQ call chkmemfortran(__LINE__,__FILE__,ierr)
> 
> Satish
> 
> On Sun, 3 Apr 2022, Barry Smith wrote:
> 
>> 
>>   To use the latest version of PETSc, each user needs to remove the error checks on these calls. The resulting code will work with previous versions of PETSc as well as the current version of PETSc.  PETSc has never promised complete backward compatibility in the sense of promising that one can use new PETSc releases without any changes to their code; the documentation has always stated new releases will contain changes in the API. We began using depreciate a few years ago to limit the number of changes that needed to be made immediately for each release but depreciate is not suitable for all changes and so users do need to make some changes for each new release. 
>> 
>> 
>> 
>> 
>> 
>>> On Apr 3, 2022, at 7:23 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>>> 
>>> The recent PetscUse/TryMethod changes are backward incompatible. Third-party codes cannot compile without modification. Our users deserve better.
>>> 
>>> 
>>> -- 
>>> Lisandro Dalcin
>>> ============
>>> Senior Research Scientist
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/ <http://ecrc.kaust.edu.sa/>
>> 
>> 
>