<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> I think it is a great idea to test on publically available supported packages that have public git repositories and a decent testing infrastructure regularly and even feed any information that comes up to the packages team in advance. I can think of PFLOTRAN, FireDrake, and MOOSE as good starting candidates. I think we should help those teams add a switch to their test system to use PETSc main when appropriate, I don't think we should be adding such stuff inside the PETSc test world. Note that Slepc and HPDDM are already in the fold and this already takes place with them.<div class=""><br class=""></div><div class=""> Packages that heavily use PETSc but do not track PETSc main from their main branch will have a bump at each release but note that tracking main need not mean updating their package to petsc main every day; in fact as Jed notes it could mean starting to track PETSc main in their main about August 30th and March 1st. This time because of unlucky timing we made major changes in main just before a release which perhaps caused more short-term frustration for some people.<div class=""><br class=""></div><div class=""> We know from Fande that MOOSE does not immediately update to the latest PETSc on release but this I don't think is related to small changes in the PETSc API but is instead due to the need to do extensive validated testing whenever they change anything they are using. So slow uptake is not just due to modest API changes in fact modest API changes may not be the largest cause of slow uptake in general (though they do trigger grumbling). Note, for example, the huge amount of issues with tracking hypre that are not directly from hypre API changes.</div><div class=""><br class=""></div><div class=""> As I pointed out in my previous email to Satish, SUNDIALS is not a good example of not keeping up with modest API changes. <br class=""><div class=""><br class=""></div><div class=""> <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 3, 2022, at 1:02 PM, Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Sundials, for example.<br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">PETSc is still relatively low in the software stack. If everyone is making biannual releases for ECP, then we'd need a topological sort on dependencies and PETSc would need to release (or at least freeze) early, e.g., January or February, so other packages have time to update by their March deadlines.<br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">I understand there may have been an assessment that PetscTryMethod sees vanishing use by dependencies. I think if we're doing that, it should probably be earlier in the release cycle with more effort to assess and notify such dependencies. Maybe we could keep a list of high profile packages, a script to grep them all, and a weekly(?) CI job that builds them.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">On Sun, Apr 3, 2022, at 10:45 AM, Barry Smith wrote:<br class=""></div><blockquote type="cite" id="qt" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">> On Apr 3, 2022, at 12:24 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" class="">balay@mcs.anl.gov</a>> wrote:<br class=""></div><div class="">> <br class=""></div><div class="">>> If we had this attitude with the external packages PETSc uses we would have to stop using most of the packages/*.py. <br class=""></div><div class="">> <br class=""></div><div class="">> Sure one can take extreme view on both sides. [no change, vs won't hesitate to change] - having a manageable (minimal) change is harder to do.<br class=""></div><div class="">> <br class=""></div><div class="">> I would point out that most externalpackages don't change much and we benefit from it - hence we are able to support so may. Some packages had major changes - and we haven't upgraded to their new versions.<br class=""></div><div class=""><br class=""></div><div class=""> What packages are these? We should have a tool that runs through all the packages/xxx.py and determines the date of release of the version we are using and if there are any newer versions available. We could run this tool automatically a month before each PETSc release sending its output to petsc-dev to see what we should be updating. <br class=""></div><div class=""><br class=""></div><div class=""> Note also that some packages we don't update to, not because of API changes but because the new releases are broken in some way, this is life in the HPC world.<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">> <br class=""></div><div class="">> [i.e with the current state one can use them only if they completely buy into petsc ecosystem i.e use old version - but not any larger one - as in use newer features from them]<br class=""></div><div class="">> <br class=""></div><div class="">> We did update to newer interfaces in some packages.<br class=""></div><div class="">> <br class=""></div><div class="">> But these problems remain - and have to be dealt with - and sometimes the complexity increases based on the dependency tree.<br class=""></div><div class="">> <br class=""></div><div class="">> [and also results in folk using and requiring help with older petsc versions]<br class=""></div><div class="">> <br class=""></div><div class="">> Satish<br class=""></div><div class="">> <br class=""></div><div class="">> <br class=""></div><div class="">> On Sun, 3 Apr 2022, Barry Smith wrote:<br class=""></div><div class="">> <br class=""></div><div class="">>> <br class=""></div><div class="">>> 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.<br class=""></div><div class="">>> <br class=""></div><div class="">>>> Just noticed - CHKERRQ() got removed from fortran interface - breaking pflotran<br class=""></div><div class="">>> <br class=""></div><div class="">>> This was just a oversight, easily fixed. <br class=""></div><div class="">>> <br class=""></div><div class="">>>> On Apr 3, 2022, at 11:13 AM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" class="">balay@mcs.anl.gov</a>> wrote:<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> <br class=""></div><div class="">>>> Note this is not just 'users should update their code' issue.<br class=""></div><div class="">>>> - all packages (that use petsc) would need to do this update<br class=""></div><div class="">>>> - and this update doesn't always happen - so pakages will stay at old release - some might not<br class=""></div><div class="">>>> - so now we cant build PETSc with both these packages together.<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> this type of change causes major issues in xsdk ecosystem (depends on how many direct/indirect dependencies are on the given package)<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> Just noticed - CHKERRQ() got removed from fortran interface - breaking pflotran<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> <a href="https://gitlab.com/xsdk-project/spack-xsdk/-/jobs/2285145624" class="">https://gitlab.com/xsdk-project/spack-xsdk/-/jobs/2285145624</a><br class=""></div><div class="">>>> <br class=""></div><div class="">>>> [also CHKERRABORT]. Perhaps they can be added back in.<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> $ git diff release-3.16..release include/petsc/finclude/petscsys.h<br class=""></div><div class="">>>> diff --git a/include/petsc/finclude/petscsys.h b/include/petsc/finclude/petscsys.h<br class=""></div><div class="">>>> <snip><br class=""></div><div class="">>>> #define SETERRABORT(c,ierr,s) call PetscError(c,ierr,0,s); call MPI_Abort(c,ierr)<br class=""></div><div class="">>>> -#define CHKERRQ(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);return;endif<br class=""></div><div class="">>>> +#define PetscCall(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);return;endif<br class=""></div><div class="">>>> #define CHKERRA(ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPIU_Abort(PETSC_COMM_SELF,ierr);endif<br class=""></div><div class="">>>> -#define CHKERRABORT(c,ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPI_Abort(c,ierr);endif<br class=""></div><div class="">>>> +#define PetscCallAbort(c,ierr) if (ierr .ne. 0) then;call PetscErrorF(ierr);call MPI_Abort(c,ierr);endif<br class=""></div><div class="">>>> #define CHKMEMQ call chkmemfortran(__LINE__,__FILE__,ierr)<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> Satish<br class=""></div><div class="">>>> <br class=""></div><div class="">>>> On Sun, 3 Apr 2022, Barry Smith wrote:<br class=""></div><div class="">>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> 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. <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>>> On Apr 3, 2022, at 7:23 AM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com" class="">dalcinl@gmail.com</a>> wrote:<br class=""></div><div class="">>>>>> <br class=""></div><div class="">>>>>> The recent PetscUse/TryMethod changes are backward incompatible. Third-party codes cannot compile without modification. Our users deserve better.<br class=""></div><div class="">>>>>> <br class=""></div><div class="">>>>>> <br class=""></div><div class="">>>>>> -- <br class=""></div><div class="">>>>>> Lisandro Dalcin<br class=""></div><div class="">>>>>> ============<br class=""></div><div class="">>>>>> Senior Research Scientist<br class=""></div><div class="">>>>>> Extreme Computing Research Center (ECRC)<br class=""></div><div class="">>>>>> King Abdullah University of Science and Technology (KAUST)<br class=""></div><div class="">>>>>> <a href="http://ecrc.kaust.edu.sa/" class="">http://ecrc.kaust.edu.sa/</a><span class="Apple-converted-space"> </span><<a href="http://ecrc.kaust.edu.sa/" class="">http://ecrc.kaust.edu.sa/</a>><br class=""></div><div class="">>>>> <br class=""></div><div class="">>>>> <br class=""></div><div class="">>>> <br class=""></div><div class="">>> <br class=""></div><div class="">> </div></blockquote></div></blockquote></div><br class=""></div></div></div></body></html>