March 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Scot Breitenfeld 11 Mar '14

11 Mar '14

I could also get it to work on Linux 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux which is probably what your laptop is running? Maybe it’s a 32-bit version issue? The comment about documentation was geared toward the people in charge of mpich.org, since they run the mailing list and I’m assuming they are in charge of the Documentation Manpages on mpich.org. I just gravitate to an html document rather then scanning a pdf :) Thanks, Scot On Mar 11, 2014, at 2:13 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > The modified program works correctly on my laptop. > >> Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >> >> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html > > That page provides the C binding and generic description of arguments identical to the one provided on pg 93 of the MPI 3.0 standard. In any case, the definitive source for function bindings should be the MPI 3.0 standard available at www.mpi-forum.org, not any other web site. > > Rajeev > > > > On Mar 11, 2014, at 1:39 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > >> I checked the original program and the suggested version on another machine using >> >> mpif90 for MPICH2 version 1.5 >> exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) >> exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) >> >> And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. >> >> http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html >> >> I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. >> >> Scot >> >> Updated program: >> >> PROGRAM struct >> >> USE mpi >> USE iso_c_binding >> >> IMPLICIT NONE >> >> INTEGER, PARAMETER :: NELEM = 2 >> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >> INTEGER :: stat(MPI_STATUS_SIZE) >> INTEGER :: fh >> INTEGER :: status >> INTEGER(kind=MPI_OFFSET_KIND) :: disp >> >> INTEGER, DIMENSION(1:3) :: iiaux >> >> TYPE Particle >> SEQUENCE >> INTEGER, DIMENSION(1:3) :: indx >> END TYPE Particle >> >> TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles >> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent >> INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets >> TYPE(C_PTR) :: fptr >> >> CALL MPI_INIT(ierr) >> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >> >> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >> offsets(1) = 0 >> oldtypes(1) = MPI_INTEGER >> blockcounts(1) = 3 >> >> ! Now define structured TYPE and commit it >> CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) >> CALL MPI_TYPE_COMMIT(particletype, ierr) >> >> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >> >> disp = 0 >> >> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >> >> particles(1)%indx = -1 >> >> fptr = C_LOC( particles(1)%indx(1)) >> >> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >> >> PRINT*,"Derived type" >> DO i=1,nelem >> PRINT*,particles(i)%indx >> ENDDO >> >> CALL MPI_File_close(fh, ierr) >> >> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >> MPI_INFO_NULL, fh, ierr) >> >> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >> >> PRINT*,"No derived type" >> >> PRINT*,iiaux >> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >> PRINT*,iiaux >> >> CALL MPI_File_close(fh, ierr) >> >> CALL MPI_FINALIZE(ierr) >> END PROGRAM struct >> >> >> >> >> >> On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: >> >>> Hi, >>> >>> I created a file in fortran using (which I compiled with mpif90): >>> >>> PROGRAM writeUstream >>> >>> IMPLICIT NONE >>> INTEGER :: i, ii >>> INTEGER, DIMENSION(1:3,1:25) :: buf >>> >>> OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") >>> >>> ii = 1 >>> >>> DO i=1, 25 >>> buf(1,i) = ii >>> buf(2,i) = ii+1 >>> buf(3,i) = ii+2 >>> WRITE(11) buf(1:3,i) >>> ii = ii + 3 >>> ENDDO >>> CLOSE(UNIT=11) >>> >>> END PROGRAM writeUstream >>> >>> And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: >>> >>> PROGRAM struct >>> >>> USE mpi >>> >>> IMPLICIT NONE >>> >>> INTEGER, PARAMETER :: NELEM = 2 >>> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >>> INTEGER :: stat(MPI_STATUS_SIZE) >>> INTEGER :: fh >>> INTEGER :: status >>> INTEGER(kind=MPI_OFFSET_KIND) :: disp >>> >>> INTEGER, DIMENSION(1:3) :: iiaux >>> >>> TYPE Particle >>> SEQUENCE >>> INTEGER, DIMENSION(1:3) :: indx >>> END TYPE Particle >>> >>> TYPE(Particle), DIMENSION(1:nelem) :: particles >>> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent >>> >>> CALL MPI_INIT(ierr) >>> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >>> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >>> >>> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >>> offsets(1) = 0 >>> oldtypes(1) = MPI_INTEGER >>> blockcounts(1) = 3 >>> >>> ! Now define structured TYPE and commit it >>> CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) >>> CALL MPI_TYPE_COMMIT(particletype, ierr) >>> >>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >>> >>> disp = 0 >>> >>> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >>> >>> particles(1:nelem)%indx = -1 >>> >>> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >>> >>> PRINT*,"derived type" >>> DO i=1,nelem >>> PRINT*,particles(i)%indx >>> ENDDO >>> >>> CALL MPI_File_close(fh, ierr) >>> >>> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >>> MPI_INFO_NULL, fh, ierr) >>> >>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>> >>> PRINT*,"No derived type" >>> >>> PRINT*,iiaux >>> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >>> PRINT*,iiaux >>> >>> CALL MPI_File_close(fh, ierr) >>> >>> CALL MPI_FINALIZE(ierr) >>> END PROGRAM struct >>> >>> >>> When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: >>> >>> derived type >>> 24 0 3 >>> 4 5 6 >>> No derived type >>> 1 2 3 >>> 4 5 6 >>> >>> I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux >>> I not exactly sure what is going on. >>> >>> Thanks, >>> Scot >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Rajeev Thakur 11 Mar '14

11 Mar '14

The modified program works correctly on my laptop. > Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. > > http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html That page provides the C binding and generic description of arguments identical to the one provided on pg 93 of the MPI 3.0 standard. In any case, the definitive source for function bindings should be the MPI 3.0 standard available at www.mpi-forum.org, not any other web site. Rajeev On Mar 11, 2014, at 1:39 PM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > I checked the original program and the suggested version on another machine using > > mpif90 for MPICH2 version 1.5 > exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) > exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) > > And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. > > http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html > > I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. > > Scot > > Updated program: > > PROGRAM struct > > USE mpi > USE iso_c_binding > > IMPLICIT NONE > > INTEGER, PARAMETER :: NELEM = 2 > INTEGER :: numtasks, rank, source, dest, tag, i, ierr > INTEGER :: stat(MPI_STATUS_SIZE) > INTEGER :: fh > INTEGER :: status > INTEGER(kind=MPI_OFFSET_KIND) :: disp > > INTEGER, DIMENSION(1:3) :: iiaux > > TYPE Particle > SEQUENCE > INTEGER, DIMENSION(1:3) :: indx > END TYPE Particle > > TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles > INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent > INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets > TYPE(C_PTR) :: fptr > > CALL MPI_INIT(ierr) > CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) > CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) > > ! Setup description of the 3 MPI_INTEGERS fields x, y, z > offsets(1) = 0 > oldtypes(1) = MPI_INTEGER > blockcounts(1) = 3 > > ! Now define structured TYPE and commit it > CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) > CALL MPI_TYPE_COMMIT(particletype, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) > > disp = 0 > > CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) > > particles(1)%indx = -1 > > fptr = C_LOC( particles(1)%indx(1)) > > CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) > > PRINT*,"Derived type" > DO i=1,nelem > PRINT*,particles(i)%indx > ENDDO > > CALL MPI_File_close(fh, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & > MPI_INFO_NULL, fh, ierr) > > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > > PRINT*,"No derived type" > > PRINT*,iiaux > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > PRINT*,iiaux > > CALL MPI_File_close(fh, ierr) > > CALL MPI_FINALIZE(ierr) > END PROGRAM struct > > > > > > On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > >> Hi, >> >> I created a file in fortran using (which I compiled with mpif90): >> >> PROGRAM writeUstream >> >> IMPLICIT NONE >> INTEGER :: i, ii >> INTEGER, DIMENSION(1:3,1:25) :: buf >> >> OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") >> >> ii = 1 >> >> DO i=1, 25 >> buf(1,i) = ii >> buf(2,i) = ii+1 >> buf(3,i) = ii+2 >> WRITE(11) buf(1:3,i) >> ii = ii + 3 >> ENDDO >> CLOSE(UNIT=11) >> >> END PROGRAM writeUstream >> >> And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: >> >> PROGRAM struct >> >> USE mpi >> >> IMPLICIT NONE >> >> INTEGER, PARAMETER :: NELEM = 2 >> INTEGER :: numtasks, rank, source, dest, tag, i, ierr >> INTEGER :: stat(MPI_STATUS_SIZE) >> INTEGER :: fh >> INTEGER :: status >> INTEGER(kind=MPI_OFFSET_KIND) :: disp >> >> INTEGER, DIMENSION(1:3) :: iiaux >> >> TYPE Particle >> SEQUENCE >> INTEGER, DIMENSION(1:3) :: indx >> END TYPE Particle >> >> TYPE(Particle), DIMENSION(1:nelem) :: particles >> INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent >> >> CALL MPI_INIT(ierr) >> CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >> CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) >> >> ! Setup description of the 3 MPI_INTEGERS fields x, y, z >> offsets(1) = 0 >> oldtypes(1) = MPI_INTEGER >> blockcounts(1) = 3 >> >> ! Now define structured TYPE and commit it >> CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) >> CALL MPI_TYPE_COMMIT(particletype, ierr) >> >> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) >> >> disp = 0 >> >> CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) >> >> particles(1:nelem)%indx = -1 >> >> CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) >> >> PRINT*,"derived type" >> DO i=1,nelem >> PRINT*,particles(i)%indx >> ENDDO >> >> CALL MPI_File_close(fh, ierr) >> >> CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & >> MPI_INFO_NULL, fh, ierr) >> >> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >> >> PRINT*,"No derived type" >> >> PRINT*,iiaux >> CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) >> PRINT*,iiaux >> >> CALL MPI_File_close(fh, ierr) >> >> CALL MPI_FINALIZE(ierr) >> END PROGRAM struct >> >> >> When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: >> >> derived type >> 24 0 3 >> 4 5 6 >> No derived type >> 1 2 3 >> 4 5 6 >> >> I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux >> I not exactly sure what is going on. >> >> Thanks, >> Scot >> >> >> >> >> >> > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Scot Breitenfeld 11 Mar '14

11 Mar '14

I checked the original program and the suggested version on another machine using mpif90 for MPICH2 version 1.5 exec: export(export,XL_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/xlf.cfg.rhel6.5.gcc447:bgxlf90,NULL) exec: export(export,XLF_USR_CONFIG=/soft/compilers/ibmcmp-aug2013/xlf/bg/14.1/etc/V1R2M1.xlf.cfg.rhel6.5.gcc447,NULL) And both methods of reading the file worked correctly for both programs. However, the suggested changes do not work on the original system. Also, the documentation for MPI_Type_create_struct leads one to think that all MPI objects (that includes MPI_Aint) in fortran are of type integer. http://www.mpich.org/static/docs/v3.0.x/www3/MPI_Type_create_struct.html I think elsewhere in the documentation it says MPI_Aint is kind=MPI_ADDRESS_KIND, but it would be nice to have note that on the man page. Scot Updated program: PROGRAM struct USE mpi USE iso_c_binding IMPLICIT NONE INTEGER, PARAMETER :: NELEM = 2 INTEGER :: numtasks, rank, source, dest, tag, i, ierr INTEGER :: stat(MPI_STATUS_SIZE) INTEGER :: fh INTEGER :: status INTEGER(kind=MPI_OFFSET_KIND) :: disp INTEGER, DIMENSION(1:3) :: iiaux TYPE Particle SEQUENCE INTEGER, DIMENSION(1:3) :: indx END TYPE Particle TYPE(Particle), DIMENSION(1:nelem), TARGET :: particles INTEGER particletype, oldtypes(1:1), blockcounts(1:1), extent INTEGER(kind=MPI_ADDRESS_KIND), DIMENSION(1:1) :: offsets TYPE(C_PTR) :: fptr CALL MPI_INIT(ierr) CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) ! Setup description of the 3 MPI_INTEGERS fields x, y, z offsets(1) = 0 oldtypes(1) = MPI_INTEGER blockcounts(1) = 3 ! Now define structured TYPE and commit it CALL MPI_Type_create_struct(1, blockcounts, offsets, oldtypes, particletype, ierr) CALL MPI_TYPE_COMMIT(particletype, ierr) CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) disp = 0 CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) particles(1)%indx = -1 fptr = C_LOC( particles(1)%indx(1)) CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) PRINT*,"Derived type" DO i=1,nelem PRINT*,particles(i)%indx ENDDO CALL MPI_File_close(fh, ierr) CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & MPI_INFO_NULL, fh, ierr) CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) PRINT*,"No derived type" PRINT*,iiaux CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) PRINT*,iiaux CALL MPI_File_close(fh, ierr) CALL MPI_FINALIZE(ierr) END PROGRAM struct On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > Hi, > > I created a file in fortran using (which I compiled with mpif90): > > PROGRAM writeUstream > > IMPLICIT NONE > INTEGER :: i, ii > INTEGER, DIMENSION(1:3,1:25) :: buf > > OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") > > ii = 1 > > DO i=1, 25 > buf(1,i) = ii > buf(2,i) = ii+1 > buf(3,i) = ii+2 > WRITE(11) buf(1:3,i) > ii = ii + 3 > ENDDO > CLOSE(UNIT=11) > > END PROGRAM writeUstream > > And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: > > PROGRAM struct > > USE mpi > > IMPLICIT NONE > > INTEGER, PARAMETER :: NELEM = 2 > INTEGER :: numtasks, rank, source, dest, tag, i, ierr > INTEGER :: stat(MPI_STATUS_SIZE) > INTEGER :: fh > INTEGER :: status > INTEGER(kind=MPI_OFFSET_KIND) :: disp > > INTEGER, DIMENSION(1:3) :: iiaux > > TYPE Particle > SEQUENCE > INTEGER, DIMENSION(1:3) :: indx > END TYPE Particle > > TYPE(Particle), DIMENSION(1:nelem) :: particles > INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent > > CALL MPI_INIT(ierr) > CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) > CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) > > ! Setup description of the 3 MPI_INTEGERS fields x, y, z > offsets(1) = 0 > oldtypes(1) = MPI_INTEGER > blockcounts(1) = 3 > > ! Now define structured TYPE and commit it > CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) > CALL MPI_TYPE_COMMIT(particletype, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) > > disp = 0 > > CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) > > particles(1:nelem)%indx = -1 > > CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) > > PRINT*,"derived type" > DO i=1,nelem > PRINT*,particles(i)%indx > ENDDO > > CALL MPI_File_close(fh, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & > MPI_INFO_NULL, fh, ierr) > > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > > PRINT*,"No derived type" > > PRINT*,iiaux > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > PRINT*,iiaux > > CALL MPI_File_close(fh, ierr) > > CALL MPI_FINALIZE(ierr) > END PROGRAM struct > > > When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: > > derived type > 24 0 3 > 4 5 6 > No derived type > 1 2 3 > 4 5 6 > > I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux > I not exactly sure what is going on. > > Thanks, > Scot > > > > > >

1 0

Re: [mpich-discuss] MPI_FILE_read and derived types in fortran.
by Rajeev Thakur 11 Mar '14

11 Mar '14

Use MPI_Type_create_struct instead of MPI_Type_struct, which has been deprecated since 1997 and removed in MPI-3 in 2012 because of Fortran binding issues. For MPI_Type_create_struct, the offsets array needs to be declared as integer (kind=MPI_ADDRESS_KIND). See if that helps. Rajeev On Mar 11, 2014, at 11:25 AM, Scot Breitenfeld <brtnfld(a)hdfgroup.org> wrote: > Hi, > > I created a file in fortran using (which I compiled with mpif90): > > PROGRAM writeUstream > > IMPLICIT NONE > INTEGER :: i, ii > INTEGER, DIMENSION(1:3,1:25) :: buf > > OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") > > ii = 1 > > DO i=1, 25 > buf(1,i) = ii > buf(2,i) = ii+1 > buf(3,i) = ii+2 > WRITE(11) buf(1:3,i) > ii = ii + 3 > ENDDO > CLOSE(UNIT=11) > > END PROGRAM writeUstream > > And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: > > PROGRAM struct > > USE mpi > > IMPLICIT NONE > > INTEGER, PARAMETER :: NELEM = 2 > INTEGER :: numtasks, rank, source, dest, tag, i, ierr > INTEGER :: stat(MPI_STATUS_SIZE) > INTEGER :: fh > INTEGER :: status > INTEGER(kind=MPI_OFFSET_KIND) :: disp > > INTEGER, DIMENSION(1:3) :: iiaux > > TYPE Particle > SEQUENCE > INTEGER, DIMENSION(1:3) :: indx > END TYPE Particle > > TYPE(Particle), DIMENSION(1:nelem) :: particles > INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent > > CALL MPI_INIT(ierr) > CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) > CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) > > ! Setup description of the 3 MPI_INTEGERS fields x, y, z > offsets(1) = 0 > oldtypes(1) = MPI_INTEGER > blockcounts(1) = 3 > > ! Now define structured TYPE and commit it > CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) > CALL MPI_TYPE_COMMIT(particletype, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) > > disp = 0 > > CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) > > particles(1:nelem)%indx = -1 > > CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) > > PRINT*,"derived type" > DO i=1,nelem > PRINT*,particles(i)%indx > ENDDO > > CALL MPI_File_close(fh, ierr) > > CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & > MPI_INFO_NULL, fh, ierr) > > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > > PRINT*,"No derived type" > > PRINT*,iiaux > CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) > PRINT*,iiaux > > CALL MPI_File_close(fh, ierr) > > CALL MPI_FINALIZE(ierr) > END PROGRAM struct > > > When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: > > derived type > 24 0 3 > 4 5 6 > No derived type > 1 2 3 > 4 5 6 > > I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux > I not exactly sure what is going on. > > Thanks, > Scot > > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI_FILE_read and derived types in fortran.
by Scot Breitenfeld 11 Mar '14

11 Mar '14

Hi, I created a file in fortran using (which I compiled with mpif90): PROGRAM writeUstream IMPLICIT NONE INTEGER :: i, ii INTEGER, DIMENSION(1:3,1:25) :: buf OPEN(UNIT=11, FILE="ustream.demo", FORM="unformatted", STATUS="UNKNOWN", ACCESS="STREAM") ii = 1 DO i=1, 25 buf(1,i) = ii buf(2,i) = ii+1 buf(3,i) = ii+2 WRITE(11) buf(1:3,i) ii = ii + 3 ENDDO CLOSE(UNIT=11) END PROGRAM writeUstream And I’ve made a simple program to read the file (on the same machine) using MPI_FILE_read: PROGRAM struct USE mpi IMPLICIT NONE INTEGER, PARAMETER :: NELEM = 2 INTEGER :: numtasks, rank, source, dest, tag, i, ierr INTEGER :: stat(MPI_STATUS_SIZE) INTEGER :: fh INTEGER :: status INTEGER(kind=MPI_OFFSET_KIND) :: disp INTEGER, DIMENSION(1:3) :: iiaux TYPE Particle SEQUENCE INTEGER, DIMENSION(1:3) :: indx END TYPE Particle TYPE(Particle), DIMENSION(1:nelem) :: particles INTEGER particletype, oldtypes(1:1), blockcounts(1:1), offsets(1:1), extent CALL MPI_INIT(ierr) CALL MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) CALL MPI_COMM_SIZE(MPI_COMM_WORLD, numtasks, ierr) ! Setup description of the 3 MPI_INTEGERS fields x, y, z offsets(1) = 0 oldtypes(1) = MPI_INTEGER blockcounts(1) = 3 ! Now define structured TYPE and commit it CALL MPI_TYPE_STRUCT(1, blockcounts, offsets, oldtypes, particletype, ierr) CALL MPI_TYPE_COMMIT(particletype, ierr) CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, MPI_INFO_NULL, fh, ierr) disp = 0 CALL MPI_File_set_view(fh, disp, MPI_INTEGER, particletype, "native", MPI_INFO_NULL, ierr) particles(1:nelem)%indx = -1 CALL MPI_File_read(fh, particles, nelem, particletype, status, ierr) PRINT*,"derived type" DO i=1,nelem PRINT*,particles(i)%indx ENDDO CALL MPI_File_close(fh, ierr) CALL MPI_File_open(MPI_COMM_WORLD, "ustream.demo", MPI_MODE_RDONLY, & MPI_INFO_NULL, fh, ierr) CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) PRINT*,"No derived type" PRINT*,iiaux CALL MPI_FILE_read(fh,iiaux,3,MPI_INTEGER,status,ierr) PRINT*,iiaux CALL MPI_File_close(fh, ierr) CALL MPI_FINALIZE(ierr) END PROGRAM struct When I run this program to read the file using just one process, the first two integers of the derived type are not correct, but all the remaining values are correct. All the values when reading them into an integer array is correct. Here is the output: derived type 24 0 3 4 5 6 No derived type 1 2 3 4 5 6 I don’t get any error from the MPI calls and I used gcc 4.8.1 to compile mpich 3.0.4 on Linux 2.6.18-308.13.1.el5PAE #1 SMP Tue Aug 21 17:50:26 EDT 2012 i686 i686 i386 GNU/Linux I not exactly sure what is going on. Thanks, Scot

1 0

Re: [mpich-discuss] Problems with computation-communication overlap in non-blocking mode
by Kenneth Raffenetti 10 Mar '14

10 Mar '14

Hi Nikola, I've added my responses inline. On 03/07/2014 08:50 AM, Velickovic Nikola wrote: > > Dear all, > > I have a simple MPI program with two processes using non-blocking communication illustrated bellow: > > process 0: process 1: > > MPI_Isend MPI_Irecv > > compute stage compute stage > > MPI_Wait MPI_Wait > > Actual communication is performed by offloading it to another thread, or using DMA (KNEM module is used for this). > Ideally what should happen is that process 0 issues a non-blocking send, process 1 receives the data > and in the meantime (in parallel) the CPU cores where the processes run are doing the compute stage. > When compute stage is completed calling MPI_Wait wraps up the communication. > > When I profile my application it turns out that actual communication is initiated with MPI_Wait (significant amount of time is spent there) and hence disables overlapping > communication and computation since MPI_Wait is called after the compute stage. > Computation in my test case takes more time than communication so MPI_Wait should not be consuming significant amount of time since the communication should be over by then. > This is allowed by the MPI standard. Non-blocking communication calls do not guarantee asynchronous progress. > This I confirmed also by using MPI_Test instead of MPI_Wait. > MPI_Test has the same effect as MPI_Wait (to the best of my knowledge) but is non-blocking. > When placing MPI_Test strategically in the compute stage it initiates the communication and a certain communication-computation overlap is achieved. Using MPI_Test is a valid way to invoke progress. MPICH also provides an environment variable (MPIR_CVAR_ASYNC_PROGRESS) that you can set to true in your program env to cause MPICH to make progress on your non-blocking communication, without having to modify your code. Yet another way would be to run as a multi-threaded MPI program and use one thread for communication and one for computation. Ken

1 0

Re: [mpich-discuss] Mpich failing electric-fence check
by Balaji, Pavan 08 Mar '14

08 Mar '14

Huiwei, Your fix is wrong. Please see the previous email I sent. — Pavan On Mar 8, 2014, at 4:50 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > We have found one malloc(0) line in MPID_nem_init and fixed that. > The change should be available in tomorrow’s nightly build tarball. > http://www.mpich.org/static/downloads/nightly/master/mpich/ > > Thanks for reporting. > — > Huiwei Lu > Postdoc Appointee > Mathematics and Computer Science Division, Argonne National Laboratory > http://www.mcs.anl.gov/~huiweilu/ > > On Mar 7, 2014, at 10:33 AM, Matthieu Dorier <matthieu.dorier(a)irisa.fr> wrote: > >> I didn't know electric-fence was so old. >> I managed to find the corruption with valgrind anyway, but it was just in case someone else wanted to use electric-fence. >> >> Matthieu Dorier >> PhD student at ENS Rennes >> http://people.irisa.fr/Matthieu.Dorier >> ----- Mail original ----- >>> De: "Rob Latham" <robl(a)mcs.anl.gov> >>> À: discuss(a)mpich.org >>> Envoyé: Vendredi 7 Mars 2014 16:35:27 >>> Objet: Re: [mpich-discuss] Mpich failing electric-fence check >>> >>> >>> >>> On 03/07/2014 09:25 AM, Jed Brown wrote: >>>> Matthieu Dorier <matthieu.dorier(a)irisa.fr> writes: >>>>> ElectricFence Aborting: Allocating 0 bytes, probably a bug. >>>> >>>> I would argue that ElectricFence is wrong here. The standard guarantees >>>> that malloc(0) succeeds and it is useful to simplify code and to test >>>> for matching free in cases where a positive size is rare. >>> >>> It wouldn't suprise me to find ElecritcFence buggy. It was a great tool >>> back in the day but Perens stopped maintaining it a decade ago, and >>> there seem to be some half-hearted attempts by the community to keep it >>> active (debian has some updates from... somewhere. >>> http://duma.sourceforge.net/ might work? >>> >>> I think everyone around here uses valgrind anyway. >>> >>> ==rob >>> >>> >>> >>>> >>>> C99 §7.20.3: If the size of the space requested is zero, the behavior is >>>> implementation- >>>> defined: either a null pointer is returned, or the behavior is as if the >>>> size were some >>>> nonzero value, except that the returned pointer shall not be used to access >>>> an object. >>>> >>>> Either way, the returned pointer can be passed to free. Are you aware >>>> of current malloc implementations which violate the above? >>>> >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> -- >>> Rob Latham >>> Mathematics and Computer Science Division >>> Argonne National Lab, IL USA >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Mpich failing electric-fence check
by Lu, Huiwei 08 Mar '14

08 Mar '14

We have found one malloc(0) line in MPID_nem_init and fixed that. The change should be available in tomorrow’s nightly build tarball. http://www.mpich.org/static/downloads/nightly/master/mpich/ Thanks for reporting. — Huiwei Lu Postdoc Appointee Mathematics and Computer Science Division, Argonne National Laboratory http://www.mcs.anl.gov/~huiweilu/ On Mar 7, 2014, at 10:33 AM, Matthieu Dorier <matthieu.dorier(a)irisa.fr> wrote: > I didn't know electric-fence was so old. > I managed to find the corruption with valgrind anyway, but it was just in case someone else wanted to use electric-fence. > > Matthieu Dorier > PhD student at ENS Rennes > http://people.irisa.fr/Matthieu.Dorier > ----- Mail original ----- >> De: "Rob Latham" <robl(a)mcs.anl.gov> >> À: discuss(a)mpich.org >> Envoyé: Vendredi 7 Mars 2014 16:35:27 >> Objet: Re: [mpich-discuss] Mpich failing electric-fence check >> >> >> >> On 03/07/2014 09:25 AM, Jed Brown wrote: >>> Matthieu Dorier <matthieu.dorier(a)irisa.fr> writes: >>>> ElectricFence Aborting: Allocating 0 bytes, probably a bug. >>> >>> I would argue that ElectricFence is wrong here. The standard guarantees >>> that malloc(0) succeeds and it is useful to simplify code and to test >>> for matching free in cases where a positive size is rare. >> >> It wouldn't suprise me to find ElecritcFence buggy. It was a great tool >> back in the day but Perens stopped maintaining it a decade ago, and >> there seem to be some half-hearted attempts by the community to keep it >> active (debian has some updates from... somewhere. >> http://duma.sourceforge.net/ might work? >> >> I think everyone around here uses valgrind anyway. >> >> ==rob >> >> >> >>> >>> C99 §7.20.3: If the size of the space requested is zero, the behavior is >>> implementation- >>> defined: either a null pointer is returned, or the behavior is as if the >>> size were some >>> nonzero value, except that the returned pointer shall not be used to access >>> an object. >>> >>> Either way, the returned pointer can be passed to free. Are you aware >>> of current malloc implementations which violate the above? >>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Mpich failing electric-fence check
by Matthieu Dorier 07 Mar '14

07 Mar '14

I didn't know electric-fence was so old. I managed to find the corruption with valgrind anyway, but it was just in case someone else wanted to use electric-fence. Matthieu Dorier PhD student at ENS Rennes http://people.irisa.fr/Matthieu.Dorier ----- Mail original ----- > De: "Rob Latham" <robl(a)mcs.anl.gov> > À: discuss(a)mpich.org > Envoyé: Vendredi 7 Mars 2014 16:35:27 > Objet: Re: [mpich-discuss] Mpich failing electric-fence check > > > > On 03/07/2014 09:25 AM, Jed Brown wrote: > > Matthieu Dorier <matthieu.dorier(a)irisa.fr> writes: > >> ElectricFence Aborting: Allocating 0 bytes, probably a bug. > > > > I would argue that ElectricFence is wrong here. The standard guarantees > > that malloc(0) succeeds and it is useful to simplify code and to test > > for matching free in cases where a positive size is rare. > > It wouldn't suprise me to find ElecritcFence buggy. It was a great tool > back in the day but Perens stopped maintaining it a decade ago, and > there seem to be some half-hearted attempts by the community to keep it > active (debian has some updates from... somewhere. > http://duma.sourceforge.net/ might work? > > I think everyone around here uses valgrind anyway. > > ==rob > > > > > > > C99 §7.20.3: If the size of the space requested is zero, the behavior is > > implementation- > > defined: either a null pointer is returned, or the behavior is as if the > > size were some > > nonzero value, except that the returned pointer shall not be used to access > > an object. > > > > Either way, the returned pointer can be passed to free. Are you aware > > of current malloc implementations which violate the above? > > > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Mpich failing electric-fence check
by Rob Latham 07 Mar '14

07 Mar '14

On 03/07/2014 09:25 AM, Jed Brown wrote: > Matthieu Dorier <matthieu.dorier(a)irisa.fr> writes: >> ElectricFence Aborting: Allocating 0 bytes, probably a bug. > > I would argue that ElectricFence is wrong here. The standard guarantees > that malloc(0) succeeds and it is useful to simplify code and to test > for matching free in cases where a positive size is rare. It wouldn't suprise me to find ElecritcFence buggy. It was a great tool back in the day but Perens stopped maintaining it a decade ago, and there seem to be some half-hearted attempts by the community to keep it active (debian has some updates from... somewhere. http://duma.sourceforge.net/ might work? I think everyone around here uses valgrind anyway. ==rob > > C99 ï¿½7.20.3: If the size of the space requested is zero, the behavior is implementation- > defined: either a null pointer is returned, or the behavior is as if the size were some > nonzero value, except that the returned pointer shall not be used to access an object. > > Either way, the returned pointer can be passed to free. Are you aware > of current malloc implementations which violate the above? > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0