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

Re: [mpich-discuss] bug in MPI_File_write_all?
by Rob Latham 21 May '14

21 May '14

On 05/21/2014 05:50 AM, CANELA-XANDRI Oriol wrote: > Ok, so it seems a problem with parallel access to this file system. Other network file systems like NFS, for instance, should not be a problem, right? > > Do you know if there is some method just for checking that this kind of problems will not arise in a particular system (with an 'unknown' file system)? > you can use NFS if you must but NFS is also not a true parallel file system. One could simply write to a local file system for a start. The PVFS parallel file system is another option. It's free and easy to deploy. Many sites have Lustre, though it is a bit more complicated. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] bug in MPI_File_write_all?
by CANELA-XANDRI Oriol 21 May '14

21 May '14

Ok, so it seems a problem with parallel access to this file system. Other network file systems like NFS, for instance, should not be a problem, right? Do you know if there is some method just for checking that this kind of problems will not arise in a particular system (with an 'unknown' file system)? Many thanks, Oriol -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -----Original Message----- From: discuss-bounces(a)mpich.org [mailto:[email protected]] On Behalf Of Rob Latham Sent: 20 May 2014 16:01 To: discuss(a)mpich.org Subject: Re: [mpich-discuss] bug in MPI_File_write_all? On 05/20/2014 09:37 AM, CANELA-XANDRI Oriol wrote: > I am writing on a sshfs... Now, I tried on the 'local' disk (I am inside a virtual machine) and there seems that works ok. So, the problem is related with the sshfs? sshfs and other fuse-based file systems have page-based accesses. If two processes attempt to write different parts of the same page, it might not be clear who should win. I don't know the exact details of the ssshfs/fusefs consistency semantics, but apparently they are not adequate for parallel access. ==rob -- 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] configure MPICH with Absoft Fortran
by Rajeev Thakur 20 May '14

20 May '14

The config.log shows this value for FFLAGS . Make sure FFLAGS is not set in your environment before running configure. FFLAGS=-w -m64 -YEXT_NAMES=LCS -YEXT_SFX=_ -YMOD_ONLY Rajeev On May 19, 2014, at 10:39 PM, Yan Bai <yanbai06(a)gmail.com> wrote: > Dear all > > I haven been trying to install MPICH-3.1 for a month, but always failed. I use Absoft Fortran and configured the MPICH with the following command > > ./configure --prefix=/opt/mpich2-install F77=$ABSOFT/bin/af90 \ > FC=$ABSOFT/bin/af90 --with-pm=mpd > > > I got the following error message: > > configure: error: The selected Fortran 90 compiler /Applications/Absoft10.2/bin/af90 does not work with the selected Fortran 77 compiler /Applications/Absoft10.2/bin/af90. Use the environment variables FC and F77 respectively to select compatible Fortran compilers. The check here tests to see if a main program compiled with the Fortran 90 compiler can link with a subroutine compiled with the Fortran 77 compiler. > > I also tried the configure line in the Readme file of MPICH-3.1 and the following one, > ./configure --prefix=/opt/mpich2-install F77=$ABSOFT/bin/af77 \ > FC=$ABSOFT/bin/af90 --with-pm=mp > > All gave me the similar error message. Attached please find the config.log file. > > Any help/suggestions will be greatly appreciated! > > Best > > Yan > <config.log>_______________________________________________ > 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] optimization of MPI_Alltoall(..)
by Jan T. Balewski 20 May '14

20 May '14

Hi Daniel, thanks a lot for this comparisons test. I do not have access to the Inifiniband setup, so your numbers will help me to build the case that I need one locally. Change to inifiniband is obviously the most promising way to increase the throughput. Would it be to much to ask you run the my code on more than 32 cores (if you have that many)? At some point Inifiniband will saturate, adding more cores will not translate on the larger 'speed' in MB/sec. I'm curious where is this limit. Thanks you very much Jan P.S. due to hardcoded dimensions my code would run as is up to 64 cores. For a higher core count this 2 variables need to be modified so they are divisible by the core count: int NchXtot=9*5*7*64*2, NchTtot=9*5*7*64 ; Jan Quoting "Kokron, Daniel S. (GSFC-606.2)[Computer Sciences Corporation]" <daniel.s.kokron(a)nasa.gov>: > Jan, > > Here is some output from your code on a cluster that uses FDR > Infiniband instead of 1Gbit Ethernet. I also used the vendor MPI > which is SMP aware. >

1 0

Re: [mpich-discuss] bug in MPI_File_write_all?
by Rob Latham 20 May '14

20 May '14

On 05/20/2014 09:37 AM, CANELA-XANDRI Oriol wrote: > I am writing on a sshfs... Now, I tried on the 'local' disk (I am inside a virtual machine) and there seems that works ok. So, the problem is related with the sshfs? sshfs and other fuse-based file systems have page-based accesses. If two processes attempt to write different parts of the same page, it might not be clear who should win. I don't know the exact details of the ssshfs/fusefs consistency semantics, but apparently they are not adequate for parallel access. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] Value of fortran communicator handles
by marco restelli 20 May '14

20 May '14

2014-05-20 16:39 GMT+0200, Kenneth Raffenetti <raffenet(a)mcs.anl.gov>: > Marco, > > Yes, this is expected. Communicator handles are opaque objects. No > guarantees are made by MPI about their values to the user. To reason > about them, you need to use MPI_COMM_COMPARE. > > Ken OK, thanks. Marco

1 0

Re: [mpich-discuss] optimization of MPI_Alltoall(..)
by Kokron, Daniel S. (GSFC-606.2)[Computer Sciences Corporation] 20 May '14

20 May '14

Jan, Here is some output from your code on a cluster that uses FDR Infiniband instead of 1Gbit Ethernet. I also used the vendor MPI which is SMP aware. 2 nodes each with 2 sandybridge sockets (no process placement) ./a.out START: NchTtot=201600 NchTXtot=40320; oneCPU: NchTX=254016000 tot_size/B=508032000, kB=496125, MB=484, nCyc=1 Ncpu=32 , block: NchT_b=6300 NchX_b=1260 size/B=15876000, kB=15503, MB=15 #### Summary: Ncpu=32 avrT/sec=8.05 , maxT/sec=8.05, sumT/sec=257.68 totMB=16257.0 avrSpeed=2018.9(MB/sec) 4 nodes each with 2 sandybridge sockets (no process placement) mpiexec -np 32 ./a.out ./a.out START: NchTtot=201600 NchTXtot=40320; oneCPU: NchTX=254016000 tot_size/B=508032000, kB=496125, MB=484, nCyc=1 Ncpu=32 , block: NchT_b=6300 NchX_b=1260 size/B=15876000, kB=15503, MB=15 #### Summary: Ncpu=32 avrT/sec=6.94 , maxT/sec=6.94, sumT/sec=221.97 totMB=16257.0 avrSpeed=2343.7(MB/sec) Same 4 nodes, but with process placement (4 ranks/socket) mpiexec -np 32 ./a.out ./a.out START: NchTtot=201600 NchTXtot=40320; oneCPU: NchTX=254016000 tot_size/B=508032000, kB=496125, MB=484, nCyc=1 Ncpu=32 , block: NchT_b=6300 NchX_b=1260 size/B=15876000, kB=15503, MB=15 #### Summary: Ncpu=32 avrT/sec=6.86 , maxT/sec=6.86, sumT/sec=219.50 totMB=16257.0 avrSpeed=2370.0(MB/sec) ________________________________________ From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] on behalf of Jan T. Balewski [balewski(a)MIT.EDU] Sent: Monday, May 19, 2014 10:19 PM To: discuss(a)mpich.org Subject: [mpich-discuss] optimization of MPI_Alltoall(..) Hi, I want to use MPI to transpose a big NxM matrix. Currently the size is: N=20k, M=40k, type=ushort, total size =16GB (it will be larger in the future) To evaluate the code I report the processing speed in MB/sec, it is dominated by the cost of MPI_Alltoall(...) between 32 MPI processes. By changing the order in which MPI jobs are assigned to the cores on the blades I was able to increase the overall speed by ~15% , from 349 MB/sec to 398 MB/sec. My question is are there more tricks I can play to accelerate MPI_Alltoall(...) further ? (For now using the existing hardware) Thanks for any suggestions Jan P.S. Below are gory details: The transposition is done in 2 stages on 32 MPI jobs running on 4 8-core Dell 1950 blades. The 4 blades are connected via eth0 to the same card in the Cisco 1 GBit switch. This is the order of operations: - big matrix is divided on 32x32 non-square blocks - each of 32 blocks is transposed individually on CPU in each MPI job - the 32x32 blocks are exchanged between MPI jobs and transposed using MPI_Alltoall(...) command - the time is measured using MPI_Wtime() FYI, the whole code is visible at: https://bitbucket.org/balewski/kruk-mpi/src/8d3c4b7deb566f2768f132135b12e58… ***** mode 1: uses 8 consecutive cores per blade, next fill 2nd blade, etc $ mpiexec -f machinefile -n 32 ./kruk2 where machinefile is: oswrk139.lns.mit.edu:8 oswrk140.lns.mit.edu:8 oswrk145.lns.mit.edu:8 oswrk150.lns.mit.edu:8 Summary: Ncpu=32 avrT/sec=40.83, totMB=16257.0 avrSpeed=398.2(MB/sec) ***** mode 2: uses 1st core from all blades, next use 2nd core from all, etc: $ mpiexec -f machinefile -n 32 ./kruk2 where machinefile is: oswrk139.lns.mit.edu:1 oswrk140.lns.mit.edu:1 oswrk145.lns.mit.edu:1 oswrk150.lns.mit.edu:1 Summary: Ncpu=32 avrT/sec=46.61, totMB=16257.0 avrSpeed=348.8(MB/sec) (3) _______________________________________________ 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] Value of fortran communicator handles
by Kenneth Raffenetti 20 May '14

20 May '14

Marco, Yes, this is expected. Communicator handles are opaque objects. No guarantees are made by MPI about their values to the user. To reason about them, you need to use MPI_COMM_COMPARE. Ken On 05/20/2014 09:33 AM, marco restelli wrote: > Hi, > I noticed that the attached fortran code produces this output: > > $ mpiexec -n 4 -l ./mpitest > [0] color = 1 ; newcomm = -2080374780 > [1] color = 1 ; newcomm = -2080374782 > [2] color = 2 ; newcomm = -2080374782 > [3] color = 2 ; newcomm = -2080374782 > > I know that I am not supposed to use the values of the communicator > handles, but I was surprised to see that two processors in the same > communicator have two different values for such an handle. > > More precisely, I was assuming that newcomm had one value on procs 0 > and 1 and another value on 2 and 3. > > So my question is whether this is the expected behaviour or not. (In > fact, I need to debug another problem in my code and I wonder whether > this could be related or not). > > Thank you, > Marco > > > > mpich: version 1.5 > gfortran: 4.7.3 > > > > program mpitest > > implicit none > include "mpif.h" > > integer :: key, color, newcomm, mpi_id, ierr > > call mpi_init(ierr) > call mpi_comm_rank(mpi_comm_world,mpi_id,ierr) > > key = 1 ! same ordering as in comm > select case(mpi_id) > case(0) > color = 1 > case(1) > color = 1 > case(2) > color = 2 > case(3) > color = 2 > end select > call mpi_comm_split( mpi_comm_world , color,key , newcomm , ierr) > > write(*,*) "color = ",color, "; newcomm = ",newcomm > > call mpi_finalize(ierr) > > end program mpitest > _______________________________________________ > 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] bug in MPI_File_write_all?
by CANELA-XANDRI Oriol 20 May '14

20 May '14

I am writing on a sshfs... Now, I tried on the 'local' disk (I am inside a virtual machine) and there seems that works ok. So, the problem is related with the sshfs? Oriol -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -----Original Message----- From: discuss-bounces(a)mpich.org [mailto:[email protected]] On Behalf Of Rajeev Thakur Sent: 20 May 2014 13:58 To: discuss(a)mpich.org Subject: Re: [mpich-discuss] bug in MPI_File_write_all? Are you writing to an NFS file system or local disk? Rajeev On May 20, 2014, at 7:09 AM, CANELA-XANDRI Oriol <Oriol.CAnela-Xandri(a)roslin.ed.ac.uk> wrote: > Hi, I have tested with the last version I have found (mpich-master-v3.1-248-g6732f002). It is strange, the first time I have tried everything have been ok, then I have tried to increment the number of iterations (repeat<40) and then the test failed again. I have run several times the test code and now it seems a little bit more robust (I do not know if this makes sense, but seems that need more iterations to fail. I do not check statistically, this could be only an impression), but fails. > > Oriol > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -----Original Message----- > From: discuss-bounces(a)mpich.org [mailto:[email protected]] On > Behalf Of Rajeev Thakur > Sent: 19 May 2014 17:05 > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] bug in MPI_File_write_all? > > The program works on my Mac laptop with the latest MPICH source. Can you try with the latest nightly snapshot of MPICH from here: > http://www.mpich.org/static/downloads/nightly/master/mpich/ > > Rajeev > > On May 19, 2014, at 4:49 AM, CANELA-XANDRI Oriol <Oriol.CAnela-Xandri(a)roslin.ed.ac.uk> wrote: > >> Yes, a attach below a test program. The error can be reproduced running it with 9 MPI threads. >> >> #include <mpi.h> >> >> #include <iostream> >> #include <sstream> >> #include <string> >> #include <vector> >> >> /** >> * get the number of local rows and columns */ int getNumroc(int >> globalSize, int myProc, int nProcs, int blockSize) { int myDist = >> myProc % nProcs; int nBlocks = globalSize / blockSize; int numroc = >> nBlocks / nProcs; numroc *= blockSize; int extraBlocks = nBlocks % >> nProcs; if(myDist < extraBlocks) { >> numroc += blockSize; >> } >> else if(myDist == extraBlocks) >> { >> numroc += globalSize % blockSize; >> } >> return numroc; >> } >> >> int main(int argc, char **argv) >> { >> //MPI vars >> bool mpiRoot; >> int mpiRank; >> int mpiNumTasks; >> char hostName[MPI_MAX_PROCESSOR_NAME]; int lenHostName; int >> myProcRow; int myProcCol; >> >> // Initiate MPI >> int tmp; >> tmp = MPI_Init(&argc, &argv); >> if (tmp != MPI_SUCCESS) { >> std::cerr << "Error: MPI can not be started. Terminating." << std::endl; >> MPI_Abort(MPI_COMM_WORLD, 1); >> } >> MPI_Comm_rank(MPI_COMM_WORLD, &mpiRank); >> MPI_Comm_size(MPI_COMM_WORLD, &mpiNumTasks); >> MPI_Get_processor_name(hostName, &lenHostName); >> >> if(mpiNumTasks != 9) >> { >> std::cerr << "Error: This is a test program designed for running with 9 threads." << std::endl; >> MPI_Abort(MPI_COMM_WORLD, 1); >> } >> >> //Id of the process in a 2d grid >> myProcRow = mpiRank / 3; >> myProcCol = mpiRank % 3; >> >> double *m; ///<A pointer to the distributed matrix >> double *mRead; ///<A pointer to the distributed matrix >> >> int nGlobRows = 5; ///<Number of rows of the global matrix >> int nGlobCols = 4; ///<Number of columns of the global matrix >> int nRows; ///<Number of rows of the local matrix >> int nCols; ///<Number of columns of the local matrix >> int nBlockRows = 1; ///<Number of rows of the distributed matrix blocks >> int nBlockCols = 3; ///<Number of columns of the distributed matrix blocks >> >> nRows = getNumroc(nGlobRows, myProcRow, 3, nBlockRows); nCols = >> getNumroc(nGlobCols, myProcCol, 3, nBlockCols); >> >> m = new double[nRows*nCols]; >> mRead = new double[nRows*nCols]; >> for(int i = 0; i < nRows; i++) >> { >> for(int j = 0; j < nCols; j++) >> { >> m[i*nCols + j] = 1; >> } >> } >> >> for(int repeat = 0; repeat < 10; repeat++) { >> int dims[] = {nGlobRows, nGlobCols}; >> int dargs[] = {nBlockRows, nBlockCols}; >> int distribs[] = {MPI_DISTRIBUTE_CYCLIC, MPI_DISTRIBUTE_CYCLIC}; >> int dim[] = {3, 3}; >> char nat[] = "native"; >> int rc; >> MPI_Datatype dcarray; >> MPI_File cFile; >> MPI_Status status; >> >> MPI_Type_create_darray(mpiNumTasks, mpiRank, 2, dims, distribs, dargs, dim, MPI_ORDER_FORTRAN, MPI_DOUBLE, &dcarray); >> MPI_Type_commit(&dcarray); >> >> std::stringstream ss; >> ss << "test_" << repeat << ".bin"; >> std::string fname = ss.str(); //"test.bin"; >> std::vector<char> fn(fname.begin(), fname.end()); >> fn.push_back('\0'); >> MPI_File_delete (&fn[0], MPI_INFO_NULL); >> >> //Write file >> rc = MPI_File_open(MPI_COMM_WORLD, &fn[0], MPI_MODE_EXCL | MPI_MODE_CREATE | MPI_MODE_WRONLY, MPI_INFO_NULL, &cFile); >> if(rc){ >> std::cerr << "Error: Failed to open file." << std::endl; >> MPI_Abort(MPI_COMM_WORLD, 1); >> } >> else >> { >> MPI_File_set_view(cFile, 0, MPI_DOUBLE, dcarray, nat, MPI_INFO_NULL); >> MPI_File_write_all(cFile, m, nRows*nCols, MPI_DOUBLE, &status); >> } >> MPI_Barrier(MPI_COMM_WORLD); >> MPI_File_close(&cFile); >> >> >> //Initialize matrix before reading to 0; >> for(int i = 0; i < nRows; i++) >> { >> for(int j = 0; j < nCols; j++) >> { >> mRead[i*nCols + j] = 0; >> } >> } >> //Read file >> rc = MPI_File_open(MPI_COMM_WORLD, &fn[0], MPI_MODE_RDONLY, MPI_INFO_NULL, &cFile); >> if(rc){ >> std::cerr << "Error: Failed to open file." << std::endl; >> MPI_Abort(MPI_COMM_WORLD, 1); >> } >> else >> { >> MPI_File_set_view(cFile, 0, MPI_DOUBLE, dcarray, nat, MPI_INFO_NULL); >> MPI_File_read_all(cFile, mRead, nRows*nCols, MPI_DOUBLE, &status); >> } >> MPI_Barrier(MPI_COMM_WORLD); >> MPI_File_close(&cFile); >> MPI_Type_free(&dcarray); >> >> //Check data >> for(int i = 0; i < nRows; i++) >> { >> for(int j = 0; j < nCols; j++) >> { >> if(mRead[i*nCols + j] != 1) >> { >> std::cerr << "Error in data. " << repeat << " iteration." << std::endl; >> MPI_Abort(MPI_COMM_WORLD, 1); >> } >> } >> } >> } >> >> delete [] m; >> delete [] mRead; >> >> return 0; >> } >> >> Oriol >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> -----Original Message----- >> From: discuss-bounces(a)mpich.org [mailto:[email protected]] On >> Behalf Of Rajeev Thakur >> Sent: 16 May 2014 20:22 >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] bug in MPI_File_write_all? >> >> Can you send us a small test program that can be compiled and run? >> >> Rajeev >> >> >> On May 16, 2014, at 11:42 AM, CANELA-XANDRI Oriol <Oriol.CAnela-Xandri(a)roslin.ed.ac.uk> wrote: >> >>> I also tried with the 3.0.4 (for which I have a distribution package) version with same results. If you think the result could change with 3.1, I will try with it. >>> >>> Oriol >>> >>> >>> -- >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> >>> -----Original Message----- >>> From: discuss-bounces(a)mpich.org [mailto:[email protected]] >>> On Behalf Of Rajeev Thakur >>> Sent: 16 May 2014 17:14 >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] bug in MPI_File_write_all? >>> >>> 1.4.1 is a very old version of MPICH. Can you try with the latest release, 3.1? >>> >>> Rajeev >>> >>> On May 16, 2014, at 8:50 AM, CANELA-XANDRI Oriol <Oriol.CAnela-Xandri(a)roslin.ed.ac.uk> wrote: >>> >>>> Hello, >>>> >>>> I am writing a function for storing a block cyclic distributed array using MPI_Type_create_darray, MPI_File_set_view, and MPI_File_write_all functions. After some testing I found that for some particular cases, sometimes, some of the values of the array have been not stored properly on the file. The error seems random, but always affects the same number in the same position (where instead of a number, there is a nan, it seems that the position is not written). I tried with other implementations (e.g. openmpi) and seems everything works well (I am using MPICH2 Version 1.4.1). >>>> >>>> For instance, I saw the error for a matrix with 5 rows and 4 columns. Block size for rows = 1 and for columns = 3. There are 9 MPI processes distributed in a 3x3 array. My function is (where nBlockRows/nBlockCols define the size of the blocks, nGlobRows/nGlobCols define the global size of the matrix, nProcRows/nProcCols define the dimensions of the process grid, and fname is the name of the file.): >>>> >>>> void Matrix::writeMatrixMPI(std::string fname) { int dims[] = >>>> {this->nGlobRows, this->nGlobCols}; int dargs[] = >>>> {this->nBlockRows, >>>> this->nBlockCols}; int distribs[] = {MPI_DISTRIBUTE_CYCLIC, >>>> MPI_DISTRIBUTE_CYCLIC}; int dim[] = {communicator->nProcRows, >>>> communicator->nProcCols}; char nat[] = "native"; int rc; >>>> MPI_Datatype dcarray; MPI_File cFile; MPI_Status status; >>>> >>>> MPI_Type_create_darray(communicator->mpiNumTasks, >>>> communicator->mpiRank, 2, dims, distribs, dargs, dim, >>>> MPI_ORDER_FORTRAN, MPI_DOUBLE, &dcarray); >>>> MPI_Type_commit(&dcarray); >>>> >>>> std::vector<char> fn(fname.begin(), fname.end()); >>>> fn.push_back('\0'); rc = MPI_File_open(MPI_COMM_WORLD, &fn[0], >>>> MPI_MODE_EXCL | MPI_MODE_CREATE | MPI_MODE_WRONLY, MPI_INFO_NULL, >>>> &cFile); if(rc){ ss << "Error: Failed to open file: " << rc; >>>> misc.error(ss.str(), 0); } else { MPI_File_set_view(cFile, 0, >>>> MPI_DOUBLE, dcarray, nat, MPI_INFO_NULL); >>>> MPI_File_write_all(cFile, this->m, this->nRows*this->nCols, MPI_DOUBLE, &status); >>>> } >>>> MPI_File_close(&cFile); >>>> MPI_Type_free(&dcarray); >>>> } >>>> >>>> If I call the function a repeated number of times without deleting the file between calls, the file seems to be always correct. If I delete the file between calls or create a file with a different name each time, then I see the error in some of the files. The error is a nan always in the same position. For me it is very strange, but as I said, with other implementations, I do not have the problem. >>>> >>>> -- >>>> The University of Edinburgh is a charitable body, registered in >>>> Scotland, with registration number SC005336. >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ > 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

Value of fortran communicator handles
by marco restelli 20 May '14

20 May '14

Hi, I noticed that the attached fortran code produces this output: $ mpiexec -n 4 -l ./mpitest [0] color = 1 ; newcomm = -2080374780 [1] color = 1 ; newcomm = -2080374782 [2] color = 2 ; newcomm = -2080374782 [3] color = 2 ; newcomm = -2080374782 I know that I am not supposed to use the values of the communicator handles, but I was surprised to see that two processors in the same communicator have two different values for such an handle. More precisely, I was assuming that newcomm had one value on procs 0 and 1 and another value on 2 and 3. So my question is whether this is the expected behaviour or not. (In fact, I need to debug another problem in my code and I wonder whether this could be related or not). Thank you, Marco mpich: version 1.5 gfortran: 4.7.3 program mpitest implicit none include "mpif.h" integer :: key, color, newcomm, mpi_id, ierr call mpi_init(ierr) call mpi_comm_rank(mpi_comm_world,mpi_id,ierr) key = 1 ! same ordering as in comm select case(mpi_id) case(0) color = 1 case(1) color = 1 case(2) color = 2 case(3) color = 2 end select call mpi_comm_split( mpi_comm_world , color,key , newcomm , ierr) write(*,*) "color = ",color, "; newcomm = ",newcomm call mpi_finalize(ierr) end program mpitest

1 0