Techically even a cycle can be dealt with. - have a june release of all packages (with old version dependencies). - have a sept release of all packages (with new versiondependencies) - but don't change API from june to sept
But practically - every packages has their own release cyle [and issues] and perhaps a world view [the same way we think in PETSc centric mode] - So far (within the xsdk side of things) - issues came up and were able to deal with when discovered. But its not clear how we can improve on this [witout some buy-in from individual packages to not beak things in a major way. and adding testing to detect things early enough so there is time to deal with them.] Satish On Sun, 3 Apr 2022, Barry Smith wrote: > > I agree this is an issue with xsdk; I don't have any good technical > solution for packages with cyclic dependencies; for one-way dependencies the > solution is easy as Jed pointed out, just sort the dependencies and make sure > that packages that depend on, for example, PETSc get final xsdk "releases" > after PETSc. Politically this may be hard, technically it is easy. This would > mean finalizing hypre and superlu_dist then finalizing PETSc then finalizing > dealii. > > > > > On Apr 3, 2022, at 1:15 PM, Satish Balay via petsc-dev > > <petsc-dev@mcs.anl.gov> wrote: > > > > This issue comes up in xsdk. most packages [superlu_dist, hypre, petsc, > > trilinos - and a bunch of others] attempt to make a release in sept [ECP > > milestone]. > > > > But then there are non-ecp packages that don't do that - and isues come up > > [for ex: dealii usually has an earlier release - that has a dependency on > > petsc.] > > > > One of the tasks is to setup CI to detect this early enough. But then - > > there could be many breakages - and the first brakage [until its addressed] > > prevents one from noticing the next breakage] > > > > https://gitlab.com/xsdk-project/spack-xsdk/-/jobs/2285145631 > > > > There are multiple challanges here - [apart from the moving target in each > > packages] - just identifying the correct target for the external package - > > i.e: will there be a new release of the external package-A before package-B > > - and what branch should one target (to test) for that new release etc.. > > > > And Its not clear if we can push some of this testing to individual package > > test suite [instead of completely at the xsdk level]. i.e what kind of > > testing in the PETSc CI cycle would help here? > > > > Just having 1 moving package [petsc4py] in this CI cycle - triggered in a > > merge of petsc4py sources in petsc source tree. Not sure how what issues > > would come up if we have others. > > > > I have a small subset of this in xsdk ci > > https://gitlab.com/xsdk-project/spack-xsdk/-/jobs/2285145624 > > > > $ nice ./bin/spack install --fail-fast -j24 slepc@main > > ^petsc@main+mpi+hypre+superlu-dist+metis+hdf5~mumps+double~int64 > > ^netlib-lapack pflotran@develop > > ^petsc@main+mpi+hypre+superlu-dist+metis+hdf5~mumps+double~int64 > > ^netlib-lapack > > > > Satish > > > > On Sun, 3 Apr 2022, Jed Brown wrote: > > > >> Sundials, for example. > >> > >> 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. > >> > >> 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. > >> > >> On Sun, Apr 3, 2022, at 10:45 AM, Barry Smith wrote: > >>> > >>> > >>>> On Apr 3, 2022, at 12:24 PM, Satish Balay <ba...@mcs.anl.gov> wrote: > >>>> > >>>>> If we had this attitude with the external packages PETSc uses we would > >>>>> have to stop using most of the packages/*.py. > >>>> > >>>> 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. > >>>> > >>>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> > >>> > >>> > >>>> > >>>> [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] > >>>> > >>>> We did update to newer interfaces in some packages. > >>>> > >>>> But these problems remain - and have to be dealt with - and sometimes > >>>> the complexity increases based on the dependency tree. > >>>> > >>>> [and also results in folk using and requiring help with older petsc > >>>> versions] > >>>> > >>>> Satish > >>>> > >>>> > >>>> On Sun, 3 Apr 2022, Barry Smith wrote: > >>>> > >>>>> > >>>>> 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 <ba...@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 <dalc...@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/> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > > >
