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

Re: [mpich-discuss] Use of Signed-off-by in MPICH
by Pavan Balaji 04 Jan '14

04 Jan '14

Please use devel(a)mpich.org for developer oriented discussion. We use signoff as a way to get a second confirmation on the correctness of the patch. In some cases, multiple confirmations. There’s also a "silent signoff” done by the jenkins testing before things are merged into mpich/master. — Pavan On Jan 4, 2014, at 7:55 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > I'm confused by the current use of Signed-off-by tags in MPICH. Is this > intended to be a developer's certificate of origin (DCO) following the > model of the Linux kernel [1]? I can't tell if IBM is using it that > way, where Michael Blocksome is the one authorized by IBM to assert on > IBM's behalf that the work has clean IP and may be distributed under the > MPICH license. But what does this mean? > > commit 87b20136ac20a0fbcffd8e29edcc500fcebbfc22 > Author: Pavan Balaji <balaji(a)mcs.anl.gov> > AuthorDate: Wed Jan 1 19:33:36 2014 -0600 > Commit: Pavan Balaji <balaji(a)mcs.anl.gov> > CommitDate: Thu Jan 2 15:39:07 2014 -0600 > > Move default eager threshold setting to ch3. > > We were setting the default eager threshold inside nemesis, instead of > in ch3. This was causing other ch3 channels, notably sock, to get a > garbage default value for the eager threshold. > > Signed-off-by: Wesley Bland <wbland(a)mcs.anl.gov> > > > If this were a DCO, we would interpret it as meaning that Wesley is the > one certifying the IP, but Pavan is the author. > > Or is Signed-off-by being used where Reviewed-by would be more > appropriate? > > > [1] https://www.kernel.org/doc/Documentation/SubmittingPatches > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

questiones related to MPICH3 on Mac
by Feng Xiao 04 Jan '14

04 Jan '14

hi there, I am installing MPICH3 on Mac. Because my fortran code is big and so prefer to use a IDE. I installed Xcode, and will install Intel Fortran. I will use IDE to edit the codes, but compile the code on Mac terminal. I have MPI coding experience on both Linux and Windows, but eventually got used to Intel Fortran and MPI windows installation for development and debugging, and transferring source codes to a linux cluster for production. 0) The download of MPICH 3.0.4 contains windows related files, can I run MPICH 3.0.4 on windows? although the MPICH site states the windows package has MPICH1 as base model. IF MPICH3 doesn't support windows, I am going to use Mac 1) I don't know if this is too troublesome to install Intel Fortran just because I want a IDE, any other good fortran IDE on Mac? 2) Intel MPI and OpenMPI (it is said it comes with Mac OS) are also MPI standard complaints, I guess the latest versions of them should have most features of MPICH3? Such as neighborhood collectives and topology aware communicator? Thanks. -- Feng Xiao Doctoral Student Petroleum Engineering Colorado School of Mines Cell 918-814-2644

1 0

build broken on 'master': 'mpitypedefs.h' file not found
by Jed Brown 04 Jan '14

04 Jan '14

Rob, this commit does not build, at least not if you configure out of source. commit 3146e104017114b0e9a7e04824cfeb7383155d12 Author: Rob Latham <robl(a)mcs.anl.gov> Date: Fri Jan 3 12:35:21 2014 -0600 bring back include file needed for MPI_AINT_CAST_TO_VOID_PTR In romio-standalone fixes, I zapped the inclusion of mpitypedefs.h, but the "ensure this large value fits into pointer without overflowing" check relied on some MPICH-internal macros/routines. Only Blue Gene driver uses those routines, so nightly tests didn't flag it. No reviewer. diff --git a/src/mpi/romio/adio/include/adioi.h b/src/mpi/romio/adio/include/adioi.h index ea07491..0553dfb 100644 --- a/src/mpi/romio/adio/include/adioi.h +++ b/src/mpi/romio/adio/include/adioi.h @@ -824,6 +824,7 @@ int ADIOI_MPE_iwrite_b; /* Use MPID_Ensure_Aint_fits_in_pointer from mpiutil.h and MPI_AINT_CAST_TO_VOID_PTR from configure (mpi.h) */ #include "glue_romio.h" + #include "mpitypedefs.h" /* for MPI_AINT_CAST_TO_VOID_PTR */ #define ADIOI_AINT_CAST_TO_VOID_PTR (void*)(MPIR_Pint) /* The next two casts are only used when you don't want sign extension /bin/sh ./libtool --tag=CC --mode=compile clang -DHAVE_CONFIG_H -I. -I../../../../src/mpi/romio -I./adio/include -I/home/jed/src/mpich/build-clang/src/include -I./include -I../../../../src/mpi/romio/include -I./mpi-io -I../../../../src/mpi/romio/mpi-io -I./adio/include -I../../../../src/mpi/romio/adio/include -I/home/jed/src/mpich/build-clang/src/mpl/include -I/home/jed/src/mpich/src/mpl/include -I/home/jed/src/mpich/src/openpa/src -I/home/jed/src/mpich/build-clang/src/openpa/src -I/home/jed/src/mpich/build-clang/src/mpi/romio/include -O2 -DFORTRANUNDERSCORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_ROMIOCONF_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT mpi-io/close.lo -MD -MP -MF $depbase.Tpo -c -o mpi-io/close.lo ../../../../src/mpi/romio/mpi-io/close.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: clang -DHAVE_CONFIG_H -I. -I../../../../src/mpi/romio -I./adio/include -I/home/jed/src/mpich/build-clang/src/include -I./include -I../../../../src/mpi/romio/include -I./mpi-io -I../../../../src/mpi/romio/mpi-io -I./adio/include -I../../../../src/mpi/romio/adio/include -I/home/jed/src/mpich/build-clang/src/mpl/include -I/home/jed/src/mpich/src/mpl/include -I/home/jed/src/mpich/src/openpa/src -I/home/jed/src/mpich/build-clang/src/openpa/src -I/home/jed/src/mpich/build-clang/src/mpi/romio/include -O2 -DFORTRANUNDERSCORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_ROMIOCONF_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT mpi-io/close.lo -MD -MP -MF mpi-io/.deps/close.Tpo -c ../../../../src/mpi/romio/mpi-io/close.c -fPIC -DPIC -o mpi-io/.libs/close.o In file included from ../../../../src/mpi/romio/mpi-io/close.c:8: In file included from ../../../../src/mpi/romio/mpi-io/mpioimpl.h:15: In file included from ../../../../src/mpi/romio/adio/include/adio.h:440: ../../../../src/mpi/romio/adio/include/adioi.h:827:12: fatal error: 'mpitypedefs.h' file not found #include "mpitypedefs.h" /* for MPI_AINT_CAST_TO_VOID_PTR */ ^ 1 error generated. Now my understanding is that ROMIO is still supposed to be buildable outside the MPI source tree, in which case src/include/mpitypedefs.h will not be available. I don't know how you want to fix this.

1 0

Use of Signed-off-by in MPICH
by Jed Brown 04 Jan '14

04 Jan '14

I'm confused by the current use of Signed-off-by tags in MPICH. Is this intended to be a developer's certificate of origin (DCO) following the model of the Linux kernel [1]? I can't tell if IBM is using it that way, where Michael Blocksome is the one authorized by IBM to assert on IBM's behalf that the work has clean IP and may be distributed under the MPICH license. But what does this mean? commit 87b20136ac20a0fbcffd8e29edcc500fcebbfc22 Author: Pavan Balaji <balaji(a)mcs.anl.gov> AuthorDate: Wed Jan 1 19:33:36 2014 -0600 Commit: Pavan Balaji <balaji(a)mcs.anl.gov> CommitDate: Thu Jan 2 15:39:07 2014 -0600 Move default eager threshold setting to ch3. We were setting the default eager threshold inside nemesis, instead of in ch3. This was causing other ch3 channels, notably sock, to get a garbage default value for the eager threshold. Signed-off-by: Wesley Bland <wbland(a)mcs.anl.gov> If this were a DCO, we would interpret it as meaning that Wesley is the one certifying the IP, but Pavan is the author. Or is Signed-off-by being used where Reviewed-by would be more appropriate? [1] https://www.kernel.org/doc/Documentation/SubmittingPatches

1 0

Re: [mpich-discuss] Potentially odd memory behavior in MPI_Waitall
by John Grime 04 Jan '14

04 Jan '14

Hi Ken, I tried again to create a minimal demonstration, and I think I now have such an example. Code attached. Notes: - Each MPI rank creates its own log file to print results to, for easy examination of data from the different processes. - The “BufferExchange” object is designed for easy sharing of arbitrary data buffers between a specified set of peer ranks. - I added memory check code around various aspects of the buffer exchanges ( see BufferExchange::FullExchange() ), and I print the memory changes at the end of each FullExchange() call (these are in KB on OSX). - The most interesting value is “final_waitall”, the measured resident set memory increase due to calling the final MPI_Waitall() ( see BufferExchange::FullExchange() ). - I tested both fixed-size buffers, and variable-sized buffers (either 100 integers per buffer, or buffers of the same size as the loop iteration number) - The memory increases seem to be nondeterministic: running the same program several times gives me different values. I think this might suggest it’s due to the OS. I built and ran the example using: mpicxx -Wall -Wextra base.cpp BufferExchange.cpp main.cpp mpiexec -np 4 ./a.out … and the output files were therefore “log.0” to “log.3”. Apologies for any obvious bugs in the code , it was something of a rush job. Cheers, J. On Jan 2, 2014, at 9:53 PM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > Can you provide a minimal demonstration of this behavior? That way we can work from the same reference point to identify possible causes. > > On 01/01/2014 03:05 PM, John Grime wrote: >> Hi all, >> >> I was wondering if someone could help me out with trying to understand what’s gong on with an MPI_Waitall() call with regards to resident set memory usage. Platform information at the end of the email. >> >> If I run a 4 process MPI job on my desktop machine, I get a steady increase in memory usage over the course of the program. Apart from the places where I would reasonably expect expect memory usage to increase, I also see regular increases when I call MPI_Waitall(). >> >> I measure this behavior via: >> >> getmem( &rss0, &vs ); >> >> result = MPI_Waitall( n_buffer_reqs, buffer_reqs, MPI_STATUSES_IGNORE ); >> if( result != MPI_SUCCESS ) ERROR_MACRO( "MPI_Waitall" ); >> >> getmem( &rss1, &vs ); >> >> … where getmem() queries the OS kernel to return the resident set size (“rss") and virtual memory size (“vs", ignored). The getmem() function does not allocate any memory itself, so I can hopefully see any difference in the resident set memory used before and after the MPI_Waitall() call via (rss1-rss0). >> >> After MPI_Waitall() returns, I very often see an increase in the resident set size ranging from 4096 bytes to 65536 bytes. >> >> Running an “identical” 4-process job on a single node of the Blue Waters compute cluster (Cray XE system, GCC 4.8.1, Cray mpich 6.0.1) does not seem to produce this behaviour. >> >> Switching the MPI_Waitall() for a loop over MPI_Waitany() calls also produces resident set increases. >> >> Does anyone have any comments or suggestions as to how I might understand whether this behavior is errant, and how I might track down the cause? It’s irritating me as I’d really like to produce code with as low a memory overhead as possible! >> >> Cheers, >> >> J. >> >> ------------------ >> Platform info: >> ------------------ >> >> OS: Apple OSX 10.9.1 >> >> mpicxx —version: >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> Target: x86_64-apple-darwin13.0.0 >> Thread model: posix >> >> mpiexec —version >> >> HYDRA build details: >> Version: 3.0.4 >> Release Date: Wed Apr 24 10:08:10 CDT 2013 >> CC: /usr/bin/clang -pipe -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 >> CXX: /usr/bin/clang++ -pipe -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 >> F77: /opt/local/bin/gfortran-mp-4.8 -pipe -m64 -Wl,-headerpad_max_install_names -arch x86_64 >> F90: /opt/local/bin/gfortran-mp-4.8 -pipe -m64 -Wl,-headerpad_max_install_names -arch x86_64 >> Configure options: '--disable-option-checking' '--prefix=/opt/local' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-base-cache' '--enable-cache' '--enable-cxx' '--enable-fast=O2' '--enable-shared' '--enable-smpcoll' '--with-device=ch3:nemesis' '--with-pm=hydra' '--with-thread-package=posix' '--enable-versioning' 'F90FLAGS=' 'F90=' '--enable-timer-type=mach_absolute_time' '--libdir=/opt/local/lib/mpich-mp' '--sysconfdir=/opt/local/etc/mpich-mp' '--program-suffix=-mp' '--enable-f77' '--enable-fc' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -arch x86_64 -O2' 'LDFLAGS=-Wl,-headerpad_max_install_names -arch x86_64 ' 'CXX=/usr/bin/clang++' 'CXXFLAGS=-pipe -arch x86_64 -O2' 'F77=/opt/local/bin/gfortran-mp-4.8' 'FFLAGS=-pipe -m64 -O2' 'FC=/opt/local/bin/gfortran-mp-4.8' 'FCFLAGS=-pipe -m64 -O2' '--cache-file=/dev/null' '--srcdir=.' 'LIBS=-lpthread ' 'CPPFLAGS= -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4 > /src/mpl/include -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/mpl/include -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/openpa/src -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/openpa/src -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/mpi/romio/include' >> Process Manager: pmi >> Launchers available: ssh rsh fork slurm ll lsf sge manual persist >> Topology libraries available: hwloc >> Resource management kernels available: user slurm ll lsf sge pbs cobalt >> Checkpointing libraries available: >> Demux engines available: poll select >> >> _______________________________________________ >> 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] Potentially odd memory behavior in MPI_Waitall
by John Grime 04 Jan '14

04 Jan '14

Hi Ken, I tried to generate such an example, but unfortunately I could’t capture the behavior. That would most likely indicate the problem is with my code, rather than MPICH, but I was curious as the behavior does not seem to manifest on other platforms. I previously ran the code through valgrind without detecting any obvious memory leaks etc (valgrind is not currently working for OSX 10.9, alas). As the additional memory use seemed to mainly appear through the MPI_Waitall() / Waitany() calls, my guess was that temporary buffers were allocated though these calls and some sort of memory fragmentation prevented fitting them into the previously free’d blocks in the underlying allocator, so progressively more memory was being attached to the process. I took a look at the current MPICH source code, and e.g. MPIR_Waitall_impl() seems to use a fixed-size stack-allocated array for the requests, allocating a larger array if more than 16 requests are used (the default value for MPID_REQUEST_PTR_ARRAY_SIZE seems to be 16). I’m using 12 requests, so I should be okay there. This is probably not a big deal. It could also be due to how I determine the process memory usage ( via the task_info() routine of the Mach kernel, in case anyone is curious ), as OSX 10.9 can do weird things behind the scenes with dynamic compression of memory. Fundamentally, I was curious to know if anyone else had observed this sort of behaviour and if there was a fairly straightforward explanation for it, even bearing in mind the obvious difficulties in making definitive statements when dealing with something as potentially complicated as different memory allocators on different platforms. Cheers, J. On Jan 2, 2014, at 9:53 PM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > Can you provide a minimal demonstration of this behavior? That way we can work from the same reference point to identify possible causes. > > On 01/01/2014 03:05 PM, John Grime wrote: >> Hi all, >> >> I was wondering if someone could help me out with trying to understand what’s gong on with an MPI_Waitall() call with regards to resident set memory usage. Platform information at the end of the email. >> >> If I run a 4 process MPI job on my desktop machine, I get a steady increase in memory usage over the course of the program. Apart from the places where I would reasonably expect expect memory usage to increase, I also see regular increases when I call MPI_Waitall(). >> >> I measure this behavior via: >> >> getmem( &rss0, &vs ); >> >> result = MPI_Waitall( n_buffer_reqs, buffer_reqs, MPI_STATUSES_IGNORE ); >> if( result != MPI_SUCCESS ) ERROR_MACRO( "MPI_Waitall" ); >> >> getmem( &rss1, &vs ); >> >> … where getmem() queries the OS kernel to return the resident set size (“rss") and virtual memory size (“vs", ignored). The getmem() function does not allocate any memory itself, so I can hopefully see any difference in the resident set memory used before and after the MPI_Waitall() call via (rss1-rss0). >> >> After MPI_Waitall() returns, I very often see an increase in the resident set size ranging from 4096 bytes to 65536 bytes. >> >> Running an “identical” 4-process job on a single node of the Blue Waters compute cluster (Cray XE system, GCC 4.8.1, Cray mpich 6.0.1) does not seem to produce this behaviour. >> >> Switching the MPI_Waitall() for a loop over MPI_Waitany() calls also produces resident set increases. >> >> Does anyone have any comments or suggestions as to how I might understand whether this behavior is errant, and how I might track down the cause? It’s irritating me as I’d really like to produce code with as low a memory overhead as possible! >> >> Cheers, >> >> J. >> >> ------------------ >> Platform info: >> ------------------ >> >> OS: Apple OSX 10.9.1 >> >> mpicxx —version: >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> Target: x86_64-apple-darwin13.0.0 >> Thread model: posix >> >> mpiexec —version >> >> HYDRA build details: >> Version: 3.0.4 >> Release Date: Wed Apr 24 10:08:10 CDT 2013 >> CC: /usr/bin/clang -pipe -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 >> CXX: /usr/bin/clang++ -pipe -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 >> F77: /opt/local/bin/gfortran-mp-4.8 -pipe -m64 -Wl,-headerpad_max_install_names -arch x86_64 >> F90: /opt/local/bin/gfortran-mp-4.8 -pipe -m64 -Wl,-headerpad_max_install_names -arch x86_64 >> Configure options: '--disable-option-checking' '--prefix=/opt/local' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-base-cache' '--enable-cache' '--enable-cxx' '--enable-fast=O2' '--enable-shared' '--enable-smpcoll' '--with-device=ch3:nemesis' '--with-pm=hydra' '--with-thread-package=posix' '--enable-versioning' 'F90FLAGS=' 'F90=' '--enable-timer-type=mach_absolute_time' '--libdir=/opt/local/lib/mpich-mp' '--sysconfdir=/opt/local/etc/mpich-mp' '--program-suffix=-mp' '--enable-f77' '--enable-fc' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -arch x86_64 -O2' 'LDFLAGS=-Wl,-headerpad_max_install_names -arch x86_64 ' 'CXX=/usr/bin/clang++' 'CXXFLAGS=-pipe -arch x86_64 -O2' 'F77=/opt/local/bin/gfortran-mp-4.8' 'FFLAGS=-pipe -m64 -O2' 'FC=/opt/local/bin/gfortran-mp-4.8' 'FCFLAGS=-pipe -m64 -O2' '--cache-file=/dev/null' '--srcdir=.' 'LIBS=-lpthread ' 'CPPFLAGS= -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4 > /src/mpl/include -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/mpl/include -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/openpa/src -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/openpa/src -I/opt/local/var/macports/build/_opt_mports_dports_science_mpich/mpich-default/work/mpich-3.0.4/src/mpi/romio/include' >> Process Manager: pmi >> Launchers available: ssh rsh fork slurm ll lsf sge manual persist >> Topology libraries available: hwloc >> Resource management kernels available: user slurm ll lsf sge pbs cobalt >> Checkpointing libraries available: >> Demux engines available: poll select >> >> _______________________________________________ >> 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] error recieving
by Gustavo Correa 03 Jan '14

03 Jan '14

Was the runtime error a segmentation fault? Apparently your recv_buff is too small. On Jan 3, 2014, at 2:35 AM, Soheil Hooshdaran wrote: > Hi. > What's wrong with my code? > • char send_buf[12] = "hello world"; > • char send_buf2[12] = "hello iran"; > • char recv_buf[10]; > • int i; > • for(i=0;i<10;++i) > • if (world_rank == 0) { > • MPI_Send(send_buf, 12, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > • //MPI_Send(send_buf2, 12, MPI_INT, 1, 1, MPI_COMM_WORLD); > • } else if (world_rank == 1) { > • MPI_Recv(recv_buf, 12, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > • printf("Process 1 received %s from process 0\n", recv_buf); > • } > > Run-time errors are very hard to fix!Help me please > > Thanks in advance > Soheil Hooshdaran > _______________________________________________ > 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] How to use bind-to core
by Kenneth Raffenetti 03 Jan '14

03 Jan '14

If you wanted to bind each process to 1 core in a round-robin fashion, you would use mpiexec.hydra -ppn 5 -bind-to core Or if your cores have 1 hwthread each, you could use mpiexec.hydra -ppn 5 -bind-to rr To bind all processes to a single core, you would need to specify a user binding, such as mpiexec.hydra -ppn 5 -bind-to user:1,1,1,1,1 That tells hydra to bind each of the 5 processes to core 1. However there is a bug in hydra that will cause an error in the second example when the number of bindings specified is > the number of hwthreads on your machine. It should be fixed in the upcoming mpich 3.1 release. We will also be adding some more process binding examples to the mpich wiki in the near future. Ken On 01/03/2014 01:49 PM, Z.Rahmani wrote: > To whom it may concern, > > I have an MPI code with 5 ranks and I use a 4-core processor, I want to > process my code on the machine with every probable state of assigning > each process on each core of CPU. I mean , for example , one time all of > process run on 1core, next time each process run on each core of 4-core > CPU and so on. > > I used " mpiexec.hydra -ppn 5 -bind-to core:4" to run first process on > first core, 2nd process on 2nd core, 3rd process on 3rd core , .... > > It would be appreciated if correct me. > > Kind Regards, > Zahra > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

How to use bind-to core
by Z.Rahmani 03 Jan '14

03 Jan '14

To whom it may concern, I have an MPI code with 5 ranks and I use a 4-core processor, I want to process my code on the machine with every probable state of assigning each process on each core of CPU. I mean , for example , one time all of process run on 1core, next time each process run on each core of 4-core CPU and so on. I used " mpiexec.hydra -ppn 5 -bind-to core:4" to run first process on first core, 2nd process on 2nd core, 3rd process on 3rd core , .... It would be appreciated if correct me. Kind Regards, Zahra

1 0

Re: [mpich-discuss] error recieving
by Wesley Bland 03 Jan '14

03 Jan '14

What error are you seeing? Is this the complete code? For instance, you never call MPI_Init or finalize here. > On Jan 3, 2014, at 1:35 AM, Soheil Hooshdaran <shooshdaran577(a)gmail.com> wrote: > > Hi. > What's wrong with my code? > char send_buf[12] = "hello world"; > char send_buf2[12] = "hello iran"; > char recv_buf[10]; > int i; > for(i=0;i<10;++i) > if (world_rank == 0) { > MPI_Send(send_buf, 12, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > //MPI_Send(send_buf2, 12, MPI_INT, 1, 1, MPI_COMM_WORLD); > } else if (world_rank == 1) { > MPI_Recv(recv_buf, 12, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > printf("Process 1 received %s from process 0\n", recv_buf); > } > > Run-time errors are very hard to fix!Help me please > > Thanks in advance > Soheil Hooshdaran > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0