March 2021 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] where is DATAFILESPATH ?
by Satish Balay 31 Mar '21

31 Mar '21

The repo is at https://gitlab.com/petsc/datafiles If a clone is located in ~/ - configure will look for it and use it. Otherwise one can specify with DATAFILESPATH=loc configure option Satish On Wed, 31 Mar 2021, Eric Chamberland wrote: > Hi, > > looking at petsc tests launched from "make test", I see many tests are skipped > like this: > > ok ksp_ksp_tutorials-ex76_1 # SKIP Requires DATAFILESPATH > TEST > arch-linux-c-debug/tests/counts/ksp_ksp_tutorials-ex76_geneo_pc_hpddm_levels_1_eps_nev-5.counts > > But where can I find the repository containing the data for these tests?... > > Or what is the right value for DATAFILESPATH? > > Thanks, > > Eric > >

1 0

where is DATAFILESPATH ?
by Eric Chamberland 31 Mar '21

31 Mar '21

Hi, looking at petsc tests launched from "make test", I see many tests are skipped like this: ok ksp_ksp_tutorials-ex76_1 # SKIP Requires DATAFILESPATH TEST arch-linux-c-debug/tests/counts/ksp_ksp_tutorials-ex76_geneo_pc_hpddm_levels_1_eps_nev-5.counts But where can I find the repository containing the data for these tests?... Or what is the right value for DATAFILESPATH? Thanks, Eric -- Eric Chamberland, ing., M. Ing Professionnel de recherche GIREF/Université Laval (418) 656-2131 poste 41 22 42

1 0

Re: [petsc-dev] Tag name v3.15
by Satish Balay 31 Mar '21

31 Mar '21

On Wed, 31 Mar 2021, Jed Brown wrote: > Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> writes: > > > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > > > >> On Wed, 31 Mar 2021 at 18:07, Satish Balay <balay(a)mcs.anl.gov> wrote: > >> > >> > And we just use 2 level workflow, and have branches for each of the > >> > 'releases' [as we move from one to the other] > >> > > >> > >> Maybe I'm not making myself clear. > >> What I find a bit awkward is that I can define > >> > >> x=3 > >> y=15 > >> z=0 > >> > >> and then do: > >> > >> wget > >> https://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-$x.$y.$z.tar.gz > >> tar zxf petsc-$x.$y.$z.tar.gz > >> cd petsc-$x.$y.$z > >> ... > >> > >> But I cannot do > >> > >> git clone ... > >> git checkout v$x.$y.$z > >> > >> because there is no tag v3.15.0, just v3.15 > > > > I agree - the current usage causes this problem. > > > > I vote for switching over to v3.15.0 [or add both tags v3.15.0 and > > v3.15 - to not break things for 'v3.15' usage - assuming 2 tags wont' > > cause other issues] > > It's okay with me to add v3.15.0 (without removing v3.15) and just tag v3.16.0 in future releases. > Ok - pushed v3.15.0 tag Satish

1 0

Re: [petsc-dev] Tag name v3.15
by Jed Brown 31 Mar '21

31 Mar '21

Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> writes: > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > >> On Wed, 31 Mar 2021 at 18:07, Satish Balay <balay(a)mcs.anl.gov> wrote: >> >> > And we just use 2 level workflow, and have branches for each of the >> > 'releases' [as we move from one to the other] >> > >> >> Maybe I'm not making myself clear. >> What I find a bit awkward is that I can define >> >> x=3 >> y=15 >> z=0 >> >> and then do: >> >> wget >> https://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-$x.$y.$z.tar.gz >> tar zxf petsc-$x.$y.$z.tar.gz >> cd petsc-$x.$y.$z >> ... >> >> But I cannot do >> >> git clone ... >> git checkout v$x.$y.$z >> >> because there is no tag v3.15.0, just v3.15 > > I agree - the current usage causes this problem. > > I vote for switching over to v3.15.0 [or add both tags v3.15.0 and > v3.15 - to not break things for 'v3.15' usage - assuming 2 tags wont' > cause other issues] It's okay with me to add v3.15.0 (without removing v3.15) and just tag v3.16.0 in future releases.

1 0

Re: [petsc-dev] Tag name v3.15
by Matthew Knepley 31 Mar '21

31 Mar '21

On Wed, Mar 31, 2021 at 11:21 AM Satish Balay via petsc-dev < petsc-dev(a)mcs.anl.gov> wrote: > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > > > On Wed, 31 Mar 2021 at 18:07, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > And we just use 2 level workflow, and have branches for each of the > > > 'releases' [as we move from one to the other] > > > > > > > Maybe I'm not making myself clear. > > What I find a bit awkward is that I can define > > > > x=3 > > y=15 > > z=0 > > > > and then do: > > > > wget > > > https://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-$x.$y.$z.tar.gz > > tar zxf petsc-$x.$y.$z.tar.gz > > cd petsc-$x.$y.$z > > ... > > > > But I cannot do > > > > git clone ... > > git checkout v$x.$y.$z > > > > because there is no tag v3.15.0, just v3.15 > > I agree - the current usage causes this problem. > > I vote for switching over to v3.15.0 [or add both tags v3.15.0 and > v3.15 - to not break things for 'v3.15' usage - assuming 2 tags wont' > cause other issues] > +1 Matt > Satish > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] Tag name v3.15
by Satish Balay 31 Mar '21

31 Mar '21

On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > On Wed, 31 Mar 2021 at 18:07, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > And we just use 2 level workflow, and have branches for each of the > > 'releases' [as we move from one to the other] > > > > Maybe I'm not making myself clear. > What I find a bit awkward is that I can define > > x=3 > y=15 > z=0 > > and then do: > > wget > https://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-$x.$y.$z.tar.gz > tar zxf petsc-$x.$y.$z.tar.gz > cd petsc-$x.$y.$z > ... > > But I cannot do > > git clone ... > git checkout v$x.$y.$z > > because there is no tag v3.15.0, just v3.15 I agree - the current usage causes this problem. I vote for switching over to v3.15.0 [or add both tags v3.15.0 and v3.15 - to not break things for 'v3.15' usage - assuming 2 tags wont' cause other issues] Satish

1 0

Re: [petsc-dev] Tag name v3.15
by Satish Balay 31 Mar '21

31 Mar '21

On Wed, 31 Mar 2021, Jed Brown wrote: > > Wrt v3.15.0 vs v3.15 I don't remember the exact reason. I suspect we > > just stuck with this notation for a long time [and didn't want to > > change it] > > I believe we were adopting the convention from Git and others. Ah - ok. Looking at our mercurial repo - I see: >> $ hg tags tip 24855:0b3db6507615 release-3.3 23582:adad7ff64fb1 release-3.2 20307:cad0859b4453 release-3.1 15532:f6965e7f147c release-3.0.0 13216:621178841b37 release-2.3.3 10547:c59a3fc37afc release-2.3.2 9364:1aa4d6336f27 >>> So we did change from 'release-3.0.0' to 'v3.0.0' and then 'v3.1' [in our git repo] Satish

1 0

Re: [petsc-dev] Tag name v3.15
by Lisandro Dalcin 31 Mar '21

31 Mar '21

On Wed, 31 Mar 2021 at 18:07, Satish Balay <balay(a)mcs.anl.gov> wrote: > And we just use 2 level workflow, and have branches for each of the > 'releases' [as we move from one to the other] > Maybe I'm not making myself clear. What I find a bit awkward is that I can define x=3 y=15 z=0 and then do: wget https://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-$x.$y.$z.tar.gz tar zxf petsc-$x.$y.$z.tar.gz cd petsc-$x.$y.$z ... But I cannot do git clone ... git checkout v$x.$y.$z because there is no tag v3.15.0, just v3.15 -- Lisandro Dalcin ============ Senior Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

1 0

Re: [petsc-dev] Tag name v3.15
by Satish Balay 31 Mar '21

31 Mar '21

And we just use 2 level workflow, and have branches for each of the 'releases' [as we move from one to the other] $ git branch -r |egrep 'origin/(maint|release)-' origin/maint-3.10 origin/maint-3.11 origin/maint-3.12 origin/maint-3.2 origin/maint-3.3 origin/maint-3.4 origin/maint-3.5 origin/maint-3.6 origin/maint-3.7 origin/maint-3.8 origin/maint-3.9 origin/maint-tao-2.2 origin/release-3.13 origin/release-3.14 Satish On Wed, 31 Mar 2021, Satish Balay via petsc-dev wrote: > >>>> > https://semver.org/ > > Given a version number MAJOR.MINOR.PATCH, increment the: > > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes. > <<<< > > For one - we don't strictly use semantic versions. > > - Our PATCH versions have (some) new functionality [from above that should be MINOR] > - Our MINOR versions have lot more new functionality, with some incompatible API changes [this should be MAJOR - but we haven't changed that in a while] > > Wrt v3.15.0 vs v3.15 I don't remember the exact reason. I suspect we > just stuck with this notation for a long time [and didn't want to > change it] > > Also Barry still wants to use 'release' term only with v3.15 - and 3.15.1 etc as updates [but not releases] > > Satish > > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > > > Satish, if we use semantic versioning for the PETSc version itself and the > > tarball, why don't we use the same format for tags? In short, why aren't we > > using v3.15.0 instead of v3.15 ? > > > > >

1 0

Re: [petsc-dev] Tag name v3.15
by Jed Brown 31 Mar '21

31 Mar '21

Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> writes: >>>>> > https://semver.org/ > > Given a version number MAJOR.MINOR.PATCH, increment the: > > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes. > <<<< > > For one - we don't strictly use semantic versions. > > - Our PATCH versions have (some) new functionality [from above that should be MINOR] > - Our MINOR versions have lot more new functionality, with some incompatible API changes [this should be MAJOR - but we haven't changed that in a while] I think the idea is that petsc-4.x is being reserved for a hypothetical petsc-future, while 3.x is everything with modest incremental changes from where we are now. To apply semantic versioning, some projects just increase the major number -- we have Firefox 87 and Chromium 89. Linux was 2.6.x for ages and then just declared they would start incrementing the major and minor versions despite an equivalent compatibility policy. So they did 3.0 - 3.19, 4.0 - 4.20, and are now 5.11. I'm happy with our current 3.x strategy, reserving 4.x for something with potentially more cross-cutting changes (even a new primary implementation language), though an incremental migration strategy would still need to be present. > Wrt v3.15.0 vs v3.15 I don't remember the exact reason. I suspect we > just stuck with this notation for a long time [and didn't want to > change it] I believe we were adopting the convention from Git and others. > Also Barry still wants to use 'release' term only with v3.15 - and 3.15.1 etc as updates [but not releases] > > Satish > > On Wed, 31 Mar 2021, Lisandro Dalcin wrote: > >> Satish, if we use semantic versioning for the PETSc version itself and the >> tarball, why don't we use the same format for tags? In short, why aren't we >> using v3.15.0 instead of v3.15 ? >> >>

1 0