April 2018 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Error in MatGetDiagonal_Shell?
by Smith, Barry F. 30 Apr '18

30 Apr '18

https://bitbucket.org/petsc/petsc/pull-requests/951/barry-fix-matgetdiagona… > On Apr 30, 2018, at 12:38 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > >> On Apr 30, 2018, at 3:14 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: >> >> >> I don't understand >> >> The code has >> >> ierr = MatGetDiagonal(A,W2);CHKERRQ(ierr); >> ierr = VecView(W2,viewer);CHKERRQ(ierr); >> >> the output from this VecView seems to match the diagonal of the matrix printed earlier. >> >>> On Apr 29, 2018, at 10:02 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: >>> >>> By looking at src/mat/examples/tests/output/ex88_1.out, it seems that the output of MatGetDiagonal is wrong for MATSHELL. >>> >>> it should be >>> 2.96782e+08 >>> 1.41731e+09 >>> and not (as computed) >>> 1.10918e+08 >>> 2.06459e+08 >> >> What do you mean "as computed"? The output file does not contain >>> 1.10918e+08 >>> 2.06459e+08 >> anywhere. >> >> Are you modifying the example and running it again to get the incorrect value? > > Yes, my bad. I did not explain it correctly > From maint, if you just run ex88 you will get the incorrect output, which is not caught in the nightlyies because floating point values are completely ignored. > > [szampini@localhost tests]$ ./ex88 > Matrix of type: shell > Mat Object: 1 MPI processes > type: seqdense > 2.9678190300000000e+08 3.9288008100000000e+08 > 6.1374683500000000e+08 1.4173141580000000e+09 > Vec Object: 1 MPI processes > type: seq > 3.92973e+19 > 8.54197e+19 > Vec Object: 1 MPI processes > type: seq > 1.10918e+08 > 2.06459e+08 > MatDiagonalSet not tested on MATSHELL > …. > >> >> Barry >> >>> >>> -- >>> Stefano >> >

1 0

Re: [petsc-dev] Error in MatGetDiagonal_Shell?
by Matthew Knepley 30 Apr '18

30 Apr '18

On Mon, Apr 30, 2018 at 1:38 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > > On Apr 30, 2018, at 3:14 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > > > > I don't understand > > > > The code has > > > > ierr = MatGetDiagonal(A,W2);CHKERRQ(ierr); > > ierr = VecView(W2,viewer);CHKERRQ(ierr); > > > > the output from this VecView seems to match the diagonal of the matrix > printed earlier. > > > >> On Apr 29, 2018, at 10:02 AM, Stefano Zampini < > stefano.zampini(a)gmail.com> wrote: > >> > >> By looking at src/mat/examples/tests/output/ex88_1.out, it seems that > the output of MatGetDiagonal is wrong for MATSHELL. > >> > >> it should be > >> 2.96782e+08 > >> 1.41731e+09 > >> and not (as computed) > >> 1.10918e+08 > >> 2.06459e+08 > > > > What do you mean "as computed"? The output file does not contain > >> 1.10918e+08 > >> 2.06459e+08 > > anywhere. > > > > Are you modifying the example and running it again to get the > incorrect value? > > Yes, my bad. I did not explain it correctly > From maint, if you just run ex88 you will get the incorrect output, which > is not caught in the nightlyies because floating point values are > completely ignored. > Now that we ignore all values, tests need to be changed to check the distance from the correct vector. Matt > > [szampini@localhost tests]$ ./ex88 > Matrix of type: shell > Mat Object: 1 MPI processes > type: seqdense > 2.9678190300000000e+08 3.9288008100000000e+08 > 6.1374683500000000e+08 1.4173141580000000e+09 > Vec Object: 1 MPI processes > type: seq > 3.92973e+19 > 8.54197e+19 > Vec Object: 1 MPI processes > type: seq > 1.10918e+08 > 2.06459e+08 > MatDiagonalSet not tested on MATSHELL > …. > > > > > Barry > > > >> > >> -- > >> Stefano > > > > -- 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.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] Error in MatGetDiagonal_Shell?
by Stefano Zampini 30 Apr '18

30 Apr '18

> On Apr 30, 2018, at 3:14 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > I don't understand > > The code has > > ierr = MatGetDiagonal(A,W2);CHKERRQ(ierr); > ierr = VecView(W2,viewer);CHKERRQ(ierr); > > the output from this VecView seems to match the diagonal of the matrix printed earlier. > >> On Apr 29, 2018, at 10:02 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: >> >> By looking at src/mat/examples/tests/output/ex88_1.out, it seems that the output of MatGetDiagonal is wrong for MATSHELL. >> >> it should be >> 2.96782e+08 >> 1.41731e+09 >> and not (as computed) >> 1.10918e+08 >> 2.06459e+08 > > What do you mean "as computed"? The output file does not contain >> 1.10918e+08 >> 2.06459e+08 > anywhere. > > Are you modifying the example and running it again to get the incorrect value? Yes, my bad. I did not explain it correctly From maint, if you just run ex88 you will get the incorrect output, which is not caught in the nightlyies because floating point values are completely ignored. [szampini@localhost tests]$ ./ex88 Matrix of type: shell Mat Object: 1 MPI processes type: seqdense 2.9678190300000000e+08 3.9288008100000000e+08 6.1374683500000000e+08 1.4173141580000000e+09 Vec Object: 1 MPI processes type: seq 3.92973e+19 8.54197e+19 Vec Object: 1 MPI processes type: seq 1.10918e+08 2.06459e+08 MatDiagonalSet not tested on MATSHELL …. > > Barry > >> >> -- >> Stefano >

1 0

Re: [petsc-dev] Error in MatGetDiagonal_Shell?
by Smith, Barry F. 29 Apr '18

29 Apr '18

I don't understand The code has ierr = MatGetDiagonal(A,W2);CHKERRQ(ierr); ierr = VecView(W2,viewer);CHKERRQ(ierr); the output from this VecView seems to match the diagonal of the matrix printed earlier. > On Apr 29, 2018, at 10:02 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > By looking at src/mat/examples/tests/output/ex88_1.out, it seems that the output of MatGetDiagonal is wrong for MATSHELL. > > it should be > 2.96782e+08 > 1.41731e+09 > and not (as computed) > 1.10918e+08 > 2.06459e+08 What do you mean "as computed"? The output file does not contain > 1.10918e+08 > 2.06459e+08 anywhere. Are you modifying the example and running it again to get the incorrect value? Barry > > -- > Stefano

1 0

Re: [petsc-dev] [petsc-users] Segmentation Violation in getting DMPlex coordinates
by Smith, Barry F. 29 Apr '18

29 Apr '18

> On Apr 29, 2018, at 6:19 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > For functions like this (only for one impl), should this new check be considered new best practices (as opposed to the composition approach, defining things with names like DMDASetUniformCoordinates_DMDA())? It seems like less boilerplate, as well as avoiding a function on the stack (and the check itself if it's turned off in optimized mode). No, it is just error checking for incorrectly written code that is too much hassle to change. Barry > > 2018-04-28 22:38 GMT+02:00 Smith, Barry F. <bsmith(a)mcs.anl.gov>: > > Added runtime error checking for such incorrect calls in barry/dmda-calls-type-check > > > > On Apr 28, 2018, at 9:19 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Sat, Apr 28, 2018 at 2:08 AM, Danyang Su <danyang.su(a)gmail.com> wrote: > > Hi All, > > > > I use DMPlex and need to get coordinates back after distribution. However, I always get segmentation violation in getting coords values in the following codes if using multiple processors. If only one processor is used, it works fine. > > > > For each processors, the off value starts from 0 which looks good. I also tried 0-based index, which gives the same error. Would any one help to check what is wrong here? > > > > idof 1 off 0 > > idof 2 off 0 > > idof 1 off 2 > > idof 2 off 2 > > idof 1 off 4 > > idof 2 off 4 > > idof 1 off 6 > > idof 2 off 6 > > idof 1 off 8 > > idof 2 off 8 > > > > > > DM :: distributedMesh, cda > > Vec :: gc > > PetscScalar, pointer :: coords(:) > > PetscSection :: cs > > > > ... > > > > call DMGetCoordinatesLocal(dmda_flow%da,gc,ierr) > > CHKERRQ(ierr) > > > > call DMGetCoordinateDM(dmda_flow%da,cda,ierr) > > CHKERRQ(ierr) > > > > call DMGetDefaultSection(cda,cs,ierr) > > CHKERRQ(ierr) > > > > call PetscSectionGetChart(cs,istart,iend,ierr) > > CHKERRQ(ierr) > > > > !c get coordinates array > > call DMDAVecGetArrayF90(cda,gc,coords,ierr) > > > > You cannot call DMDA function if you have a DMPlex. You jsut call VecGetArrayF90() > > > > Matt > > > > CHKERRQ(ierr) > > > > do ipoint = istart, iend-1 > > > > call PetscSectionGetDof(cs,ipoint,dof,ierr) > > CHKERRQ(ierr) > > > > call PetscSectionGetOffset(cs,ipoint,off,ierr) > > CHKERRQ(ierr) > > > > inode = ipoint-istart+1 > > > > if (cell_coords == coords_xyz) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = coords(off+2) > > nodes(inode)%z = coords(off+3) > > else if (cell_coords == coords_xy) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = coords(off+2) > > nodes(inode)%z = 0.0d0 > > else if (cell_coords == coords_yz) then > > nodes(inode)%x = 0.0d0 > > nodes(inode)%y = coords(off+1) > > nodes(inode)%z = coords(off+2) > > else if (cell_coords ==coords_xz) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = 0.0d0 > > nodes(inode)%z = coords(off+2) > > end if > > end do > > > > call DMDAVecRestoreArrayF90(cda,gc,coords,ierr) > > CHKERRQ(ierr) > > > > Thanks, > > > > Danyang > > > > > > > > > > > > -- > > 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/ > >

1 0

Error in MatGetDiagonal_Shell?
by Stefano Zampini 29 Apr '18

29 Apr '18

By looking at src/mat/examples/tests/output/ex88_1.out, it seems that the output of MatGetDiagonal is wrong for MATSHELL. it should be 2.96782e+08 1.41731e+09 and not (as computed) 1.10918e+08 2.06459e+08 -- Stefano

1 0

Re: [petsc-dev] [petsc-users] Segmentation Violation in getting DMPlex coordinates
by Patrick Sanan 29 Apr '18

29 Apr '18

For functions like this (only for one impl), should this new check be considered new best practices (as opposed to the composition approach, defining things with names like DMDASetUniformCoordinates_DMDA())? It seems like less boilerplate, as well as avoiding a function on the stack (and the check itself if it's turned off in optimized mode). 2018-04-28 22:38 GMT+02:00 Smith, Barry F. <bsmith(a)mcs.anl.gov>: > > Added runtime error checking for such incorrect calls in > barry/dmda-calls-type-check > > > > On Apr 28, 2018, at 9:19 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Sat, Apr 28, 2018 at 2:08 AM, Danyang Su <danyang.su(a)gmail.com> > wrote: > > Hi All, > > > > I use DMPlex and need to get coordinates back after distribution. > However, I always get segmentation violation in getting coords values in > the following codes if using multiple processors. If only one processor is > used, it works fine. > > > > For each processors, the off value starts from 0 which looks good. I > also tried 0-based index, which gives the same error. Would any one help to > check what is wrong here? > > > > idof 1 off 0 > > idof 2 off 0 > > idof 1 off 2 > > idof 2 off 2 > > idof 1 off 4 > > idof 2 off 4 > > idof 1 off 6 > > idof 2 off 6 > > idof 1 off 8 > > idof 2 off 8 > > > > > > DM :: distributedMesh, cda > > Vec :: gc > > PetscScalar, pointer :: coords(:) > > PetscSection :: cs > > > > ... > > > > call DMGetCoordinatesLocal(dmda_flow%da,gc,ierr) > > CHKERRQ(ierr) > > > > call DMGetCoordinateDM(dmda_flow%da,cda,ierr) > > CHKERRQ(ierr) > > > > call DMGetDefaultSection(cda,cs,ierr) > > CHKERRQ(ierr) > > > > call PetscSectionGetChart(cs,istart,iend,ierr) > > CHKERRQ(ierr) > > > > !c get coordinates array > > call DMDAVecGetArrayF90(cda,gc,coords,ierr) > > > > You cannot call DMDA function if you have a DMPlex. You jsut call > VecGetArrayF90() > > > > Matt > > > > CHKERRQ(ierr) > > > > do ipoint = istart, iend-1 > > > > call PetscSectionGetDof(cs,ipoint,dof,ierr) > > CHKERRQ(ierr) > > > > call PetscSectionGetOffset(cs,ipoint,off,ierr) > > CHKERRQ(ierr) > > > > inode = ipoint-istart+1 > > > > if (cell_coords == coords_xyz) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = coords(off+2) > > nodes(inode)%z = coords(off+3) > > else if (cell_coords == coords_xy) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = coords(off+2) > > nodes(inode)%z = 0.0d0 > > else if (cell_coords == coords_yz) then > > nodes(inode)%x = 0.0d0 > > nodes(inode)%y = coords(off+1) > > nodes(inode)%z = coords(off+2) > > else if (cell_coords ==coords_xz) then > > nodes(inode)%x = coords(off+1) > > nodes(inode)%y = 0.0d0 > > nodes(inode)%z = coords(off+2) > > end if > > end do > > > > call DMDAVecRestoreArrayF90(cda,gc,coords,ierr) > > CHKERRQ(ierr) > > > > Thanks, > > > > Danyang > > > > > > > > > > > > -- > > 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/ > >

1 0

Re: [petsc-dev] Install location for MPIUNI mpi.h
by Jed Brown 28 Apr '18

28 Apr '18

Satish Balay <balay(a)mcs.anl.gov> writes: > On Wed, 25 Apr 2018, Jed Brown wrote: > >> Bitbucket keeps saying "Something went wrong while creating your pull >> request." but you can look at the branch >> >> https://bitbucket.org/petsc/petsc/branch/jed/mpiuni-include/maint >> >> @balay Can we simply remove the MPIUNI includes from MPI.py or should we >> remove it later? > > Best to remove now - to check if there are issues? > > also Fix mpif.h usage code? > > There is also mpi.mod - that might need renaming [to comply with not installing in /usr/include?] > > So rename to mpiuni.mod? [and rename mpi.h to mpiuni.h etc?] Renaming to include/petsc/mpiuni.h and the module probably makes sense because ensuring correct path ordering is really delicate. > Looks like this change is more of a 'master change'.. This branch started from 'maint', but does not need to be merged there. >> What --download packages are supported when using >> MPIUNI? I don't see any examples. > > Yeah - our tests are basic here. I don't remember if any externalpackages compiled with mpiuni > > Satish

1 0

Re: [petsc-dev] Install location for MPIUNI mpi.h
by Satish Balay 25 Apr '18

25 Apr '18

On Wed, 25 Apr 2018, Jed Brown wrote: > Bitbucket keeps saying "Something went wrong while creating your pull > request." but you can look at the branch > > https://bitbucket.org/petsc/petsc/branch/jed/mpiuni-include/maint > > @balay Can we simply remove the MPIUNI includes from MPI.py or should we > remove it later? Best to remove now - to check if there are issues? also Fix mpif.h usage code? There is also mpi.mod - that might need renaming [to comply with not installing in /usr/include?] So rename to mpiuni.mod? [and rename mpi.h to mpiuni.h etc?] Looks like this change is more of a 'master change'.. > What --download packages are supported when using > MPIUNI? I don't see any examples. Yeah - our tests are basic here. I don't remember if any externalpackages compiled with mpiuni Satish

1 0

Re: [petsc-dev] Install location for MPIUNI mpi.h
by Jed Brown 25 Apr '18

25 Apr '18

Bitbucket keeps saying "Something went wrong while creating your pull request." but you can look at the branch https://bitbucket.org/petsc/petsc/branch/jed/mpiuni-include/maint @balay Can we simply remove the MPIUNI includes from MPI.py or should we remove it later? What --download packages are supported when using MPIUNI? I don't see any examples. "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> On Apr 25, 2018, at 2:47 PM, Balay, Satish <balay(a)mcs.anl.gov> wrote: >> >> On Wed, 25 Apr 2018, Smith, Barry F. wrote: >> >>> >>> >>>> On Apr 25, 2018, at 2:31 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>> >>>> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >>>> >>>>>> On Apr 25, 2018, at 1:36 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>>>>> >>>>>> It is currently installed to include/petsc/mpiuni/mpi.h and petscsys.h >>>>>> includes it as <mpi.h>, which means that users of MPIUNI need to put >>>>>> -I/prefix/include/petsc/mpiuni in their command lines. Matt and I agree >>>>>> that this is bad. We disagree on the solution. >>>>>> >>>>>> He wants to install it to /prefix/include/mpi.h as though the user had >>>>>> written --download-mpich. This would conflict if a user later installs >>>>>> a real MPI to that location. >>>>> >>>>> Jed, >>>>> >>>>> So you propose in petscsys.h ? >>>>> >>>>> #if defined(PETSC_HAVE_MPIUNI) >>>>> #include <petsc/mpiuni/mpi.h> >>>>> #else >>>>> #include <mpi.h> >>>>> #endif >>>>> >>>>> I don't have a problem with this. >>>> >>>> Yes, and same installation layout as today. >>> >>> Ok, this is far better than copying the mpiuni mpi.h file to a public place (Matt's suggestion) and is a bit better than requiring the extra -I flag (Satish's suggestion) >>> >> >> All approaches have drawbacks. This approach breaks user code. I guess thats easy to work arround [and fix these >> examples awell] >> >> $ git grep '<mpi\.h>' |grep examples >> src/dm/examples/tests/ex42.c:#include <mpi.h> >> src/tao/leastsquares/examples/tutorials/chwirut2.c:#include <mpi.h> > > Fix these examples at the same time. >> >> >>>> >>>>> I notice that the Fortran petscsys.h is scattered full of weird MPIUni specific stuff like >>>>> >>>>> #if defined (PETSC_HAVE_MPIUNI) >>>>> #include "mpiunifdef.h" >>>>> #endif >>>>> >>>>> #if defined(PETSC_HAVE_MPIUNI) >>>>> #define MPI_Comm PetscFortranInt >>>>> #define MPI_Group PetscFortranInt >>>>> #define PetscMPIInt PetscFortranInt >>>>> #else >>>>> #define MPI_Comm integer >>>>> #define MPI_Group integer >>>>> #define PetscMPIInt integer >>>>> #endif >> >> I might have diverged from mpi standard to prevent '-i8' affecting petsc+mpiuni code. > > Ah, yes > >> >> Satish >> >>>>> >>>>> It seems PETSc Fortran does not use the standard mpif.h file? >>>> >>>> Yuck. >>> >>> I don't remember the history of this construct. There must have been a reason years ago that may no longer exist, I don't know. >>> >>> Barry

1 0