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

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines
by Satish Balay 16 Mar '21

16 Mar '21

On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: > > My [partial] change is in branch balay/reorg-f90-for-xlf > > Satish is this branch pushed? I’d like to send it to the ibm folks to see if it works for them as well. Sorry - pushed now. From what I remember - it didn't work. Satish > They also added this extra follow up: > > The change we did in the source files is to replace all the "use pet*" statements in all the Interface blocks with IMPORT statement. > > The nature of this workaround is to reduce the number of symbols that the compiler have to create, which exceeded the limitation and caused ICE. > > Every USE statement in an interface block opens up the module symbol file and reads all the symbols from it and creates an entity for each symbol in compiler. This is unnecessary when the module already has the same USE statement in the module scope. Instead, users can use IMPORT statement to make the module symbols accessible inside interface face blocks. > > With the change, the compiler would only read the module symbol file once and create one set of symbols where the old code reads the module symbol files as many times as the number of the USE statements in Interface blocks and create that many sets of duplicate symbols. Replacing those USE statements with IMPORT statements also shortens the compile time significantly. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > > On Mar 3, 2021, at 13:43, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > > > The only change I can get working (i.e avoid compile errors) is to split petscvecmod.F90 into 2 source files - but I don't know if this will help with xlf.. > > > > My [partial] change is in branch balay/reorg-f90-for-xlf > > > > Satish > > > > On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: > > > >> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: > >> > >>> Sure - once any change works locally [for gcc and xlf] > >>> > >>> When I try - I get a bunch of errors.. [yet to digest them.] > >> > >>>>>>> Can you please give the following source code workaround a try? > >>>>>>> Since there is already "use petscvecdefdummy" at the module scope, one workaround might be to remove the unnecessary "use petscvecdefdummy" in vecnotequal and vecequals > >>>>>>> and all similar procedures. > >>>>>>> > >>>>>>> For example, the test case has: > >>>>>>> module petscvecdef > >>>>>>> use petscvecdefdummy > >>>>>>> ... > >>>>>>> function vecnotequal(A,B) > >>>>>>> use petscvecdefdummy > >>>>>>> logical vecnotequal > >>>>>>> type(tVec), intent(in) :: A,B > >>>>>>> vecnotequal = (A%v .ne. B%v) > >>>>>>> end function > >> > >> > >> Ok - try this suggestion: > >> > >> diff --git a/src/vec/f90-mod/petscvecmod.F90 b/src/vec/f90-mod/petscvecmod.F90 > >> index 0c447156b9..81968c7ca1 100644 > >> --- a/src/vec/f90-mod/petscvecmod.F90 > >> +++ b/src/vec/f90-mod/petscvecmod.F90 > >> @@ -77,7 +77,6 @@ > >> use petscvecdefdummy > >> interface operator(.ne.) > >> function vecnotequal(A,B) > >> - use petscvecdefdummy > >> logical vecnotequal > >> type(tVec), intent(in) :: A,B > >> end function > >> > >> > >>>>>>> > >> FC arch-linux-c-debug/obj/vec/f90-mod/petscvecmod.o > >> /home/balay/petsc/src/vec/f90-mod/petscvecmod.F90:81:22: > >> > >> 81 | type(tVec), intent(in) :: A,B > >> | 1 > >> Error: Derived type ‘tvec’ at (1) is being used before it is defined > >> /home/balay/petsc/include/../src/vec/f90-mod/ftn-auto-interfaces/petscis.h90:2:10: > >> > >> 2 | use petscvecdef > >> | 1 > >> Fatal Error: Cannot open module file ‘petscvecdef.mod’ for reading at (1): No such file or directory > >> <<<<<< > >> > >> Satish > >

1 0

Re: [petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines
by Jacob Faibussowitsch 16 Mar '21

16 Mar '21

> My [partial] change is in branch balay/reorg-f90-for-xlf Satish is this branch pushed? I’d like to send it to the ibm folks to see if it works for them as well. They also added this extra follow up: The change we did in the source files is to replace all the "use pet*" statements in all the Interface blocks with IMPORT statement. The nature of this workaround is to reduce the number of symbols that the compiler have to create, which exceeded the limitation and caused ICE. Every USE statement in an interface block opens up the module symbol file and reads all the symbols from it and creates an entity for each symbol in compiler. This is unnecessary when the module already has the same USE statement in the module scope. Instead, users can use IMPORT statement to make the module symbols accessible inside interface face blocks. With the change, the compiler would only read the module symbol file once and create one set of symbols where the old code reads the module symbol files as many times as the number of the USE statements in Interface blocks and create that many sets of duplicate symbols. Replacing those USE statements with IMPORT statements also shortens the compile time significantly. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Mar 3, 2021, at 13:43, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > The only change I can get working (i.e avoid compile errors) is to split petscvecmod.F90 into 2 source files - but I don't know if this will help with xlf.. > > My [partial] change is in branch balay/reorg-f90-for-xlf > > Satish > > On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: > >> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote: >> >>> Sure - once any change works locally [for gcc and xlf] >>> >>> When I try - I get a bunch of errors.. [yet to digest them.] >> >>>>>>> Can you please give the following source code workaround a try? >>>>>>> Since there is already "use petscvecdefdummy" at the module scope, one workaround might be to remove the unnecessary "use petscvecdefdummy" in vecnotequal and vecequals >>>>>>> and all similar procedures. >>>>>>> >>>>>>> For example, the test case has: >>>>>>> module petscvecdef >>>>>>> use petscvecdefdummy >>>>>>> ... >>>>>>> function vecnotequal(A,B) >>>>>>> use petscvecdefdummy >>>>>>> logical vecnotequal >>>>>>> type(tVec), intent(in) :: A,B >>>>>>> vecnotequal = (A%v .ne. B%v) >>>>>>> end function >> >> >> Ok - try this suggestion: >> >> diff --git a/src/vec/f90-mod/petscvecmod.F90 b/src/vec/f90-mod/petscvecmod.F90 >> index 0c447156b9..81968c7ca1 100644 >> --- a/src/vec/f90-mod/petscvecmod.F90 >> +++ b/src/vec/f90-mod/petscvecmod.F90 >> @@ -77,7 +77,6 @@ >> use petscvecdefdummy >> interface operator(.ne.) >> function vecnotequal(A,B) >> - use petscvecdefdummy >> logical vecnotequal >> type(tVec), intent(in) :: A,B >> end function >> >> >>>>>>> >> FC arch-linux-c-debug/obj/vec/f90-mod/petscvecmod.o >> /home/balay/petsc/src/vec/f90-mod/petscvecmod.F90:81:22: >> >> 81 | type(tVec), intent(in) :: A,B >> | 1 >> Error: Derived type ‘tvec’ at (1) is being used before it is defined >> /home/balay/petsc/include/../src/vec/f90-mod/ftn-auto-interfaces/petscis.h90:2:10: >> >> 2 | use petscvecdef >> | 1 >> Fatal Error: Cannot open module file ‘petscvecdef.mod’ for reading at (1): No such file or directory >> <<<<<< >> >> Satish

1 0

Re: [petsc-dev] Petsc "make test" have more failures for --with-openmp=1
by Barry Smith 15 Mar '21

15 Mar '21

I posted some information at the issue. IMHO it is likely a bug in one or more of hypre's smoothers that use OpenMP. We have never tested them before (and likely hypre has not tested all the combinations) and so would not have seen the bug. Hopefully they can just fix it. Barry I got the problem to occur with ex56 with 2 MPI ranks and 4 OpenMP threads, if I used less than 4 threads it did not generate an indefinite preconditioner. > On Mar 14, 2021, at 1:18 PM, Eric Chamberland <Eric.Chamberland(a)giref.ulaval.ca> wrote: > > Done: > > https://github.com/hypre-space/hypre/issues/303 <https://github.com/hypre-space/hypre/issues/303> > Maybe I will need some help about PETSc to answer their questions... > > Eric > > On 2021-03-14 3:44 a.m., Stefano Zampini wrote: >> Eric >> >> You should report these HYPRE issues upstream https://github.com/hypre-space/hypre/issues <https://github.com/hypre-space/hypre/issues> >> >> >>> On Mar 14, 2021, at 3:44 AM, Eric Chamberland <Eric.Chamberland(a)giref.ulaval.ca <mailto:[email protected]>> wrote: >>> >>> For us it clearly creates problems in real computations... >>> >>> I understand the need to have clean test for PETSc, but for me, it reveals that hypre isn't usable with more than one thread for now... >>> >>> Another solution: force single-threaded configuration for hypre until this is fixed? >>> >>> Eric >>> >>> On 2021-03-13 8:50 a.m., Pierre Jolivet wrote: >>>> -pc_hypre_boomeramg_relax_type_all Jacobi => >>>> Linear solve did not converge due to DIVERGED_INDEFINITE_PC iterations 3 >>>> -pc_hypre_boomeramg_relax_type_all l1scaled-Jacobi => >>>> OK, independently of the architecture it seems (Eric Docker image with 1 or 2 threads or my macOS), but contraction factor is higher >>>> Linear solve converged due to CONVERGED_RTOL iterations 8 >>>> Linear solve converged due to CONVERGED_RTOL iterations 24 >>>> Linear solve converged due to CONVERGED_RTOL iterations 26 >>>> v. currently >>>> Linear solve converged due to CONVERGED_RTOL iterations 7 >>>> Linear solve converged due to CONVERGED_RTOL iterations 9 >>>> Linear solve converged due to CONVERGED_RTOL iterations 10 >>>> >>>> Do we change this? Or should we force OMP_NUM_THREADS=1 for make test? >>>> >>>> Thanks, >>>> Pierre >>>> >>>>> On 13 Mar 2021, at 2:26 PM, Mark Adams <mfadams(a)lbl.gov <mailto:[email protected]>> wrote: >>>>> >>>>> Hypre uses a multiplicative smoother by default. It has a chebyshev smoother. That with a Jacobi PC should be thread invariant. >>>>> Mark >>>>> >>>>> On Sat, Mar 13, 2021 at 8:18 AM Pierre Jolivet <pierre(a)joliv.et <mailto:[email protected]>> wrote: >>>>> >>>>>> On 13 Mar 2021, at 9:17 AM, Pierre Jolivet <pierre(a)joliv.et <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hello Eric, >>>>>> I’ve made an “interesting” discovery, so I’ll put back the list in c/c. >>>>>> It appears the following snippet of code which uses Allreduce() + lambda function + MPI_IN_PLACE is: >>>>>> - Valgrind-clean with MPICH; >>>>>> - Valgrind-clean with OpenMPI 4.0.5; >>>>>> - not Valgrind-clean with OpenMPI 4.1.0. >>>>>> I’m not sure who is to blame here, I’ll need to look at the MPI specification for what is required by the implementors and users in that case. >>>>>> >>>>>> In the meantime, I’ll do the following: >>>>>> - update config/BuildSystem/config/packages/OpenMPI.py to use OpenMPI 4.1.0, see if any other error appears; >>>>>> - provide a hotfix to bypass the segfaults; >>>>> >>>>> I can confirm that splitting the single Allreduce with my own MPI_Op into two Allreduce with MAX and BAND fixes the segfaults with OpenMPI (*). >>>>> >>>>>> - look at the hypre issue and whether they should be deferred to the hypre team. >>>>> >>>>> I don’t know if there is something wrong in hypre threading or if it’s just a side effect of threading, but it seems that the number of threads has a drastic effect on the quality of the PC. >>>>> By default, it looks that there are two threads per process with your Docker image. >>>>> If I force OMP_NUM_THREADS=1, then I get the same convergence as in the output file. >>>>> >>>>> Thanks, >>>>> Pierre >>>>> >>>>> (*) https://gitlab.com/petsc/petsc/-/merge_requests/3712 <https://gitlab.com/petsc/petsc/-/merge_requests/3712> >>>>>> Thank you for the Docker files, they were really useful. >>>>>> If you want to avoid oversubscription failures, you can edit the file /opt/openmpi-4.1.0/etc/openmpi-default-hostfile and append the line: >>>>>> localhost slots=12 >>>>>> If you want to increase the timeout limit of PETSc test suite for each test, you can add the extra flag in your command line TIMEOUT=180 (default is 60, units are seconds). >>>>>> >>>>>> Thanks, I’ll ping you on GitLab when I’ve got something ready for you to try, >>>>>> Pierre >>>>>> >>>>>> <ompi.cxx> >>>>>> >>>>>>> On 12 Mar 2021, at 8:54 PM, Eric Chamberland <Eric.Chamberland(a)giref.ulaval.ca <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hi Pierre, >>>>>>> >>>>>>> I now have a docker container reproducing the problems here. >>>>>>> >>>>>>> Actually, if I look at snes_tutorials-ex12_quad_singular_hpddm it fails like this: >>>>>>> >>>>>>> not ok snes_tutorials-ex12_quad_singular_hpddm # Error code: 59 >>>>>>> # Initial guess >>>>>>> # L_2 Error: 0.00803099 >>>>>>> # Initial Residual >>>>>>> # L_2 Residual: 1.09057 >>>>>>> # Au - b = Au + F(0) >>>>>>> # Linear L_2 Residual: 1.09057 >>>>>>> # [d470c54ce086:14127] Read -1, expected 4096, errno = 1 >>>>>>> # [d470c54ce086:14128] Read -1, expected 4096, errno = 1 >>>>>>> # [d470c54ce086:14129] Read -1, expected 4096, errno = 1 >>>>>>> # [3]PETSC ERROR: ------------------------------------------------------------------------ >>>>>>> # [3]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range >>>>>>> # [3]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger >>>>>>> # [3]PETSC ERROR: or see https://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind <https://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind> >>>>>>> # [3]PETSC ERROR: or try http://valgrind.org <http://valgrind.org/> on GNU/linux and Apple Mac OS X to find memory corruption errors >>>>>>> # [3]PETSC ERROR: likely location of problem given in stack below >>>>>>> # [3]PETSC ERROR: --------------------- Stack Frames ------------------------------------ >>>>>>> # [3]PETSC ERROR: Note: The EXACT line numbers in the stack are not available, >>>>>>> # [3]PETSC ERROR: INSTEAD the line number of the start of the function >>>>>>> # [3]PETSC ERROR: is given. >>>>>>> # [3]PETSC ERROR: [3] buildTwo line 987 /opt/petsc-main/include/HPDDM_schwarz.hpp >>>>>>> # [3]PETSC ERROR: [3] next line 1130 /opt/petsc-main/include/HPDDM_schwarz.hpp >>>>>>> # [3]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- >>>>>>> # [3]PETSC ERROR: Signal received >>>>>>> # [3]PETSC ERROR: [0]PETSC ERROR: ------------------------------------------------------------------------ >>>>>>> >>>>>>> also ex12_quad_hpddm_reuse_baij fails with a lot more "Read -1, expected ..." which I don't know where they come from...? >>>>>>> >>>>>>> Hypre (like in diff-snes_tutorials-ex56_hypre) is also having DIVERGED_INDEFINITE_PC failures... >>>>>>> >>>>>>> Please see the 3 attached docker files: >>>>>>> >>>>>>> 1) fedora_mkl_and_devtools : the DockerFile which install fedore 33 with gnu compilers and MKL and everything to develop. >>>>>>> >>>>>>> 2) openmpi: the DockerFile to bluid OpenMPI >>>>>>> >>>>>>> 3) petsc: The las DockerFile that build/install and test PETSc >>>>>>> >>>>>>> I build the 3 like this: >>>>>>> >>>>>>> docker build -t fedora_mkl_and_devtools -f fedora_mkl_and_devtools . >>>>>>> >>>>>>> docker build -t openmpi -f openmpi . >>>>>>> >>>>>>> docker build -t petsc -f petsc . >>>>>>> >>>>>>> Disclaimer: I am not a docker expert, so I may do things that are not docker-stat-of-the-art but I am opened to suggestions... ;) >>>>>>> >>>>>>> I have just ran it on my portable (long) which have not enough cores, so many more tests failed (should force --oversubscribe but don't know how to). I will relaunch on my workstation in a few minutes. >>>>>>> >>>>>>> I will now test your branch! (sorry for the delay). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Eric >>>>>>> >>>>>>> On 2021-03-11 9:03 a.m., Eric Chamberland wrote: >>>>>>>> Hi Pierre, >>>>>>>> >>>>>>>> ok, that's interesting! >>>>>>>> >>>>>>>> I will try to build a docker image until tomorrow and give you the exact recipe to reproduce the bugs. >>>>>>>> >>>>>>>> Eric >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2021-03-11 2:46 a.m., Pierre Jolivet wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11 Mar 2021, at 6:16 AM, Barry Smith <bsmith(a)petsc.dev <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Eric, >>>>>>>>>> >>>>>>>>>> Sorry about not being more immediate. We still have this in our active email so you don't need to submit individual issues. We'll try to get to them as soon as we can. >>>>>>>>> >>>>>>>>> Indeed, I’m still trying to figure this out. >>>>>>>>> I realized that some of my configure flags were different than yours, e.g., no --with-memalign. >>>>>>>>> I’ve also added SuperLU_DIST to my installation. >>>>>>>>> Still, I can’t reproduce any issue. >>>>>>>>> I will continue looking into this, it appears I’m seeing some valgrind errors, but I don’t know if this is some side effect of OpenMPI not being valgrind-clean (last time I checked, there was no error with MPICH). >>>>>>>>> >>>>>>>>> Thank you for your patience, >>>>>>>>> Pierre >>>>>>>>> >>>>>>>>> /usr/bin/gmake -f gmakefile test test-fail=1 >>>>>>>>> Using MAKEFLAGS: test-fail=1 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex12_quad_hpddm_reuse_baij.counts >>>>>>>>> ok snes_tutorials-ex12_quad_hpddm_reuse_baij >>>>>>>>> ok diff-snes_tutorials-ex12_quad_hpddm_reuse_baij >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tests-ex33_superlu_dist_2.counts >>>>>>>>> ok ksp_ksp_tests-ex33_superlu_dist_2 >>>>>>>>> ok diff-ksp_ksp_tests-ex33_superlu_dist_2 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tests-ex49_superlu_dist.counts >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-0_conv-0 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-0_conv-0 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-0_conv-1 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-0_conv-1 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-1_conv-0 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-1_conv-0 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-1_conv-1 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-1herm-1_conv-1 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-0_conv-0 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-0_conv-0 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-0_conv-1 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-0_conv-1 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-1_conv-0 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-1_conv-0 >>>>>>>>> ok ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-1_conv-1 >>>>>>>>> ok diff-ksp_ksp_tests-ex49_superlu_dist+nsize-4herm-1_conv-1 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex50_tut_2.counts >>>>>>>>> ok ksp_ksp_tutorials-ex50_tut_2 >>>>>>>>> ok diff-ksp_ksp_tutorials-ex50_tut_2 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tests-ex33_superlu_dist.counts >>>>>>>>> ok ksp_ksp_tests-ex33_superlu_dist >>>>>>>>> ok diff-ksp_ksp_tests-ex33_superlu_dist >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex56_hypre.counts >>>>>>>>> ok snes_tutorials-ex56_hypre >>>>>>>>> ok diff-snes_tutorials-ex56_hypre >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex56_2.counts >>>>>>>>> ok ksp_ksp_tutorials-ex56_2 >>>>>>>>> ok diff-ksp_ksp_tutorials-ex56_2 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex17_3d_q3_trig_elas.counts >>>>>>>>> ok snes_tutorials-ex17_3d_q3_trig_elas >>>>>>>>> ok diff-snes_tutorials-ex17_3d_q3_trig_elas >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex12_quad_hpddm_reuse_threshold_baij.counts >>>>>>>>> ok snes_tutorials-ex12_quad_hpddm_reuse_threshold_baij >>>>>>>>> ok diff-snes_tutorials-ex12_quad_hpddm_reuse_threshold_baij >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5_superlu_dist_3.counts >>>>>>>>> not ok ksp_ksp_tutorials-ex5_superlu_dist_3 # Error code: 1 >>>>>>>>> # srun: error: Unable to create step for job 1426755: More processors requested than permitted >>>>>>>>> ok ksp_ksp_tutorials-ex5_superlu_dist_3 # SKIP Command failed so no diff >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5f_superlu_dist.counts >>>>>>>>> ok ksp_ksp_tutorials-ex5f_superlu_dist # SKIP Fortran required for this test >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex12_tri_parmetis_hpddm_baij.counts >>>>>>>>> ok snes_tutorials-ex12_tri_parmetis_hpddm_baij >>>>>>>>> ok diff-snes_tutorials-ex12_tri_parmetis_hpddm_baij >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex19_tut_3.counts >>>>>>>>> ok snes_tutorials-ex19_tut_3 >>>>>>>>> ok diff-snes_tutorials-ex19_tut_3 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex17_3d_q3_trig_vlap.counts >>>>>>>>> ok snes_tutorials-ex17_3d_q3_trig_vlap >>>>>>>>> ok diff-snes_tutorials-ex17_3d_q3_trig_vlap >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5f_superlu_dist_3.counts >>>>>>>>> ok ksp_ksp_tutorials-ex5f_superlu_dist_3 # SKIP Fortran required for this test >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex19_superlu_dist.counts >>>>>>>>> ok snes_tutorials-ex19_superlu_dist >>>>>>>>> ok diff-snes_tutorials-ex19_superlu_dist >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex56_attach_mat_nearnullspace-1_bddc_approx_hypre.counts >>>>>>>>> ok snes_tutorials-ex56_attach_mat_nearnullspace-1_bddc_approx_hypre >>>>>>>>> ok diff-snes_tutorials-ex56_attach_mat_nearnullspace-1_bddc_approx_hypre >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex49_hypre_nullspace.counts >>>>>>>>> ok ksp_ksp_tutorials-ex49_hypre_nullspace >>>>>>>>> ok diff-ksp_ksp_tutorials-ex49_hypre_nullspace >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex19_superlu_dist_2.counts >>>>>>>>> ok snes_tutorials-ex19_superlu_dist_2 >>>>>>>>> ok diff-snes_tutorials-ex19_superlu_dist_2 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5_superlu_dist_2.counts >>>>>>>>> not ok ksp_ksp_tutorials-ex5_superlu_dist_2 # Error code: 1 >>>>>>>>> # srun: error: Unable to create step for job 1426755: More processors requested than permitted >>>>>>>>> ok ksp_ksp_tutorials-ex5_superlu_dist_2 # SKIP Command failed so no diff >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/snes_tutorials-ex56_attach_mat_nearnullspace-0_bddc_approx_hypre.counts >>>>>>>>> ok snes_tutorials-ex56_attach_mat_nearnullspace-0_bddc_approx_hypre >>>>>>>>> ok diff-snes_tutorials-ex56_attach_mat_nearnullspace-0_bddc_approx_hypre >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex64_1.counts >>>>>>>>> ok ksp_ksp_tutorials-ex64_1 >>>>>>>>> ok diff-ksp_ksp_tutorials-ex64_1 >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5_superlu_dist.counts >>>>>>>>> not ok ksp_ksp_tutorials-ex5_superlu_dist # Error code: 1 >>>>>>>>> # srun: error: Unable to create step for job 1426755: More processors requested than permitted >>>>>>>>> ok ksp_ksp_tutorials-ex5_superlu_dist # SKIP Command failed so no diff >>>>>>>>> TEST arch-linux2-c-opt-ompi/tests/counts/ksp_ksp_tutorials-ex5f_superlu_dist_2.counts >>>>>>>>> ok ksp_ksp_tutorials-ex5f_superlu_dist_2 # SKIP Fortran required for this test >>>>>>>>> >>>>>>>>>> Barry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 10, 2021, at 11:03 PM, Eric Chamberland <Eric.Chamberland(a)giref.ulaval.ca <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> Barry, >>>>>>>>>>> >>>>>>>>>>> to get a some follow up on --with-openmp=1 failures, shall I open gitlab issues for: >>>>>>>>>>> >>>>>>>>>>> a) all hypre failures giving DIVERGED_INDEFINITE_PC >>>>>>>>>>> >>>>>>>>>>> b) all superlu_dist failures giving different results with initia and "Exceeded timeout limit of 60 s" >>>>>>>>>>> >>>>>>>>>>> c) hpddm failures "free(): invalid next size (fast)" and "Segmentation Violation" >>>>>>>>>>> >>>>>>>>>>> d) all tao's "Exceeded timeout limit of 60 s" >>>>>>>>>>> >>>>>>>>>>> I don't see how I could do all these debugging by myself... >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Eric >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Eric Chamberland, ing., M. Ing >>>>>>>> Professionnel de recherche >>>>>>>> GIREF/Université Laval >>>>>>>> (418) 656-2131 poste 41 22 42 >>>>>>> -- >>>>>>> Eric Chamberland, ing., M. Ing >>>>>>> Professionnel de recherche >>>>>>> GIREF/Université Laval >>>>>>> (418) 656-2131 poste 41 22 42 >>>>>>> <fedora_mkl_and_devtools.txt><openmpi.txt><petsc.txt> >>>>>> >>>>> >>>> >>> -- >>> Eric Chamberland, ing., M. Ing >>> Professionnel de recherche >>> GIREF/Université Laval >>> (418) 656-2131 poste 41 22 42 >> > -- > Eric Chamberland, ing., M. Ing > Professionnel de recherche > GIREF/Université Laval > (418) 656-2131 poste 41 22 42

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Satish Balay 15 Mar '21

15 Mar '21

On Mon, 15 Mar 2021, Lisandro Dalcin wrote: > On Mon, 15 Mar 2021 at 18:26, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > But epydoc can be installed with python3. > > > Maybe. Have you tried to actually run it after installation? :-) I have not (yet). > > > > So this is more of petsc4py code that uses epydoc - than epydoc code? > > > > > I did not understand your question. Epidoc is just an external tool > required to build a piece of the documentation. It only runs on Python 2. > And to build documentation, it uses introspection, so whatever you want to > document has to be installed alongside with epydoc such that epidoc is able > to "import petsc4py.PETSc" and proceed to generate the API reference by > traversing classes, methods, functions, etc. > > > > > I have not found a nice replacement for epydoc-generated documentation. > > > If Python 2 is an annoyance, then just remove, comment-out anything > > related > > > to epydoc in "makefile" > > > > Well I can work around it. [by installing both python2 and python3 > > versions of epydoc via pip] > > > > Don't bother about installing Epydoc in Python 3, it does not work. You > only need it in Python 2, also install petsc4py, run "make install py=2" > (petsc4py will go to ~/.local) Ah - its about docutils. >>>>> checkdocutils: @${PYTHON} -c $$'try:\n import docutils\nexcept:\n print("Run python -m pip install docutils and then try this command again");exit(1)' @${PYTHON2} -c $$'try:\n import docutils\nexcept:\n print("Run python2 -m pip install docutils or pip2 install docutils or [sudo] easy_install docutils and then try the command again");exit(1)' @${PYTHON2} -c $$'try:\n import epydoc\nexcept:\n print("Run python2 -m pip install epydoc or pip2 install epydoc or [sudo] easy_install epydoc and then try the command again");exit(1)' <<<<< I guess I should do 'make PYTHON=python2 PYTHON=python2' to prevent these checks from running with python3 [and prompting me to install these packages with python3] > > > > > However its not clear to me where the python2 requirement is coming > > from - and if things can be unified using python3 > > > > I hope it is clear now. A piece of the documentation requires epydoc, which > in turns only works on Python 2. > > > > > > > and run "make sdist". > > > > Ah - ok. Will check this to see if I can generate the tarball in sync > > with petsc tarball. What source files need updating for > > release/version info? > > > > > CHANGES.rst (add entry for new release) Can we add a ref to src/docs/website/documentation/changes/index.html from here so that this doesn't need updating? > src/__init__.py (update __version__ to "3.15.0" ) I can update this release version (3.15,3.16 etc) manually for every release in sync with petsc - and automate the patchlevel [again in sync with petsc] One issue: what version do we use here for development snapshot? [Ideally we would somehow automate this to use petscversion.h - that works from git] > > > $ git grep "PETSc Users Manual" > DESCRIPTION.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. > docs/index.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. > docs/source/citing.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, > 2020. > docs/source/overview.rst: *PETSc Users Manual*, ANL-95/11 - Revision > 3.14, 2020. Ok - I can add these to the list that I update manually (at 3.15,13.16 etc versions) > > > > > But this way the tarball will miss the API reference. > > > > > PS: All this could be converted to a script that installs petsc4py and > > > epydoc in a Python 2 virtual environment, and next users another venv for > > > the Python 3 Sphinx stuff. > > > > One issue: Fedora-33 does not have 'python2-pip' anymore. I was able > > to manually install it. However this might become an issue for others > > who want to build docs [even if we automate the docs build to > > install/use pyton2-venv] > > > > > Yes, Satish I know. The long term solution is to get rid of Epydoc and > replace it for something else, most likely Sphinx-based. Yes - I think this is the long term goal. > If generating this epydoc stuff is too much of an annoyance for you, just > kill it for good and let's forget about it. I'm trying to figure out the appropriate way to integrate this into the petsc tarball build process [that works on my laptop]. I think I have the relevant info now. Making petsc4py doc-gen more portable and more integrated into petsc doc gen process can be improved separately [later] Satish

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Lisandro Dalcin 15 Mar '21

15 Mar '21

On Mon, 15 Mar 2021 at 18:26, Satish Balay <balay(a)mcs.anl.gov> wrote: > > But epydoc can be installed with python3. Maybe. Have you tried to actually run it after installation? :-) > So this is more of petsc4py code that uses epydoc - than epydoc code? > > I did not understand your question. Epidoc is just an external tool required to build a piece of the documentation. It only runs on Python 2. And to build documentation, it uses introspection, so whatever you want to document has to be installed alongside with epydoc such that epidoc is able to "import petsc4py.PETSc" and proceed to generate the API reference by traversing classes, methods, functions, etc. > > I have not found a nice replacement for epydoc-generated documentation. > > If Python 2 is an annoyance, then just remove, comment-out anything > related > > to epydoc in "makefile" > > Well I can work around it. [by installing both python2 and python3 > versions of epydoc via pip] > Don't bother about installing Epydoc in Python 3, it does not work. You only need it in Python 2, also install petsc4py, run "make install py=2" (petsc4py will go to ~/.local) > > However its not clear to me where the python2 requirement is coming > from - and if things can be unified using python3 > I hope it is clear now. A piece of the documentation requires epydoc, which in turns only works on Python 2. > > > and run "make sdist". > > Ah - ok. Will check this to see if I can generate the tarball in sync > with petsc tarball. What source files need updating for > release/version info? > > CHANGES.rst (add entry for new release) src/__init__.py (update __version__ to "3.15.0" ) $ git grep "PETSc Users Manual" DESCRIPTION.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. docs/index.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. docs/source/citing.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. docs/source/overview.rst: *PETSc Users Manual*, ANL-95/11 - Revision 3.14, 2020. > > But this way the tarball will miss the API reference. > > > PS: All this could be converted to a script that installs petsc4py and > > epydoc in a Python 2 virtual environment, and next users another venv for > > the Python 3 Sphinx stuff. > > One issue: Fedora-33 does not have 'python2-pip' anymore. I was able > to manually install it. However this might become an issue for others > who want to build docs [even if we automate the docs build to > install/use pyton2-venv] > > Yes, Satish I know. The long term solution is to get rid of Epydoc and replace it for something else, most likely Sphinx-based. If generating this epydoc stuff is too much of an annoyance for you, just kill it for good and let's forget about it. -- 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] integrate petsc4py tarball generation with petsc tarball generation
by Patrick Sanan 15 Mar '21

15 Mar '21

I tried earlier but I don't know what I'm doing, so was hoping Lisandro would help. If it's worth anything this is what I did: # set PETSC_DIR and PETSC_ARCH for minimal docs build as used for Sphinx (basically just c2html and sowing). # had to remember to actually build the library or you get a link error with -lpetsc cd src/binding/petsc4py # I have all the requisite packages in my base Python 3.7 conda environment (I think), including epydoc make PYTHON=python PYTHON2=python PYTHON3=python docs /Users/patrick/opt/miniconda3/bin/rst2html.py --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./LICENSE.rst > docs/LICENSE.html /Users/patrick/opt/miniconda3/bin/rst2html.py --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./CHANGES.rst > docs/CHANGES.html /Users/patrick/opt/miniconda3/bin/rst2html.py --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses docs/index.rst > docs/index.html mkdir -p build/doctrees docs/usrman sphinx-build -b html -d build/doctrees \ docs/source docs/usrman Sphinx v2.4.4 in Verwendung loading pickled environment... erledigt building [mo]: targets for 0 po files that are out of date building [html]: targets for 0 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found no targets are out of date. build abgeschlossen. The HTML pages are in docs/usrman. rm -f docs/usrman/.buildinfo python setup.py build_src running build_src mkdir -p docs/apiref env CFLAGS=-O0 python setup.py -q build --build-lib build/lib.py2 env PYTHONPATH=$PWD/build/lib.py2 python -c 'import petsc4py.PETSc' Traceback (most recent call last): File "<string>", line 1, in <module> File "/Users/patrick/code/petsc-doc/src/binding/petsc4py/build/lib.py2/petsc4py/PETSc.py", line 3, in <module> PETSc = ImportPETSc(ARCH) File "/Users/patrick/code/petsc-doc/src/binding/petsc4py/build/lib.py2/petsc4py/lib/__init__.py", line 29, in ImportPETSc return Import('petsc4py', 'PETSc', path, arch) File "/Users/patrick/code/petsc-doc/src/binding/petsc4py/build/lib.py2/petsc4py/lib/__init__.py", line 73, in Import module = import_module(pkg, name, path, arch) File "/Users/patrick/code/petsc-doc/src/binding/petsc4py/build/lib.py2/petsc4py/lib/__init__.py", line 58, in import_module with f: return imp.load_module(fullname, f, fn, info) File "/Users/patrick/opt/miniconda3/lib/python3.7/imp.py", line 242, in load_module return load_dynamic(name, filename, file) File "/Users/patrick/opt/miniconda3/lib/python3.7/imp.py", line 342, in load_dynamic return _load(spec) ImportError: dlopen(/Users/patrick/code/petsc-doc/src/binding/petsc4py/build/lib.py2/petsc4py/lib/arch-classic-docs/PETSc.cpython-37m-darwin.so, 2): Symbol not found: _dasum Referenced from: /Users/patrick/code/petsc-doc/arch-classic-docs/lib/libpetsc.3.014.dylib Expected in: flat namespace in /Users/patrick/code/petsc-doc/arch-classic-docs/lib/libpetsc.3.014.dylib make: *** [epydoc-html] Error 1 > Am 15.03.2021 um 16:59 schrieb Barry Smith <bsmith(a)petsc.dev>: > > > Well someone tried importing epydoc for python3 and it did not generate an error, did they try generating the petsc4py docs with it. That would tell you if it works? > > Yes, we do want to be able to build all the PETSc docs together in a portable way. > >> On Mar 15, 2021, at 10:56 AM, Patrick Sanan <patrick.sanan(a)gmail.com <mailto:[email protected]>> wrote: >> >> >> >>> Am 15.03.2021 um 16:26 schrieb Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>>: >>> >>> On Mon, 15 Mar 2021, Lisandro Dalcin wrote: >>> >>>> On Mon, 15 Mar 2021 at 07:06, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >>>> >>>>> Lisandro, >>>>> >>>>> For the upcoming release its best to update lib/petsc/bin/maint/builddist >>>>> to also build petsc4py tarball in sync with petsc tarball. >>>>> >>>>> What is the current process to generate petsc4py tarball? >>>>> >>>>> >>>>> >>>>> BTW: I stumbled into a couple of issues with building petsc4py docs >>>>> >>>>> 1. the docs build process requires petsc library to be built? >>>>> >>>>> >>>> >>>> >>>> >>>>>>>>> >>>>> python setup.py build_src >>>>> running build_src >>>>> cythonizing 'petsc4py.PETSc.pyx' -> 'petsc4py.PETSc.c' >>>>> cythonizing 'libpetsc4py/libpetsc4py.pyx' -> 'libpetsc4py/libpetsc4py.c' >>>>> mkdir -p docs/apiref >>>>> env CFLAGS=-O0 python2 setup.py -q build --build-lib build/lib.py2 >>>>> /usr/bin/ld: cannot find -lpetsc >>>>> collect2: error: ld returned 1 exit status >>>>> error: command 'gcc' failed with exit status 1 >>>>> make[2]: *** [makefile:110: epydoc-html] Error 1 >>>>> gmake[1]: [makefile:422: sphinx-docs-all] Error 2 (ignored) >>>>> <<< >>>>> >>>>> 2. Any particular reason it needs python2? I see it requires >>>>> docutils,epydoc - but I see python3 is able to install them. >>>>> >>>>> >>>> It requires petsc4py to be installed in Python 2, such that epydoc can >>>> build the API reference. >>> >>> But epydoc can be installed with python3. So this is more of petsc4py code that uses epydoc - than epydoc code? >>> >>>> I have not found a nice replacement for epydoc-generated documentation. >>>> If Python 2 is an annoyance, then just remove, comment-out anything related >>>> to epydoc in "makefile" >>> >>> Well I can work around it. [by installing both python2 and python3 versions of epydoc via pip] >>> >>> However its not clear to me where the python2 requirement is coming >>> from - and if things can be unified using python3 >>> >>> A related issue: I think Patrick is working on migrating some of the >>> petsc4py docs to sphynx. And curently sphynx is installed in python3 >>> virt-env [so now we need it for both python3 for petsc side, and >>> python2 for petsc4py side] >> >> I haven't dug into the petsc4py docs yet, but I was very much hoping that we could at least make all the docs build at once and be deployed to the same URL, even if for now they are building with an assortment of tools. (We could include the petsc4py docs, for now, as we're doing with the HTML man pages and sources from c2html, specifying them as "extra html" with Sphinx) . As Satish says, it'd be nice to do this with the same Python environment we use to build the Sphinx docs - I would naively hope/assume that since epydoc exists for python3 and petsc4py works with python3, it would be possible. >> >>> >>>> and run "make sdist". >>> >>> Ah - ok. Will check this to see if I can generate the tarball in sync >>> with petsc tarball. What source files need updating for >>> release/version info? >>> >>>> But this way the tarball will miss the API reference. >>> >>>> PS: All this could be converted to a script that installs petsc4py and >>>> epydoc in a Python 2 virtual environment, and next users another venv for >>>> the Python 3 Sphinx stuff. >>> >>> One issue: Fedora-33 does not have 'python2-pip' anymore. I was able >>> to manually install it. However this might become an issue for others >>> who want to build docs [even if we automate the docs build to >>> install/use pyton2-venv] >>> >>> Satish >> >

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Satish Balay 15 Mar '21

15 Mar '21

Ok - I can look at updating builddist script to build PETSc and PETSc4py [with python2 - and prerequistes installed] before attempting to build python docs [and petsc4py tarball] Satish On Mon, 15 Mar 2021, Barry Smith wrote: > > Satish, > > I think some of the python documentation tools used, epydoc, require that the python package it is documenting exists and is run-able since it probably uses the self-documenting features of Python. This makes perfect sense for Python. A python package cannot provide help messages unless you can import it. > > Barry > > Maybe it could be rigged that petsc4py would allow itself to be imported and produce help messages without loading the PETSc libraries, this would require digging around a bit in how petsc4py loads the PETSc dynamic library. > > > > > On Mar 15, 2021, at 10:42 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > > > On Mon, 15 Mar 2021, Satish Balay wrote: > >> > >>> and run "make sdist". > >> > >> Ah - ok. Will check this to see if I can generate the tarball in sync > >> with petsc tarball. What source files need updating for > >> release/version info? > > > > Is it required to build PETSc library - to build petsc4py tarball? > > > > Satish > > > > ----- > > > > balay@sb /home/balay/tmp/petsc/src/binding/petsc4py (main=) > > $ make sdist > > python setup.py build_src > > running build_src > > cythonizing 'petsc4py.PETSc.pyx' -> 'petsc4py.PETSc.c' > > cythonizing 'libpetsc4py/libpetsc4py.pyx' -> 'libpetsc4py/libpetsc4py.c' > > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./LICENSE.rst > docs/LICENSE.html > > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./CHANGES.rst > docs/CHANGES.html > > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses docs/index.rst > docs/index.html > > mkdir -p build/doctrees docs/usrman > > sphinx-build -b html -d build/doctrees \ > > docs/source docs/usrman > > Running Sphinx v3.2.1 > > building [mo]: targets for 0 po files that are out of date > > building [html]: targets for 6 source files that are out of date > > updating environment: [new config] 6 added, 0 changed, 0 removed > > reading sources... [100%] tutorial > > looking for now-outdated files... none found > > pickling environment... done > > checking consistency... /home/balay/tmp/petsc/src/binding/petsc4py/docs/source/manual.rst: WARNING: document isn't included in any toctree > > done > > preparing documents... done > > writing output... [100%] tutorial > > generating indices... genindexdone > > writing additional pages... searchdone > > copying static files... ... done > > copying extra files... done > > dumping search index in English (code: en)... done > > dumping object inventory... done > > build succeeded, 1 warning. > > > > The HTML pages are in docs/usrman. > > rm -f docs/usrman/.buildinfo > > mkdir -p docs/apiref > > env CFLAGS=-O0 python2 setup.py -q build --build-lib build/lib.py2 > > /usr/bin/ld: cannot find -lpetsc > > collect2: error: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > make: *** [makefile:110: epydoc-html] Error 1 >

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Barry Smith 15 Mar '21

15 Mar '21

Well someone tried importing epydoc for python3 and it did not generate an error, did they try generating the petsc4py docs with it. That would tell you if it works? Yes, we do want to be able to build all the PETSc docs together in a portable way. > On Mar 15, 2021, at 10:56 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > > >> Am 15.03.2021 um 16:26 schrieb Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>>: >> >> On Mon, 15 Mar 2021, Lisandro Dalcin wrote: >> >>> On Mon, 15 Mar 2021 at 07:06, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >>> >>>> Lisandro, >>>> >>>> For the upcoming release its best to update lib/petsc/bin/maint/builddist >>>> to also build petsc4py tarball in sync with petsc tarball. >>>> >>>> What is the current process to generate petsc4py tarball? >>>> >>>> >>>> >>>> BTW: I stumbled into a couple of issues with building petsc4py docs >>>> >>>> 1. the docs build process requires petsc library to be built? >>>> >>>> >>> >>> >>> >>>>>>>> >>>> python setup.py build_src >>>> running build_src >>>> cythonizing 'petsc4py.PETSc.pyx' -> 'petsc4py.PETSc.c' >>>> cythonizing 'libpetsc4py/libpetsc4py.pyx' -> 'libpetsc4py/libpetsc4py.c' >>>> mkdir -p docs/apiref >>>> env CFLAGS=-O0 python2 setup.py -q build --build-lib build/lib.py2 >>>> /usr/bin/ld: cannot find -lpetsc >>>> collect2: error: ld returned 1 exit status >>>> error: command 'gcc' failed with exit status 1 >>>> make[2]: *** [makefile:110: epydoc-html] Error 1 >>>> gmake[1]: [makefile:422: sphinx-docs-all] Error 2 (ignored) >>>> <<< >>>> >>>> 2. Any particular reason it needs python2? I see it requires >>>> docutils,epydoc - but I see python3 is able to install them. >>>> >>>> >>> It requires petsc4py to be installed in Python 2, such that epydoc can >>> build the API reference. >> >> But epydoc can be installed with python3. So this is more of petsc4py code that uses epydoc - than epydoc code? >> >>> I have not found a nice replacement for epydoc-generated documentation. >>> If Python 2 is an annoyance, then just remove, comment-out anything related >>> to epydoc in "makefile" >> >> Well I can work around it. [by installing both python2 and python3 versions of epydoc via pip] >> >> However its not clear to me where the python2 requirement is coming >> from - and if things can be unified using python3 >> >> A related issue: I think Patrick is working on migrating some of the >> petsc4py docs to sphynx. And curently sphynx is installed in python3 >> virt-env [so now we need it for both python3 for petsc side, and >> python2 for petsc4py side] > > I haven't dug into the petsc4py docs yet, but I was very much hoping that we could at least make all the docs build at once and be deployed to the same URL, even if for now they are building with an assortment of tools. (We could include the petsc4py docs, for now, as we're doing with the HTML man pages and sources from c2html, specifying them as "extra html" with Sphinx) . As Satish says, it'd be nice to do this with the same Python environment we use to build the Sphinx docs - I would naively hope/assume that since epydoc exists for python3 and petsc4py works with python3, it would be possible. > >> >>> and run "make sdist". >> >> Ah - ok. Will check this to see if I can generate the tarball in sync >> with petsc tarball. What source files need updating for >> release/version info? >> >>> But this way the tarball will miss the API reference. >> >>> PS: All this could be converted to a script that installs petsc4py and >>> epydoc in a Python 2 virtual environment, and next users another venv for >>> the Python 3 Sphinx stuff. >> >> One issue: Fedora-33 does not have 'python2-pip' anymore. I was able >> to manually install it. However this might become an issue for others >> who want to build docs [even if we automate the docs build to >> install/use pyton2-venv] >> >> Satish >

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Barry Smith 15 Mar '21

15 Mar '21

Satish, I think some of the python documentation tools used, epydoc, require that the python package it is documenting exists and is run-able since it probably uses the self-documenting features of Python. This makes perfect sense for Python. A python package cannot provide help messages unless you can import it. Barry Maybe it could be rigged that petsc4py would allow itself to be imported and produce help messages without loading the PETSc libraries, this would require digging around a bit in how petsc4py loads the PETSc dynamic library. > On Mar 15, 2021, at 10:42 AM, Satish Balay via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > On Mon, 15 Mar 2021, Satish Balay wrote: >> >>> and run "make sdist". >> >> Ah - ok. Will check this to see if I can generate the tarball in sync >> with petsc tarball. What source files need updating for >> release/version info? > > Is it required to build PETSc library - to build petsc4py tarball? > > Satish > > ----- > > balay@sb /home/balay/tmp/petsc/src/binding/petsc4py (main=) > $ make sdist > python setup.py build_src > running build_src > cythonizing 'petsc4py.PETSc.pyx' -> 'petsc4py.PETSc.c' > cythonizing 'libpetsc4py/libpetsc4py.pyx' -> 'libpetsc4py/libpetsc4py.c' > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./LICENSE.rst > docs/LICENSE.html > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses ./CHANGES.rst > docs/CHANGES.html > /usr/bin/rst2html --input-encoding=utf-8 --no-compact-lists --cloak-email-addresses docs/index.rst > docs/index.html > mkdir -p build/doctrees docs/usrman > sphinx-build -b html -d build/doctrees \ > docs/source docs/usrman > Running Sphinx v3.2.1 > building [mo]: targets for 0 po files that are out of date > building [html]: targets for 6 source files that are out of date > updating environment: [new config] 6 added, 0 changed, 0 removed > reading sources... [100%] tutorial > looking for now-outdated files... none found > pickling environment... done > checking consistency... /home/balay/tmp/petsc/src/binding/petsc4py/docs/source/manual.rst: WARNING: document isn't included in any toctree > done > preparing documents... done > writing output... [100%] tutorial > generating indices... genindexdone > writing additional pages... searchdone > copying static files... ... done > copying extra files... done > dumping search index in English (code: en)... done > dumping object inventory... done > build succeeded, 1 warning. > > The HTML pages are in docs/usrman. > rm -f docs/usrman/.buildinfo > mkdir -p docs/apiref > env CFLAGS=-O0 python2 setup.py -q build --build-lib build/lib.py2 > /usr/bin/ld: cannot find -lpetsc > collect2: error: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > make: *** [makefile:110: epydoc-html] Error 1

1 0

Re: [petsc-dev] integrate petsc4py tarball generation with petsc tarball generation
by Patrick Sanan 15 Mar '21

15 Mar '21

> Am 15.03.2021 um 16:26 schrieb Satish Balay <balay(a)mcs.anl.gov>: > > On Mon, 15 Mar 2021, Lisandro Dalcin wrote: > >> On Mon, 15 Mar 2021 at 07:06, Satish Balay <balay(a)mcs.anl.gov> wrote: >> >>> Lisandro, >>> >>> For the upcoming release its best to update lib/petsc/bin/maint/builddist >>> to also build petsc4py tarball in sync with petsc tarball. >>> >>> What is the current process to generate petsc4py tarball? >>> >>> >>> >>> BTW: I stumbled into a couple of issues with building petsc4py docs >>> >>> 1. the docs build process requires petsc library to be built? >>> >>> >> >> >> >>>>>>> >>> python setup.py build_src >>> running build_src >>> cythonizing 'petsc4py.PETSc.pyx' -> 'petsc4py.PETSc.c' >>> cythonizing 'libpetsc4py/libpetsc4py.pyx' -> 'libpetsc4py/libpetsc4py.c' >>> mkdir -p docs/apiref >>> env CFLAGS=-O0 python2 setup.py -q build --build-lib build/lib.py2 >>> /usr/bin/ld: cannot find -lpetsc >>> collect2: error: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >>> make[2]: *** [makefile:110: epydoc-html] Error 1 >>> gmake[1]: [makefile:422: sphinx-docs-all] Error 2 (ignored) >>> <<< >>> >>> 2. Any particular reason it needs python2? I see it requires >>> docutils,epydoc - but I see python3 is able to install them. >>> >>> >> It requires petsc4py to be installed in Python 2, such that epydoc can >> build the API reference. > > But epydoc can be installed with python3. So this is more of petsc4py code that uses epydoc - than epydoc code? > >> I have not found a nice replacement for epydoc-generated documentation. >> If Python 2 is an annoyance, then just remove, comment-out anything related >> to epydoc in "makefile" > > Well I can work around it. [by installing both python2 and python3 versions of epydoc via pip] > > However its not clear to me where the python2 requirement is coming > from - and if things can be unified using python3 > > A related issue: I think Patrick is working on migrating some of the > petsc4py docs to sphynx. And curently sphynx is installed in python3 > virt-env [so now we need it for both python3 for petsc side, and > python2 for petsc4py side] I haven't dug into the petsc4py docs yet, but I was very much hoping that we could at least make all the docs build at once and be deployed to the same URL, even if for now they are building with an assortment of tools. (We could include the petsc4py docs, for now, as we're doing with the HTML man pages and sources from c2html, specifying them as "extra html" with Sphinx) . As Satish says, it'd be nice to do this with the same Python environment we use to build the Sphinx docs - I would naively hope/assume that since epydoc exists for python3 and petsc4py works with python3, it would be possible. > >> and run "make sdist". > > Ah - ok. Will check this to see if I can generate the tarball in sync > with petsc tarball. What source files need updating for > release/version info? > >> But this way the tarball will miss the API reference. > >> PS: All this could be converted to a script that installs petsc4py and >> epydoc in a Python 2 virtual environment, and next users another venv for >> the Python 3 Sphinx stuff. > > One issue: Fedora-33 does not have 'python2-pip' anymore. I was able > to manually install it. However this might become an issue for others > who want to build docs [even if we automate the docs build to > install/use pyton2-venv] > > Satish

1 0