January 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] adding Report Typo and Errors link to manual pages
by Jed Brown 06 Jan '14

06 Jan '14

Satish Balay <balay(a)mcs.anl.gov> writes: > How about: http://ftp.mcs.anl.gov/pub/petsc/tmp/VecView.html > > [perhaps 'MANUALPAGE' can be changed to 'documentation' - if we are doing this for all docs.] The message should come preformatted to include the URL of the page on which a typo is being reported. I would also reduce the font size a little.

1 0

Re: [petsc-dev] adding Report Typo and Errors link to manual pages
by Satish Balay 06 Jan '14

06 Jan '14

On Mon, 6 Jan 2014, Jed Brown wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > Do you want this for only 'manpages' or all generated html? > > I want it (somewhere unintrusive) for all HTML pages (generated or not). > How about: http://ftp.mcs.anl.gov/pub/petsc/tmp/VecView.html [perhaps 'MANUALPAGE' can be changed to 'documentation' - if we are doing this for all docs.] Satish diff --git a/makefile b/makefile index 362c004..9de2ad2 100644 --- a/makefile +++ b/makefile @@ -335,11 +335,13 @@ docsetdate: chk_petscdir fi; \ datestr=`git log -1 --pretty=format:%ci | cut -d ' ' -f 1`; \ export datestr; \ + typostr=' <div id="bugreport" align=right><a href="mailto:[email protected]?subject=Typo or Error in MANUALPAGE &body=Please describe the typo or error in the manual page">Report Typos and Errors</a></div>';\ + export typostr; \ find * -type d -wholename src/docs/website -prune -o -type d -wholename src/benchmarks/results -prune -o \ -type d -wholename config/BuildSystem/docs/website -prune -o -type d -wholename include/web -prune -o \ -type d -wholename 'arch-*' -prune -o -type d -wholename src/tops -prune -o -type d -wholename externalpackages -prune -o \ -type f -wholename tutorials/multiphysics/tutorial.html -prune -o -type f -name \*.html \ - -exec perl -pi -e 's^(<body.*>)^$$1\n <div id=\"version\" align=right><b>$$ENV{petscversion} $$ENV{datestr}</b></div>^i' {} \; \ + -exec perl -pi -e 's^(<body.*>)^$$1\n <div id=\"version\" align=right><b>$$ENV{petscversion} $$ENV{datestr}</b></div>\n$$ENV{typostr}^i' {} \; \ -exec perl -pi -e 's^(<head>)^$$1 <link rel="canonical" href="http://www.mcs.anl.gov/petsc/petsc-current/{}" />^i' {} \; ; \ echo "Done fixing version number, date, canonical URL info"

1 0

Re: [petsc-dev] adding Report Typo and Errors link to manual pages
by Jed Brown 06 Jan '14

06 Jan '14

Satish Balay <balay(a)mcs.anl.gov> writes: > Do you want this for only 'manpages' or all generated html? I want it (somewhere unintrusive) for all HTML pages (generated or not).

1 0

Re: [petsc-dev] adding Report Typo and Errors link to manual pages
by Satish Balay 06 Jan '14

06 Jan '14

Barry, Do you want this for only 'manpages' or all generated html? if all generated docs - then this would be same as adding as the version/date on the top-right corner. If only manpages - then I'll have to add this to a location where the manpages are generated/modified. thanks, Satish On Wed, 1 Jan 2014, Barry Smith wrote: > > Satish, > > Resending this. Should be really straightforward, please let me know if there are difficulties in getting this done soon. > > Thanks > > Barry > > Request-assigned: balay add Report Typos and Errors link to all manual pages > > On Dec 10, 2013, at 11:11 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > Satish, > > > > Please add to the generation of all manual pages (in the upper right corner) a Report Typos and Errors link using mailto: For example something like > > > > <a href=“mailto:[email protected]?subject=Typo or Error in MANUALPAGE &body=Please describe the typo or error in the manual page">Report Typos and Errors</a> > > > > where MANUALPAGE is the name of that generated manual page. > > > > Thanks > > > > Barry > > > >

1 0

Re: [petsc-dev] broken stuff in next please fix
by Jed Brown 05 Jan '14

05 Jan '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > It appears that this bug appeared in a release and hence could > affect many users. Same with ParMETIS bugs, V1R2M0, and numerous compiler bugs. PETSc releases have bugs too. Releases are never completely bug-free; responsible projects put out patch releases quickly after finding bugs, and make it as easy as possible to upgrade. > I think configure should detect it and do either A) or B) > otherwise it looks to all users like a bug in PETSc, when it is > not. Yes we cannot catalog all bugs but ones that we know about > and that make PETSc look bad should be handled. If we do this with all known bugs, BuildSystem will grow to be bigger than PETSc and take hours to run. mpich-3.0.4 has been out for a long time now, and most everyone with a sensible distribution has had a painless and automatic upgrade.

1 0

Re: [petsc-dev] broken stuff in next please fix
by Barry Smith 05 Jan '14

05 Jan '14

On Jan 5, 2014, at 1:09 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> I have switched back to using the >> mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that >> change into a commit when I shouldn’t have. (I still miss the nice >> bk gui that showed cleanly each change you were committing). > > I never used the bk gui, but what is lacking in "git gui" or sourcetree? > >> But it is extremely worrisome that we need to use PARTICULAR >> versions of MPI implementations to get clean compilers?!?!?! >> >> 1) Isn’t this fundamentally wrong? > > Like all dependencies, MPI implementations can have bugs. This was a > bug and was fixed before it spent much time in the wild. It appears that this bug appeared in a release and hence could affect many users. I think configure should detect it and do either A) or B) otherwise it looks to all users like a bug in PETSc, when it is not. Yes we cannot catalog all bugs but ones that we know about and that make PETSc look bad should be handled. Barry > The memory bug > is more subtle and I have no idea why mpich-3.0.5 has not been released. > >> 1.5) Do we want to be in the business of saying, “if you use >> compiler XX version YY then you need to use MPICH implementation >> version ZZ, otherwise it won’t work? > > This is just a warning, but some MPI implementations have functions that > crash at runtime. Others have space leaks (e.g., V1R2M0 on BG/Q). > >> 2) Shouldn’t we be portable to all the various MPI implementations that are released at various times? >> >> 3) Do we need a configure test to properly handle the “broken” MPI implementations? > > Lots of compilers have bugs too, including wrong code. I don't think > it's maintainable to catalog all the bugs in all dependencies on all > architectures. If something is buggy on a popular system, such that it > creates complaints, we can work around it. Note that some packages like > ParMETIS have major open bugs that people hit all the time, and we > maintain patches that upstream inexplicably does not apply. > > In the case of MPI type tags, the user encounters the same warnings if > they use MPI_2INT. > > > Public shaming for known bugs that intentionally cannot be detected at > configure time is one marginally-effective recourse.

1 0

Re: [petsc-dev] broken stuff in next please fix
by Jed Brown 05 Jan '14

05 Jan '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > I have switched back to using the > mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that > change into a commit when I shouldn’t have. (I still miss the nice > bk gui that showed cleanly each change you were committing). I never used the bk gui, but what is lacking in "git gui" or sourcetree? > But it is extremely worrisome that we need to use PARTICULAR > versions of MPI implementations to get clean compilers?!?!?! > > 1) Isn’t this fundamentally wrong? Like all dependencies, MPI implementations can have bugs. This was a bug and was fixed before it spent much time in the wild. The memory bug is more subtle and I have no idea why mpich-3.0.5 has not been released. > 1.5) Do we want to be in the business of saying, “if you use > compiler XX version YY then you need to use MPICH implementation > version ZZ, otherwise it won’t work? This is just a warning, but some MPI implementations have functions that crash at runtime. Others have space leaks (e.g., V1R2M0 on BG/Q). > 2) Shouldn’t we be portable to all the various MPI implementations that are released at various times? > > 3) Do we need a configure test to properly handle the “broken” MPI implementations? Lots of compilers have bugs too, including wrong code. I don't think it's maintainable to catalog all the bugs in all dependencies on all architectures. If something is buggy on a popular system, such that it creates complaints, we can work around it. Note that some packages like ParMETIS have major open bugs that people hit all the time, and we maintain patches that upstream inexplicably does not apply. In the case of MPI type tags, the user encounters the same warnings if they use MPI_2INT. Public shaming for known bugs that intentionally cannot be detected at configure time is one marginally-effective recourse.

1 0

Re: [petsc-dev] broken stuff in next please fix
by Barry Smith 05 Jan '14

05 Jan '14

I have switched back to using the mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that change into a commit when I shouldn’t have. (I still miss the nice bk gui that showed cleanly each change you were committing). But it is extremely worrisome that we need to use PARTICULAR versions of MPI implementations to get clean compilers?!?!?! 1) Isn’t this fundamentally wrong? 1.5) Do we want to be in the business of saying, “if you use compiler XX version YY then you need to use MPICH implementation version ZZ, otherwise it won’t work? 2) Shouldn’t we be portable to all the various MPI implementations that are released at various times? 3) Do we need a configure test to properly handle the “broken” MPI implementations? It seems to me that we need to have configure either A) declare certain MPI implementations as broken and tell the user to change implementations or B) use conditional compiles so PETSc builds cleanly even with these “broken” MPI implementations. How are we going to fix this? remember not everyone uses —download-mpich Barry On Jan 4, 2014, at 9:49 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: >> We were previously using v3.0.4 [with some bug fixes for some issues that >> came up in petsc testing]. >> >> http://ftp.mcs.anl.gov/pub/petsc/tmp/mpich-master-v3.0.4-106-g3adb59c.tar.gz > > Barry, what was the idea here? > > https://bitbucket.org/petsc/petsc/commits/7904a3320b8a1f45505a06da988fac624… > > It's certainly unrelated to the rest of the commit. Shall we just > revert that part? > > > And how is it that the MPICH release has a memory bug for 8 months > during which time they haven't put out a new patch release (3.0.5)? > > http://git.mpich.org/mpich.git/commit/3adb59cb83a4f675ba990062c62396d1a2348…

1 0

ParMETIS assertion with pc_gamg_repartition
by John Mousel 05 Jan '14

05 Jan '14

I'm getting a ParMETIS assertion: [53] ***ASSERTION failed on line 176 of file /nics/b/home/jmousel/NumericalLibraries/petsc/intel-debug/externalpackages/parmetis-4.0.3-p1/libparmetis/comm.c: j == nnbrs [110] ***ASSERTION failed on line 176 of file /nics/b/home/jmousel/NumericalLibraries/petsc/intel-debug/externalpackages/parmetis-4.0.3-p1/libparmetis/comm.c: j == nnbrs when I add -redistribute_pc_gamg_repartition true to my option list: -pres_ksp_type preonly -pres_pc_type redistribute -pres_redistribute_ksp_type pgmres -pres_redistribute_pc_type gamg -pres_redistribute_pc_gamg_threshold 0.05 -pres_redistribute_mg_levels_ksp_type richardson -pres_redistribute_mg_levels_pc_type sor -pres_redistribute_mg_coarse_ksp_type richardson -pres_redistribute_mg_coarse_pc_type sor -pres_redistribute_mg_coarse_pc_sor_its 3 -pres_redistribute_mg_type full -pres_redistribute_pc_gamg_type agg -pres_redistribute_pc_gamg_agg_nsmooths 1 -pres_redistribute_pc_gamg_sym_graph true -ELAFINT_flex_comm_size 16 -vel_ksp_type ibcgs -vel_ksp_monitor -pres_redistribute_ksp_monitor -lspaint_ksp_monitor -pres_redistribute_pc_gamg_repartition true -pres_redistribute_pc_gamg_reuse_interpolation There is no additional stack trace to provide. I receive the same message for 12, 48, 60, and 120 cores. The matrix has about 12 million rows. John

1 0

Re: [petsc-dev] broken stuff in next please fix
by Jed Brown 04 Jan '14

04 Jan '14

Satish Balay <balay(a)mcs.anl.gov> writes: > We were previously using v3.0.4 [with some bug fixes for some issues that > came up in petsc testing]. > > http://ftp.mcs.anl.gov/pub/petsc/tmp/mpich-master-v3.0.4-106-g3adb59c.tar.gz Barry, what was the idea here? https://bitbucket.org/petsc/petsc/commits/7904a3320b8a1f45505a06da988fac624… It's certainly unrelated to the rest of the commit. Shall we just revert that part? And how is it that the MPICH release has a memory bug for 8 months during which time they haven't put out a new patch release (3.0.5)? http://git.mpich.org/mpich.git/commit/3adb59cb83a4f675ba990062c62396d1a2348…

1 0