August 2017 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] About an error while using mpi i/o collectives : "Error in ADIOI_Calc_aggregator(): rank_index(1)..."
by Thakur, Rajeev 22 Aug '17

22 Aug '17

Yes, displacements for the filetype must be in “monotonically nondecreasing order”. Rajeev > On Aug 22, 2017, at 3:05 PM, pramod kumbhar <pramod.s.kumbhar(a)gmail.com> wrote: > > Hi Rob, > > Thanks! Below is not exactly same issue/error but related : > > While constructing derived datatype (filetype used for set_view), do we need displacements / offsets to be in ascending order? > I mean, suppose I am creating derived datatype using MPI_Type_create_hindexed (or mpi struct) with length/displacements as: > > blocklengths[0] = 8; > blocklengths[1] = 231670; > blocklengths[2] = 116606; > > displacements[0] = 0; > displacements[1] = 8; > displacements[2] = 231678; > > Above displacements are in ascending order. Suppose I shuffle order bit: > > blocklengths[0] = 8; > blocklengths[1] = 116606; > blocklengths[2] = 231670; > > displacements[0] = 0; > displacements[1] = 231678; > displacements[2] = 8; > > It's still the same but while specifying block-lengths/offsets I changed the order. (resultant file will have data in different oder but that's ignored here) > Isn't this a valid specification? This second example results in a segfault (in ADIO_GEN_WriteStrided / Coll). > > I quickly wrote attached program, let me know if I have missed anything obvious here. > > Regards, > Pramod > > p.s. you can compile & run as: > > Not working => mpicxx test.cpp && mpirun -n 2 ./a.out > Working =>. mpicxx test.cpp -DUSE_ORDER && mpirun -n 2 ./a.out > > > > On Tue, Aug 22, 2017 at 5:25 PM, Latham, Robert J. <robl(a)mcs.anl.gov> wrote: > On Mon, 2017-08-21 at 17:45 +0200, pramod kumbhar wrote: > > Dear All, > > > > In one of our application I am seeing following error while using > > collective call MPI_File_write_all : > > > > Error in ADIOI_Calc_aggregator(): rank_index(1) >= fd->hints- > > >cb_nodes (1) fd_size=102486061 off=102486469 > > > > Non collective version works fine. > > > > While looking at callstack I came across below comment in mpich- > > 3.2/src/mpi/romio/adio/common/ad_aggregate.c : > > > > /* we index into fd_end with rank_index, and fd_end was allocated > > to be no > > * bigger than fd->hins->cb_nodes. If we ever violate that, > > we're > > * overrunning arrays. Obviously, we should never ever hit this > > abort */ > > if (rank_index >= fd->hints->cb_nodes || rank_index < 0) { > > FPRINTF(stderr, "Error in ADIOI_Calc_aggregator(): > > rank_index(%d) >= fd->hints->cb_nodes (%d) fd_size=%lld > > off=%lld\n", > > rank_index,fd->hints->cb_nodes,fd_size,off); > > MPI_Abort(MPI_COMM_WORLD, 1); > > } > > > > I am going to look into application and see if there is an issue with > > offset overflow. But looking at above comment ("Obviously, we should > > never ever hit this abort ") I thought should ask if there is any > > obvious thing I am missing. > > that's my comment. The 'rank_index' array is allocated based on the > 'cb_nodes' hint. I definitely would like to know more about how the > code is manipulating rank_index, cb_nodes, and fd_end . > > If there is a reduced test case you can send me, that will be a huge > help. > > ==rob > > > > > Regards, > > Pramod > > > > p.s. I will provide reproducer after looking into this more > > carefully. > > _______________________________________________ > > 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 > > <test.cpp>_______________________________________________ > 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] Communicator conundrum
by Thakur, Rajeev 22 Aug '17

22 Aug '17

One way to do it is described here: https://trac.mpich.org/projects/mpich/ticket/495 Rajeev > On Aug 22, 2017, at 4:36 PM, Michael L. Stokes <Michael.Stokes(a)uah.edu> wrote: > > I do apologize if this is going to the wrong group so please recommend another group if inappropriate. I do see it as a possible implementation issue. > > I have a main program that spawns an MPI process A, and a second spawn from main that spawns MPI process B. What I need is to create a communicator between processes A and B. I don't see a way to do this with the current implementation. > > I do see a way to do this if the local_comm and the peer_comm arguments in the MPI_Intercomm_create() function called in A and B could be the parent_comm in both processes. Since you can't use the same argument for local_comm and peer_comm in the current implementation, I don't see a path forward. > > Am I missing something here? Is there another way to create a comm between A and B? > > Thanks > Mike > > _______________________________________________ > 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

Communicator conundrum
by Michael L. Stokes 22 Aug '17

22 Aug '17

I do apologize if this is going to the wrong group so please recommend another group if inappropriate. I do see it as a possible implementation issue. I have a main program that spawns an MPI process A, and a second spawn from main that spawns MPI process B. What I need is to create a communicator between processes A and B. I don't see a way to do this with the current implementation. I do see a way to do this if the local_comm and the peer_comm arguments in the MPI_Intercomm_create() function called in A and B could be the parent_comm in both processes. Since you can't use the same argument for local_comm and peer_comm in the current implementation, I don't see a path forward. Am I missing something here? Is there another way to create a comm between A and B? Thanks Mike _______________________________________________ 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] About an error while using mpi i/o collectives : "Error in ADIOI_Calc_aggregator(): rank_index(1)..."
by pramod kumbhar 22 Aug '17

22 Aug '17

Hi Rob, Thanks! Below is not exactly same issue/error but related : While constructing derived datatype (filetype used for set_view), do we need displacements / offsets to be in ascending order? I mean, suppose I am creating derived datatype using MPI_Type_create_hindexed (or mpi struct) with length/displacements as: blocklengths[0] = 8; blocklengths[1] = 231670; blocklengths[2] = 116606; displacements[0] = 0; displacements[1] = 8; displacements[2] = 231678; Above displacements are in ascending order. Suppose I shuffle order bit: blocklengths[0] = 8; blocklengths[1] = 116606; blocklengths[2] = 231670; displacements[0] = 0; displacements[1] = 231678; displacements[2] = 8; It's still the same but while specifying block-lengths/offsets I changed the order. (resultant file will have data in different oder but that's ignored here) Isn't this a valid specification? This second example results in a segfault (in ADIO_GEN_WriteStrided / Coll). I quickly wrote attached program, let me know if I have missed anything obvious here. Regards, Pramod p.s. you can compile & run as: Not working => mpicxx test.cpp && mpirun -n 2 ./a.out Working =>. mpicxx test.cpp -DUSE_ORDER && mpirun -n 2 ./a.out On Tue, Aug 22, 2017 at 5:25 PM, Latham, Robert J. <robl(a)mcs.anl.gov> wrote: > On Mon, 2017-08-21 at 17:45 +0200, pramod kumbhar wrote: > > Dear All, > > > > In one of our application I am seeing following error while using > > collective call MPI_File_write_all : > > > > Error in ADIOI_Calc_aggregator(): rank_index(1) >= fd->hints- > > >cb_nodes (1) fd_size=102486061 off=102486469 > > > > Non collective version works fine. > > > > While looking at callstack I came across below comment in mpich- > > 3.2/src/mpi/romio/adio/common/ad_aggregate.c : > > > > /* we index into fd_end with rank_index, and fd_end was allocated > > to be no > > * bigger than fd->hins->cb_nodes. If we ever violate that, > > we're > > * overrunning arrays. Obviously, we should never ever hit this > > abort */ > > if (rank_index >= fd->hints->cb_nodes || rank_index < 0) { > > FPRINTF(stderr, "Error in ADIOI_Calc_aggregator(): > > rank_index(%d) >= fd->hints->cb_nodes (%d) fd_size=%lld > > off=%lld\n", > > rank_index,fd->hints->cb_nodes,fd_size,off); > > MPI_Abort(MPI_COMM_WORLD, 1); > > } > > > > I am going to look into application and see if there is an issue with > > offset overflow. But looking at above comment ("Obviously, we should > > never ever hit this abort ") I thought should ask if there is any > > obvious thing I am missing. > > that's my comment. The 'rank_index' array is allocated based on the > 'cb_nodes' hint. I definitely would like to know more about how the > code is manipulating rank_index, cb_nodes, and fd_end . > > If there is a reduced test case you can send me, that will be a huge > help. > > ==rob > > > > > Regards, > > Pramod > > > > p.s. I will provide reproducer after looking into this more > > carefully. > > _______________________________________________ > > 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] About an error while using mpi i/o collectives : "Error in ADIOI_Calc_aggregator(): rank_index(1)..."
by Latham, Robert J. 22 Aug '17

22 Aug '17

On Mon, 2017-08-21 at 17:45 +0200, pramod kumbhar wrote: > Dear All, > > In one of our application I am seeing following error while using > collective call MPI_File_write_all : > > Error in ADIOI_Calc_aggregator(): rank_index(1) >= fd->hints- > >cb_nodes (1) fd_size=102486061 off=102486469 > > Non collective version works fine. > > While looking at callstack I came across below comment in mpich- > 3.2/src/mpi/romio/adio/common/ad_aggregate.c : > > /* we index into fd_end with rank_index, and fd_end was allocated > to be no > * bigger than fd->hins->cb_nodes. If we ever violate that, > we're > * overrunning arrays. Obviously, we should never ever hit this > abort */ > if (rank_index >= fd->hints->cb_nodes || rank_index < 0) { > FPRINTF(stderr, "Error in ADIOI_Calc_aggregator(): > rank_index(%d) >= fd->hints->cb_nodes (%d) fd_size=%lld > off=%lld\n", > rank_index,fd->hints->cb_nodes,fd_size,off); > MPI_Abort(MPI_COMM_WORLD, 1); > } > > I am going to look into application and see if there is an issue with > offset overflow. But looking at above comment ("Obviously, we should > never ever hit this abort ") I thought should ask if there is any > obvious thing I am missing. that's my comment. The 'rank_index' array is allocated based on the 'cb_nodes' hint. I definitely would like to know more about how the code is manipulating rank_index, cb_nodes, and fd_end . If there is a reduced test case you can send me, that will be a huge help. ==rob > > Regards, > Pramod > > p.s. I will provide reproducer after looking into this more > carefully. > _______________________________________________ > 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

About an error while using mpi i/o collectives : "Error in ADIOI_Calc_aggregator(): rank_index(1)..."
by pramod kumbhar 21 Aug '17

21 Aug '17

Dear All, In one of our application I am seeing following error while using collective call MPI_File_write_all : Error in ADIOI_Calc_aggregator(): rank_index(1) >= fd->hints->cb_nodes (1) fd_size=102486061 off=102486469 Non collective version works fine. While looking at callstack I came across below comment in mpich-3.2/src/mpi/romio/adio/common/ad_aggregate.c : /* we index into fd_end with rank_index, and fd_end was allocated to be no * bigger than fd->hins->cb_nodes. If we ever violate that, we're ** overrunning arrays. Obviously, we should never ever hit this abort */* if (rank_index >= fd->hints->cb_nodes || rank_index < 0) { FPRINTF(stderr, "Error in ADIOI_Calc_aggregator(): rank_index(%d) >= fd->hints->cb_nodes (%d) fd_size=%lld off=%lld\n", rank_index,fd->hints->cb_nodes,fd_size,off); MPI_Abort(MPI_COMM_WORLD, 1); } I am going to look into application and see if there is an issue with offset overflow. But looking at above comment ("Obviously, we should never ever hit this abort ") I thought should ask if there is any obvious thing I am missing. Regards, Pramod p.s. I will provide reproducer after looking into this more carefully. _______________________________________________ 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] looking for Torque/PBS mailing list of forum
by Halim Amer 21 Aug '17

21 Aug '17

If you have trouble subscribing to the Torque mailing list then you should contact the admins of that list (torqueusers-owner(a)supercluster.org on the link you provided). This mailing list is for MPICH, not for PBS/Torque; we cannot do much to help you. Halim www.mcs.anl.gov/~aamer On 8/17/17 12:45 AM, Peter Biermann wrote: > Dear MPI users, > I have a problem with the Torque/PBS system that I'd like to discuss on > an appropriate mailing list or forum. Can you recommend somewhere to > discuss such topics? > I tried http://www.clusterresources.com/mailman/listinfo/torqueusers, > but it says "You must supply a valid email address." after I filled in > my name and email. > > Thanks > Peter > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > Virenfrei. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > _______________________________________________ > 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

mpich-master: couldn't build libmpicxx.la with Sun C on Linux
by Siegmar Gross 21 Aug '17

21 Aug '17

Hi, I tried to install mpich-master on my "SUSE Linux Enterprise Server 12.2 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6) and gcc-7.1.0. Unfortunately, I couldn't build it with Sun C due to the following error. loki mpich-master_2017-08-20_Linux.x86_64.64_cc 276 tail -18 log.make.Linux.x86_64.64_cc "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect CCLD src/mpi/debugger/libdbginitdummy.la GEN lib/libmpi.la CXX src/binding/cxx/initcxx.lo "./src/include/mpichconf.h", line 1132: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. 1 Warning(s) detected. CXXLD lib/libmpicxx.la CC: -library=Crun cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 CC: -library=Cstd cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 Makefile:9429: recipe for target 'lib/libmpicxx.la' failed make[2]: *** [lib/libmpicxx.la] Error 1 make[2]: Leaving directory '/export2/src/mpich-master/mpich-master_2017-08-20_Linux.x86_64.64_cc' Makefile:34562: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/export2/src/mpich-master/mpich-master_2017-08-20_Linux.x86_64.64_cc' Makefile:9242: recipe for target 'all' failed make: *** [all] Error 2 loki mpich-master_2017-08-20_Linux.x86_64.64_cc 277 I used the following command to configure MPICH. ../mpich/configure \ --prefix=/usr/local/mpich-master_64_cc \ --libdir=/usr/local/mpich-master_64_cc/lib64 \ --includedir=/usr/local/mpich-master_64_cc/include64 \ CC="cc" CXX="CC" F77="f77" FC="f95" \ CFLAGS="-m64" CXXFLAGS="-m64" FFLAGS="-m64" FCFLAGS="-m64" \ LDFLAGS="-m64 -L/usr/lib64 -R/usr/lib64" \ --enable-fortran=ye --enable-cxx --enable-romio \ --enable-debuginfo --enable-smpcoll \ --enable-threads=multiple --with-thread-package=posix \ --enable-shared \ |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_cc Building MPICH caused the following warning with gcc. loki mpich-master_2017-08-20_Linux.x86_64.64_gcc 267 grep -i warning log.make.Linux.x86_64.64_gcc | sort | uniq ../mpich/src/include/mpir_mem.h:144:11: warning: argument 1 value '18446744073709551612' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] loki mpich-master_2017-08-20_Linux.x86_64.64_gcc 268 Building MPICH caused the following warnings with cc. loki mpich-master_2017-08-20_Linux.x86_64.64_cc 270 grep -i warning log.make.Linux.x86_64.64_cc | sort | uniq "../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/src/topology-custom.c", line 88: warning: initializer will be sign-extended: -1 "../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/src/topology-linux.c", line 2727: warning: initializer will be sign-extended: -1 "../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/src/topology-synthetic.c", line 851: warning: initializer will be sign-extended: -1 "../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/src/topology-x86.c", line 122: warning: initializer will be sign-extended: -1 "../../../../../../../../../mpich/src/pm/hydra/tools/topo/hwloc/hwloc/src/topology-xml.c", line 1783: warning: initializer will be sign-extended: -1 "../../../../mpich/src/mpi/romio/adio/common/ad_fstype.c", line 428: warning: statement not reached "../../../../mpich/src/mpi/romio/adio/common/ad_threaded_io.c", line 31: warning: statement not reached "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 103: warning: parameter in inline asm statement unused: %1 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 111: warning: parameter in inline asm statement unused: %1 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 121: warning: parameter in inline asm statement unused: %2 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 129: warning: parameter in inline asm statement unused: %3 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 142: warning: parameter in inline asm statement unused: %1 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 151: warning: parameter in inline asm statement unused: %1 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 159: warning: parameter in inline asm statement unused: %3 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 167: warning: parameter in inline asm statement unused: %3 "../../../../mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 95: warning: parameter in inline asm statement unused: %2 "../../../../mpich/src/pm/hydra/pm/pmiserv/pmiserv_pmi_v1.c", line 796: warning: statement not reached "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/mpi/datatype/dataloop/segment.c", line 658: warning: statement not reached "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 194: warning: assignment type mismatch: "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 195: warning: operands have incompatible pointer types: op "==" "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 196: warning: operands have incompatible pointer types: op "!=" "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 198: warning: argument #2 is incompatible with prototype: "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 198: warning: assignment type mismatch: "../mpich/src/mpid/ch3/channels/nemesis/netmod/tcp/tcp_init.c", line 199: warning: operands have incompatible pointer types: op "==" "../mpich/src/mpid/ch3/channels/nemesis/src/ch3i_comm.c", line 36: warning: statement not reached "../mpich/src/mpid/ch3/channels/nemesis/src/ch3i_comm.c", line 99: warning: statement not reached "./src/include/mpichconf.h", line 1132: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. I would be grateful, if somebody can fix the problem. Do you need anything else? Thank you very much for any help in advance. Kind regards Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

looking for Torque/PBS mailing list of forum
by Peter Biermann 17 Aug '17

17 Aug '17

Dear MPI users, I have a problem with the Torque/PBS system that I'd like to discuss on an appropriate mailing list or forum. Can you recommend somewhere to discuss such topics? I tried http://www.clusterresources.com/mailman/listinfo/torqueusers, but it says "You must supply a valid email address." after I filled in my name and email. Thanks Peter <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virenfrei. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ 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] need help to run hybrid code
by Halim Amer 14 Aug '17

14 Aug '17

If you are running with multiple processes per node, then pass "--bind-to core:6" or "--bind-to hwthread:6" if you have more than one hardware thread per core and you want to map them to OpenMP threads. If your intention is to have only one MPI process per node, then make sure it is the case (e.g., by checking the hostname of each process). Also, I don't understand what you mean by virtual threads, but if you meant over-subscribing the same hardware thread with multiple OpenMP threads, then make sure you have at least 6 hardware threads available for each MPI process and use OpenMP CPU affinity hints (OMP_PROC_BIND for OpenMP >= 4, or GOMP_CPU_AFFINIty/KMP_AFFINITY depending on your compiler). Halim www.mcs.anl.gov/~aamer On 8/14/17 12:14 PM, Pasha Pashaei wrote: > Dear Colleague > Hi > I am working on hybrid MPI -OpenMp code and face with a problem. I can > not run the code as the way that I want. > I can run pure mpi code and also pure openmp code, but not hybrid one. > I used "export OMP_NUM_THREADS=6" and then "mpirun -np 4 ./hybrid.exe > > output.txt" > It run but I noticed that It used only virtual threads of CPUs not > physical threads. > I have both OpenMpi and Mpich on my computer. > My problem is I want to use mpi for communication between nodes and > sockets and Openmp for cores which are inside of sockets and nodes, I do > not know how to pin cpu to each other in each socket and nodes. I could > find some material on internet such as > https://aciref.org/how-to-gain-hybrid-mpi-openmp-code-performance-without-c… > How to gain hybrid MPI-OpenMP code performance without > ...<https://aciref.org/how-to-gain-hybrid-mpi-openmp-code-performance-without-c…> > aciref.org > How to gain hybrid MPI-OpenMP code performance without changing a line > of code a.k.a. dealing with task affinity > But it did not work, I think I need a PBS file to assign those commands > on my grid with qsub command. > If you need more information please let me know. > I am looking forward to hearing from you, > Best regards. > > > Pasha Pashaei > > > > _______________________________________________ > 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