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

Re: [petsc-dev] plan to transition to new documentation and webpages?
by Satish Balay 06 Mar '21

06 Mar '21

This is partly due to the complexity of having some docs from 'release' and some from 'main' branches. We had a way to manage this when all docs were on petsc website - but its not clear how to do this properly with readthedocs Satish On Fri, 5 Mar 2021, Barry Smith wrote: > > What is the plan to transition to the new documentation and webpages? > > I go to https://www.mcs.anl.gov/petsc/index.html <https://www.mcs.anl.gov/petsc/index.html> and mostly see the old stuff etc. Our next release is coming up soon and it would be nice to have transitioned out of the old material and to the new material by/at the new release. > > What do we need to do to make this happen? > > Thanks > > Barry > >

1 0

plan to transition to new documentation and webpages?
by Barry Smith 05 Mar '21

05 Mar '21

What is the plan to transition to the new documentation and webpages? I go to https://www.mcs.anl.gov/petsc/index.html <https://www.mcs.anl.gov/petsc/index.html> and mostly see the old stuff etc. Our next release is coming up soon and it would be nice to have transitioned out of the old material and to the new material by/at the new release. What do we need to do to make this happen? Thanks Barry

1 0

Re: [petsc-dev] 32 bit compilers and PETSc
by Barry Smith 04 Mar '21

04 Mar '21

Not really bad compilers. Just 32 bit compilers. 640k is all anyone will ever need. > On Mar 4, 2021, at 10:13 AM, Scott Kruger <kruger(a)txcorp.com> wrote: > > On 2021-03-04 08:58, Satish Balay via petsc-dev did write: >> On Wed, 3 Mar 2021, Barry Smith wrote: >>> >>> Can we make ./configure ban 32 bit compilers unless a special flag is used? And just have one CI test that uses 32 bit where we turn off examples that overflow 32 bits? >> >> We could add another linux test where 32bit part is more obvious. >> >> And we have "requires: defined(FLAG)" but not sure if we can check for "PETSC_SIZEOF_VOID_P 8" this way. Perhaps we can add to configure: >> >> requires: defined(PETSC_USING_64BIT_PTR) >> or >> requires: !defined(PETSC_USING_32BIT_PTR) > > This sounds like a lot of work just to figure out which tests overflow, > and then clutter up the tests just to fix bad compilers. For example, > does the "medium" test matrix cause overflow? Perhaps we could just > turn off any external file reading? > > Scott > > >> >> Satish >> >> --- >> diff --git a/config/BuildSystem/config/types.py b/config/BuildSystem/config/types.py >> index 39eda33099..d35adae503 100644 >> --- a/config/BuildSystem/config/types.py >> +++ b/config/BuildSystem/config/types.py >> @@ -268,6 +268,8 @@ char petsc_max_path_len[] = xstr(PETSC_MAX_PATH_LEN); >> 'enum': (4, 8), >> 'size_t': (8, 4)}.items(): >> self.executeTest(self.checkSizeof, args=[t, sizes]) >> + if self.sizes['void-p'] == 8: >> + self.addDefine('USING_64BIT_PTR',1) >> self.executeTest(self.checkVisibility) >> self.executeTest(self.checkMaxPathLen) >> return >> >> >> ./configure CFLAGS=-m32 CXXFLAGS=-m32 FFLAGS=-m32 --with-mpi=0 && make && make check > > -- > Scott Kruger > Tech-X Corporation kruger(a)txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 > Boulder, CO 80303 Fax: (303) 448-7756

1 0

Solaris 64 bit problems building PETSc
by Barry Smith 04 Mar '21

04 Mar '21

Any idea how to fix this stuff or just toss Solaris? https://gitlab.com/petsc/petsc/-/jobs/1071928836 <https://gitlab.com/petsc/petsc/-/jobs/1071928836> ld: warning: relocation error: R_AMD64_PC32: file /export/home/glci/builds/zxfiRCGf/0/petsc/petsc/arch-ci-opensolaris-cmplx-pkgs-dbg/lib/libpetsc.so: symbol petscstack: displacement relocation applied to the symbol <unknown> at 0x4ff91ba: symbol petscstack is a copy relocated symbol 1795 <https://gitlab.com/petsc/petsc/-/jobs/1071928836#L1795>ld: warning: relocation error: R_AMD64_PC32: file /export/home/glci/builds/zxfiRCGf/0/petsc/petsc/arch-ci-opensolaris-cmplx-pkgs-dbg/lib/libpetsc.so: symbol petscstack: displacement relocation applied to the symbol <unknown> at 0x4ff91e0: symbol petscstack is a copy relocated symbol

1 0

petsc-3.14.5 now available
by Satish Balay 04 Mar '21

04 Mar '21

Dear PETSc users, The patch release petsc-3.14.5 is now available for download. http://www.mcs.anl.gov/petsc/download/index.html Satish

1 0

Re: [petsc-dev] 32 bit compilers and PETSc
by Scott Kruger 04 Mar '21

04 Mar '21

On 2021-03-04 08:58, Satish Balay via petsc-dev did write: > On Wed, 3 Mar 2021, Barry Smith wrote: > > > > Can we make ./configure ban 32 bit compilers unless a special flag is used? And just have one CI test that uses 32 bit where we turn off examples that overflow 32 bits? > > We could add another linux test where 32bit part is more obvious. > > And we have "requires: defined(FLAG)" but not sure if we can check for "PETSC_SIZEOF_VOID_P 8" this way. Perhaps we can add to configure: > > requires: defined(PETSC_USING_64BIT_PTR) > or > requires: !defined(PETSC_USING_32BIT_PTR) This sounds like a lot of work just to figure out which tests overflow, and then clutter up the tests just to fix bad compilers. For example, does the "medium" test matrix cause overflow? Perhaps we could just turn off any external file reading? Scott > > Satish > > --- > diff --git a/config/BuildSystem/config/types.py b/config/BuildSystem/config/types.py > index 39eda33099..d35adae503 100644 > --- a/config/BuildSystem/config/types.py > +++ b/config/BuildSystem/config/types.py > @@ -268,6 +268,8 @@ char petsc_max_path_len[] = xstr(PETSC_MAX_PATH_LEN); > 'enum': (4, 8), > 'size_t': (8, 4)}.items(): > self.executeTest(self.checkSizeof, args=[t, sizes]) > + if self.sizes['void-p'] == 8: > + self.addDefine('USING_64BIT_PTR',1) > self.executeTest(self.checkVisibility) > self.executeTest(self.checkMaxPathLen) > return > > > ./configure CFLAGS=-m32 CXXFLAGS=-m32 FFLAGS=-m32 --with-mpi=0 && make && make check -- Scott Kruger Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Commit squashing in MR
by Jed Brown 04 Mar '21

04 Mar '21

If you're in Emacs, Magit (https://github.com/magit/magit) is excellent for much the same things, and works over remote (i.e., I'm editing "ssh:thathost:path/to/file.c" and invoke magit). There's also a (partial) magit clone for vscode. https://marketplace.visualstudio.com/items?itemName=kahole.magit Patrick Sanan <patrick.sanan(a)gmail.com> writes: > I have also been enjoying using lazygit (thanks, Lisandro, for the tip!). It's a similar sort of thing but runs in the terminal. > I find it very useful for those things where the command line git tool falls down (staging parts of files, browsing large sets of changes), and I like that I don't have to bother with X windows to use something like gitk on my remote machine. > > https://github.com/jesseduffield/lazygit > > The only wrinkles I ran into using this are that is seems to assume you have a somewhat-recent "git" executable for some of the fancier > features (like merging or rearranging commits without using git rebase -i). > >> Am 03.03.2021 um 21:02 schrieb Jacob Faibussowitsch <jacob.fai(a)gmail.com>: >> >>> 'gitk' is easier to read [for me] than 'git log --graph' >> >> Where was this my entire life… best kept git secret! >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >>> On Mar 3, 2021, at 13:55, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >>> >>> 'gitk' is easier to read [for me] than 'git log --graph' >>> >>> Satish >>> >>> On Wed, 3 Mar 2021, Jacob Faibussowitsch wrote: >>> >>>>> git: 'graph' is not a git command. See 'git --help'. >>>> >>>> I have it as an alias: >>>> >>>> graph = !git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative >>>> >>>> Best regards, >>>> >>>> Jacob Faibussowitsch >>>> (Jacob Fai - booss - oh - vitch) >>>> Cell: (312) 694-3391 >>>> >>>>> On Mar 3, 2021, at 13:50, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Mar 2, 2021 at 10:02 PM Junchao Zhang <junchao.zhang(a)gmail.com <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>> I am a naive git user, so I use interactive git rebase. Suppose I am on the branch I want to modify, >>>>> >>>>> 1) Use git graph to locate an upstream commit to be used as the base >>>>> $ git graph >>>>> >>>>> Humm .... >>>>> >>>>> 14:49 adams/cusparse-lu-landau= /gpfs/alpine/csc314/scratch/adams/petsc$ git --version >>>>> git version 2.20.1 >>>>> 14:49 adams/cusparse-lu-landau= /gpfs/alpine/csc314/scratch/adams/petsc$ git graph >>>>> git: 'graph' is not a git command. See 'git --help'. >>>>> >>>>> The most similar commands are >>>>> branch >>>>> grep >>>>> >>>> >>>> >>> >>

1 0

Re: [petsc-dev] 32 bit compilers and PETSc
by Satish Balay 04 Mar '21

04 Mar '21

On Wed, 3 Mar 2021, Barry Smith wrote: > > I just wasted an enormous amount of time "debugging"my additions to BAIJ on the solaris test machines. Turns out there was no bug at all just that the compilers default to 32 bit and we have no possible way of detecting size_t overflow; so smallish test cases can become a debugging nightmare. > > Can we make ./configure ban 32 bit compilers unless a special flag is used? And just have one CI test that uses 32 bit where we turn off examples that overflow 32 bits? We could add another linux test where 32bit part is more obvious. And we have "requires: defined(FLAG)" but not sure if we can check for "PETSC_SIZEOF_VOID_P 8" this way. Perhaps we can add to configure: requires: defined(PETSC_USING_64BIT_PTR) or requires: !defined(PETSC_USING_32BIT_PTR) Satish --- diff --git a/config/BuildSystem/config/types.py b/config/BuildSystem/config/types.py index 39eda33099..d35adae503 100644 --- a/config/BuildSystem/config/types.py +++ b/config/BuildSystem/config/types.py @@ -268,6 +268,8 @@ char petsc_max_path_len[] = xstr(PETSC_MAX_PATH_LEN); 'enum': (4, 8), 'size_t': (8, 4)}.items(): self.executeTest(self.checkSizeof, args=[t, sizes]) + if self.sizes['void-p'] == 8: + self.addDefine('USING_64BIT_PTR',1) self.executeTest(self.checkVisibility) self.executeTest(self.checkMaxPathLen) return ./configure CFLAGS=-m32 CXXFLAGS=-m32 FFLAGS=-m32 --with-mpi=0 && make && make check

1 0

Re: [petsc-dev] Commit squashing in MR
by Patrick Sanan 04 Mar '21

04 Mar '21

I have also been enjoying using lazygit (thanks, Lisandro, for the tip!). It's a similar sort of thing but runs in the terminal. I find it very useful for those things where the command line git tool falls down (staging parts of files, browsing large sets of changes), and I like that I don't have to bother with X windows to use something like gitk on my remote machine. https://github.com/jesseduffield/lazygit The only wrinkles I ran into using this are that is seems to assume you have a somewhat-recent "git" executable for some of the fancier features (like merging or rearranging commits without using git rebase -i). > Am 03.03.2021 um 21:02 schrieb Jacob Faibussowitsch <jacob.fai(a)gmail.com>: > >> 'gitk' is easier to read [for me] than 'git log --graph' > > Where was this my entire life… best kept git secret! > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >> On Mar 3, 2021, at 13:55, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >> >> 'gitk' is easier to read [for me] than 'git log --graph' >> >> Satish >> >> On Wed, 3 Mar 2021, Jacob Faibussowitsch wrote: >> >>>> git: 'graph' is not a git command. See 'git --help'. >>> >>> I have it as an alias: >>> >>> graph = !git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative >>> >>> Best regards, >>> >>> Jacob Faibussowitsch >>> (Jacob Fai - booss - oh - vitch) >>> Cell: (312) 694-3391 >>> >>>> On Mar 3, 2021, at 13:50, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Tue, Mar 2, 2021 at 10:02 PM Junchao Zhang <junchao.zhang(a)gmail.com <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> I am a naive git user, so I use interactive git rebase. Suppose I am on the branch I want to modify, >>>> >>>> 1) Use git graph to locate an upstream commit to be used as the base >>>> $ git graph >>>> >>>> Humm .... >>>> >>>> 14:49 adams/cusparse-lu-landau= /gpfs/alpine/csc314/scratch/adams/petsc$ git --version >>>> git version 2.20.1 >>>> 14:49 adams/cusparse-lu-landau= /gpfs/alpine/csc314/scratch/adams/petsc$ git graph >>>> git: 'graph' is not a git command. See 'git --help'. >>>> >>>> The most similar commands are >>>> branch >>>> grep >>>> >>> >>> >> >

1 0

32 bit compilers and PETSc
by Barry Smith 03 Mar '21

03 Mar '21

I just wasted an enormous amount of time "debugging"my additions to BAIJ on the solaris test machines. Turns out there was no bug at all just that the compilers default to 32 bit and we have no possible way of detecting size_t overflow; so smallish test cases can become a debugging nightmare. Can we make ./configure ban 32 bit compilers unless a special flag is used? And just have one CI test that uses 32 bit where we turn off examples that overflow 32 bits? Barry

1 0