- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPICH 3.3.2 and ch4:ucx launcher
by Raffenetti, Kenneth J. 14 May '20

14 May '20

Sorry, I just read the configure line more closely. Do you have a strict dependency on PMIx? It is not required to run with ch4:ucx. The default process manager (Hydra) supports launching on Slurm clusters out of the box. Ken On 5/14/20, 9:52 AM, "Raffenetti, Kenneth J. via discuss" <discuss(a)mpich.org> wrote: Sorry for the delayed response. Why are you adding --with-pm=no to your configuration? Ken On 5/1/20, 3:20 PM, "Tony Curtis via discuss" <discuss(a)mpich.org> wrote: On May 1, 2020, at 4:04 PM, Sajid Ali <sajidsyed2021(a)u.northwestern.edu> wrote: Hi Tony, Yes, and be sure to set the correct mpi launcher at runtime via the --mpi argument to srun (for more info check this page https://slurm.schedmd.com/mpi_guide.html ). Thanks - thought so. I’m just a j. Random user so I can’t do much about this. Tony _______________________________________________ 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 3.3.2 and ch4:ucx launcher
by Raffenetti, Kenneth J. 14 May '20

14 May '20

Sorry for the delayed response. Why are you adding --with-pm=no to your configuration? Ken On 5/1/20, 3:20 PM, "Tony Curtis via discuss" <discuss(a)mpich.org> wrote: On May 1, 2020, at 4:04 PM, Sajid Ali <sajidsyed2021(a)u.northwestern.edu> wrote: Hi Tony, Yes, and be sure to set the correct mpi launcher at runtime via the --mpi argument to srun (for more info check this page https://slurm.schedmd.com/mpi_guide.html ). Thanks - thought so. I’m just a j. Random user so I can’t do much about this. Tony

1 0

Why does hydra_mpi_proxy kill client processes?
by Yuri 12 May '20

12 May '20

I am running NWchem (a quantum chemistry program) in parallel on a single host using mpich-3.2.1_6 on FreeBSD 12.1 It runs, but every once in a while hydra_mpi_proxy sends SIGKILL to a client process nwchem. The same task usually succeeds when rerun again, and some other task fails with SIGKILL next time, so the problem is sporadic. Why does hydra_mpi_proxy kill client processes? My original NWchem bug report is https://github.com/nwchemgit/nwchem/issues/198 Thank you, Yuri

1 0

Re: [mpich-discuss] Run mpich on localhost
by Martin Ivanov 10 May '20

10 May '20

Hello Tony, Thank you very much for your help. Interestingly, there are both mpich and hwloc packages for dfly. They should be working ok. For now, with 5 cores is OK for me, 50 % of the time it starts successfully. If I manage to compile WRF I may experiment updating mpich. But for now I prefer to stick to the library versions recommended by the WRF compilation tutorial. Best regards, Martin Von meinem iPhone gesendet > Am 10.05.2020 um 22:17 schrieb Tony Curtis <anthony.curtis(a)stonybrook.edu>: > > > >> On May 10, 2020, at 3:16 AM, Martin Ivanov <marto1980(a)gmail.com> wrote: >> >> Hello Tony, >> Thank you very much for your reply. I am posting you the output of 'ps x', when 'mpirun -n 5 mpich-3.0.4/examples/hellow' freezes: >> >> After that freeze, I killed mpirun with Ctrl + C: >> " >> marto@dragonfly% mpirun -n 5 mpich-3.0.4/examples/hellow >> ^C[mpiexec@dragonfly] Sending Ctrl-C to processes as requested >> [mpiexec@dragonfly] Press Ctrl-C again to force abort >> [proxy:0:0@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:71): assert (!(pollfds[i].revents & ~POLLIN & ~POLLOUT & ~POLLHUP & ~POLLERR)) failed >> [proxy:0:0@dragonfly] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event >> [mpiexec@dragonfly] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed >> [mpiexec@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status >> [mpiexec@dragonfly] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event >> [mpiexec@dragonfly] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion >> " >> >> The next relaunch of mpirun with 5 cores was successful. For completeness, I am attaching the output of 'ps x' after mpirun with 2 cores freezes, which it actually with 2 cores always does. >> >> I hope this was helpful. I am looking forward to your reply. >> > > Hi, > > Well, I took this as an opportunity to play with dfly again, so I replicated mpich 3.0.4 and see much the same behavior. Mpirun -n 2 hangs consistently, -n 4 works reliably (= # system cores), -n 5 sometimes. > > I’m not an mpich developer so I will leave further prognostication to their capable hands, but your suspicions about hwloc from the warning messages seem to be well-founded. > > Tony >

1 0

Re: [mpich-discuss] Run mpich on localhost
by Tony Curtis 10 May '20

10 May '20

> On May 10, 2020, at 3:16 AM, Martin Ivanov <marto1980(a)gmail.com> wrote: > > Hello Tony, > Thank you very much for your reply. I am posting you the output of 'ps x', when 'mpirun -n 5 mpich-3.0.4/examples/hellow' freezes: > > After that freeze, I killed mpirun with Ctrl + C: > " > marto@dragonfly% mpirun -n 5 mpich-3.0.4/examples/hellow > ^C[mpiexec@dragonfly] Sending Ctrl-C to processes as requested > [mpiexec@dragonfly] Press Ctrl-C again to force abort > [proxy:0:0@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:71): assert (!(pollfds[i].revents & ~POLLIN & ~POLLOUT & ~POLLHUP & ~POLLERR)) failed > [proxy:0:0@dragonfly] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event > [mpiexec@dragonfly] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed > [mpiexec@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status > [mpiexec@dragonfly] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event > [mpiexec@dragonfly] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion > " > > The next relaunch of mpirun with 5 cores was successful. For completeness, I am attaching the output of 'ps x' after mpirun with 2 cores freezes, which it actually with 2 cores always does. > > I hope this was helpful. I am looking forward to your reply. > Hi, Well, I took this as an opportunity to play with dfly again, so I replicated mpich 3.0.4 and see much the same behavior. Mpirun -n 2 hangs consistently, -n 4 works reliably (= # system cores), -n 5 sometimes. I’m not an mpich developer so I will leave further prognostication to their capable hands, but your suspicions about hwloc from the warning messages seem to be well-founded. Tony

1 0

Re: [mpich-discuss] 1. Single file reading by all processors in MPI. 2.Difference between blocking and non-blocking call of MPI_neighbor_alltoallw
by Joseph Schuchart 10 May '20

10 May '20

On 5/10/20 7:30 PM, Jeff Hammond via discuss wrote: > > >> On May 9, 2020, at 8:34 PM, hritikesh semwal >> <hritikesh.semwal(a)gmail.com> wrote: >> >> >> >> >> On Sun, May 10, 2020 at 4:18 AM Jeff Hammond <jeff.science(a)gmail.com >> <mailto:[email protected]>> wrote: >> >> >> >> On Sat, May 9, 2020 at 10:10 AM hritikesh semwal via discuss >> <discuss(a)mpich.org <mailto:[email protected]>> wrote: >> >> Hello, >> >> I have following two questions with MPI, >> >> 1. Do I need to give a separate input file to each processor >> in a group or all of them can read the input from a single >> file? All data inside the file should be read by every processor. >> >> >> You can read the input file from every process but it isn't a good >> idea. Read the input file from rank 0 and broadcast the >> contents. This assumes that your input file is small. If your >> input file is huge, then you should consider designing it for >> parallel reading with MPI_File_* functions. >> >> >> Thanks for your response. I am reading two input files in my parallel >> CFD solver at different places of the code. The first input file has 7 >> integer values and second input file has 15 integer values. Is it >> large to read it through conventional C functions for file reading >> i.e. fscanf() and is broadcast good for this amount of data? > > It depends on your filesystem details but I’d expect the cutoff where > parallel reading of input to be necessary is greater than 1 MB and > potentially much more than that. Anything less than 4K (or whatever the > filesystem page size is if not 4K) is going to be dominated by block > read latency, which can’t be reduced with parallelism. The latency/bandwidth for reading is only one aspect though, the filesystem overhead is another. Your site administrators will be grateful for you *not* trying to open the same file from a couple thousand processes at once... Reading it once in a single process and distributing it in a broadcast is imo the best option in this case. Cheers Joseph, who brought down Lustre installations in the past... > > Jeff > >> 2. Can you please tell me what is the difference between >> MPI_Neighbor_alltoallw and MPI_Ineighbor_alltoallw? As I read >> in MPI 3.0 document that MPI_Neighbor_alltoallw also used >> non-blocking send and receive inside its execution. >> >> >> MPI_Neighbor_alltoallw is a blocking function while >> MPI_Ineighbor_alltoallw is not. Using non-blocking send and >> receive inside its execution does not mean >> that MPI_Neighbor_alltoallw doesn't block - if that is how it's >> implemented, then there will be the equivalent of a MPI_Waitall >> before the function returns. But in any case, just because the >> MPI document suggests a possible implementation does not mean that >> is how all implementations work. >> >> >> Yes, there is MPI_Waitall inside the MPI_Neighbor_alltoallw before it >> returns. >> >> >> Jeff >> >> Thank you. >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> > > _______________________________________________ > 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] 1. Single file reading by all processors in MPI. 2.Difference between blocking and non-blocking call of MPI_neighbor_alltoallw
by Jeff Hammond 10 May '20

10 May '20

> On May 9, 2020, at 8:34 PM, hritikesh semwal <hritikesh.semwal(a)gmail.com> wrote: > > > > >> On Sun, May 10, 2020 at 4:18 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> >>>> On Sat, May 9, 2020 at 10:10 AM hritikesh semwal via discuss <discuss(a)mpich.org> wrote: >>>> Hello, >>>> >>>> I have following two questions with MPI, >>>> >>>> 1. Do I need to give a separate input file to each processor in a group or all of them can read the input from a single file? All data inside the file should be read by every processor. >>> >>> You can read the input file from every process but it isn't a good idea. Read the input file from rank 0 and broadcast the contents. This assumes that your input file is small. If your input file is huge, then you should consider designing it for parallel reading with MPI_File_* functions. >> >> Thanks for your response. I am reading two input files in my parallel CFD solver at different places of the code. The first input file has 7 integer values and second input file has 15 integer values. Is it large to read it through conventional C functions for file reading i.e. fscanf() and is broadcast good for this amount of data? It depends on your filesystem details but I’d expect the cutoff where parallel reading of input to be necessary is greater than 1 MB and potentially much more than that. Anything less than 4K (or whatever the filesystem page size is if not 4K) is going to be dominated by block read latency, which can’t be reduced with parallelism. Jeff >>> 2. Can you please tell me what is the difference between MPI_Neighbor_alltoallw and MPI_Ineighbor_alltoallw? As I read in MPI 3.0 document that MPI_Neighbor_alltoallw also used non-blocking send and receive inside its execution. >>> >> >> MPI_Neighbor_alltoallw is a blocking function while MPI_Ineighbor_alltoallw is not. Using non-blocking send and receive inside its execution does not mean that MPI_Neighbor_alltoallw doesn't block - if that is how it's implemented, then there will be the equivalent of a MPI_Waitall before the function returns. But in any case, just because the MPI document suggests a possible implementation does not mean that is how all implementations work. > > Yes, there is MPI_Waitall inside the MPI_Neighbor_alltoallw before it returns. > >> >> Jeff >> >>> Thank you. >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/

1 0

Re: [mpich-discuss] Run mpich on localhost
by Martin Ivanov 10 May '20

10 May '20

Hello Tony, Thank you very much for your reply. I am posting you the output of 'ps x', when 'mpirun -n 5 mpich-3.0.4/examples/hellow' freezes: " marto@dragonfly% ps x PID TT STAT TIME COMMAND 1025 ?? I6s 0:00.14 /usr/local/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session 1028 ?? I4s 0:00.08 kdeinit5: Running... (kdeinit5) 1029 ?? I2 0:00.26 /usr/local/lib/libexec/kf5/klauncher --fd=8 1031 ?? I7 0:00.65 kded5 1040 ?? I3 0:00.21 /usr/local/bin/kaccess 1047 ?? I4 0:00.02 /usr/local/libexec/dconf-service 1058 ?? I1 0:00.26 /usr/local/bin/ksmserver 1061 ?? I6 0:00.38 /usr/local/bin/kglobalaccel5 1067 ?? I7 0:00.10 /usr/local/lib/libexec/kf5/kscreen_backend_launcher 1069 ?? I0 0:18.15 /usr/local/bin/kwin_x11 -session 100000000158893236700000019470008_1589011398_40052 1071 ?? I3 0:07.36 /usr/local/bin/plasmashell 1073 ?? I6 0:00.06 /usr/local/bin/xembedsniproxy 1075 ?? I3 0:00.17 /usr/local/lib/libexec/polkit-kde-authentication-agent-1 1080 ?? I6 0:00.05 /usr/local/bin/kwrited 1084 ?? I5 0:00.07 /usr/local/bin/gmenudbusmenuproxy 1093 ?? I2 0:00.24 /usr/local/lib/libexec/DiscoverNotifier -session 1014ce0c7d3000158899951500000013340005_1589011398_16101 1121 ?? I2 0:00.45 /usr/local/bin/korgac -session 100000000158893236700000019470009_1589011398_16368 1128 ?? I2 0:00.00 /usr/local/libexec/at-spi-bus-launcher 1130 ?? I3 0:00.24 /usr/local/lib/libexec/kactivitymanagerd 1131 ?? S5 0:00.11 /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 1134 ?? I2 0:00.07 /usr/local/libexec/at-spi2-registryd --use-gnome-session 1136 ?? I1 0:07.00 /usr/local/lib/thunderbird/thunderbird --sm-client-id 100000000158893248800000019470014 1140 ?? S5 0:01.73 /usr/local/bin/gkrellm --sm-client-id 100000000158893266700000019470017 1142 ?? I6 0:00.54 /usr/local/bin/dolphin -session 100000000158893337700000019470020_1589011398_16282 1144 ?? I7 0:00.35 /usr/local/bin/kmix -session 1014ce0c7d3000158899952000000013340007_1589011398_17041 1146 ?? I0 0:01.01 /usr/local/bin/konsole -session 1014ce0c7d3000158899955500000013340009_1589011398_16527 1152 ?? I1 0:00.24 /usr/local/lib/libexec/org_kde_powerdevil 1214 ?? I4 0:00.00 kdeinit5: file.so file local:/var/run/user/1001/klauncherPKUbmP.1.slave-socket local:/var/run/user/1001/kio_desktopMgyNoK.1.slave-socket (kdeinit5) 1216 ?? Z 0:00.00 (sh) 1217 ?? Z 0:00.00 (sh) 1218 ?? Z 0:00.00 (sh) 1219 ?? Z 0:00.01 (sh) 1220 ?? Z 0:00.00 (sh) 1221 ?? Z 0:00.01 (sh) 1222 ?? Z 0:00.00 (sh) 1223 ?? Z 0:00.00 (sh) 1224 ?? Z 0:00.01 (sh) 1225 ?? Z 0:00.00 (sh) 1226 ?? Z 0:00.00 (sh) 1227 ?? Z 0:00.00 (sh) 1228 ?? Z 0:00.00 (sh) 1229 ?? Z 0:00.00 (sh) 1230 ?? Z 0:00.00 (sh) 1231 ?? Z 0:00.00 (sh) 1232 ?? Z 0:00.01 (sh) 1233 ?? Z 0:00.00 (sh) 1234 ?? Z 0:00.01 (sh) 1235 ?? Z 0:00.00 (sh) 1277 ?? S4 0:00.00 kdeinit5: file.so file local:/var/run/user/1001/klauncherPKUbmP.1.slave-socket local:/var/run/user/1001/kded5wwlydC.1.slave-socket (kdeinit5) 1278 ?? I7 0:05.48 chrome: (chrome) 1281 ?? S1 0:01.06 chrome: --type=utility --field-trial-handle=9865741493051962933,5833454360386249874,131072 --lang=en-US --service-sandbox-type=network --disable-webrtc-apm-in-audio-service --shared 1282 ?? I0 0:02.61 chrome: --type=gpu-process --field-trial-handle=9865741493051962933,5833454360386249874,131072 --gpu-preferences=MAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAQAAAAAAAAAAAAAAAAAAAACAAA 1302 ?? I0 0:00.67 chrome: --type=renderer --disable-webrtc-apm-in-audio-service --field-trial-handle=9865741493051962933,5833454360386249874,131072 --disable-gpu-compositing --lang=en-US --enable-aut 1315 ?? I6 0:14.93 chrome: --type=renderer --disable-webrtc-apm-in-audio-service --field-trial-handle=9865741493051962933,5833454360386249874,131072 --disable-gpu-compositing --lang=en-US --enable-aut 1320 ?? I1 0:00.26 chrome: --type=renderer --disable-webrtc-apm-in-audio-service --field-trial-handle=9865741493051962933,5833454360386249874,131072 --disable-gpu-compositing --lang=en-US --enable-aut 1321 ?? I4 0:00.20 chrome: --type=renderer --disable-webrtc-apm-in-audio-service --field-trial-handle=9865741493051962933,5833454360386249874,131072 --disable-gpu-compositing --lang=en-US --enable-aut 1322 ?? I5 0:00.25 chrome: --type=utility --field-trial-handle=9865741493051962933,5833454360386249874,131072 --lang=en-US --service-sandbox-type=audio --disable-webrtc-apm-in-audio-service --shared-f 1422 ?? I2s 0:00.00 /home/marto/WRF/Build_WRF/LIBRARIES/mpich/bin/hydra_pmi_proxy --control-port dragonfly:2416 --rmk user --launcher ssh --demux poll --pgid 0 --retries 10 --usize -2 --proxy-id 0 1423 ?? R4s 1:11.89 mpich-3.0.4/examples/hellow 1424 ?? I2s 0:00.00 mpich-3.0.4/examples/hellow 1425 ?? R3s 1:11.04 mpich-3.0.4/examples/hellow 1426 ?? R2s 1:11.39 mpich-3.0.4/examples/hellow 1427 ?? R6s 1:11.96 mpich-3.0.4/examples/hellow 972 v0 I0 0:00.00 -tcsh (tcsh) 977 v0 I0+ 0:00.00 /bin/sh /usr/local/bin/startx 1001 v0 I0+ 0:00.00 xinit /home/marto/.xinitrc -- /usr/local/bin/X :0 -auth /home/marto/.serverauth.977 1004 v0 I0 0:00.00 ck-launch-session startplasma-x11 1013 v0 I1 0:00.03 startplasma-x11 1024 v0 I6 0:00.00 dbus-launch --autolaunch 7a25735143fe35ec86d2d9be5eac81cc --binary-syntax --close-stderr 1043 v0 I2 0:00.13 /usr/local/bin/plasma_session 1196 1 I2s 0:00.07 /bin/tcsh 1421 1 I2+ 0:00.00 mpirun -n 5 mpich-3.0.4/examples/hellow (mpiexec.hydra) 1199 2 I5s+ 0:00.04 /bin/tcsh 1194 3 S6s 0:00.04 /bin/tcsh 1429 3 R6+ 0:00.00 ps x " After that freeze, I killed mpirun with Ctrl + C: " marto@dragonfly% mpirun -n 5 mpich-3.0.4/examples/hellow ^C[mpiexec@dragonfly] Sending Ctrl-C to processes as requested [mpiexec@dragonfly] Press Ctrl-C again to force abort [proxy:0:0@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:71): assert (!(pollfds[i].revents & ~POLLIN & ~POLLOUT & ~POLLHUP & ~POLLERR)) failed [proxy:0:0@dragonfly] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event [mpiexec@dragonfly] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed [mpiexec@dragonfly] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [mpiexec@dragonfly] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event [mpiexec@dragonfly] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion " The next relaunch of mpirun with 5 cores was successful. For completeness, I am attaching the output of 'ps x' after mpirun with 2 cores freezes, which it actually with 2 cores always does. I hope this was helpful. I am looking forward to your reply. Best regards, Martin On Sat, May 9, 2020 at 2:15 PM Tony Curtis <anthony.curtis(a)stonybrook.edu> wrote: > > > On May 9, 2020, at 2:24 AM, Martin Ivanov <marto1980(a)gmail.com> wrote: > > Hello Tony, > Thank you very much for your reply. I followed your advice and gave the > hostname 'dragonfly' to my machine. Then, in /etc/hosts I provided gave the > alias 'dragonfly' to localhost as you suggested: > > " > marto@dragonfly% cat /etc/hosts > ::1 localhost dragonfly > 127.0.0.1 localhost dragonfly > " > > I compiled both the icpi and hellow examples. Now mpiexec seems to work, > although not as reliably as I might wish. Running any of the examples with > one core like this: > > mpiexec -n 1 mpich-3.0.4/examples/hellow > > is always successful. I could never get the command to finish with 2, 3, > or 4 cores: it simply hangs. E.g. with 2 cores after running the above > command I get: > > " > marto@dragonfly% ps x | grep hellow > 166493 ?? I6s 0:00.00 mpich-3.0.4/examples/hellow > 166494 ?? I6s 0:00.00 mpich-3.0.4/examples/hellow > " > > > Ok, good, that seemed like it was the obvious problem. Can you show all > the processes involved in the launch, not just the application (i.e. also > the mpirun and anything that is spawned)? This might provide a further > clue about what is happening underneath. > > Tony > >

1 0

Re: [mpich-discuss] 1. Single file reading by all processors in MPI. 2.Difference between blocking and non-blocking call of MPI_neighbor_alltoallw
by Benson Muite 10 May '20

10 May '20

On Sun, May 10, 2020, at 6:33 AM, hritikesh semwal via discuss wrote: > > > On Sun, May 10, 2020 at 4:18 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> >> On Sat, May 9, 2020 at 10:10 AM hritikesh semwal via discuss <discuss(a)mpich.org> wrote: >>> Hello, >>> >>> I have following two questions with MPI, >>> >>> 1. Do I need to give a separate input file to each processor in a group or all of them can read the input from a single file? All data inside the file should be read by every processor. >> >> You can read the input file from every process but it isn't a good idea. Read the input file from rank 0 and broadcast the contents. This assumes that your input file is small. If your input file is huge, then you should consider designing it for parallel reading with MPI_File_* functions. > > Thanks for your response. I am reading two input files in my parallel CFD solver at different places of the code. The first input file has 7 integer values and second input file has 15 integer values. Is it large to read it through conventional C functions for file reading i.e. fscanf() and is broadcast good for this amount of data? > fscanf on process 0 with a broadcast should be sufficient. >> >> >> >>> >>> 2. Can you please tell me what is the difference between MPI_Neighbor_alltoallw and MPI_Ineighbor_alltoallw? As I read in MPI 3.0 document that MPI_Neighbor_alltoallw also used non-blocking send and receive inside its execution. >>> >> >> MPI_Neighbor_alltoallw is a blocking function while MPI_Ineighbor_alltoallw is not. Using non-blocking send and receive inside its execution does not mean that MPI_Neighbor_alltoallw doesn't block - if that is how it's implemented, then there will be the equivalent of a MPI_Waitall before the function returns. But in any case, just because the MPI document suggests a possible implementation does not mean that is how all implementations work. > > Yes, there is MPI_Waitall inside the MPI_Neighbor_alltoallw before it returns. > >> >> >> Jeff >> >>> >>> Thank you. >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ > _______________________________________________ > 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] 1. Single file reading by all processors in MPI. 2.Difference between blocking and non-blocking call of MPI_neighbor_alltoallw
by hritikesh semwal 09 May '20

09 May '20

On Sun, May 10, 2020 at 4:18 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > On Sat, May 9, 2020 at 10:10 AM hritikesh semwal via discuss < > discuss(a)mpich.org> wrote: > >> Hello, >> >> I have following two questions with MPI, >> >> 1. Do I need to give a separate input file to each processor in a group >> or all of them can read the input from a single file? All data inside the >> file should be read by every processor. >> > > You can read the input file from every process but it isn't a good idea. > Read the input file from rank 0 and broadcast the contents. This assumes > that your input file is small. If your input file is huge, then you should > consider designing it for parallel reading with MPI_File_* functions. > Thanks for your response. I am reading two input files in my parallel CFD solver at different places of the code. The first input file has 7 integer values and second input file has 15 integer values. Is it large to read it through conventional C functions for file reading i.e. fscanf() and is broadcast good for this amount of data? > > >> 2. Can you please tell me what is the difference between >> MPI_Neighbor_alltoallw and MPI_Ineighbor_alltoallw? As I read in MPI 3.0 >> document that MPI_Neighbor_alltoallw also used non-blocking send and >> receive inside its execution. >> >> > MPI_Neighbor_alltoallw is a blocking function while > MPI_Ineighbor_alltoallw is not. Using non-blocking send and receive inside > its execution does not mean that MPI_Neighbor_alltoallw doesn't block - if > that is how it's implemented, then there will be the equivalent of a > MPI_Waitall before the function returns. But in any case, just because the > MPI document suggests a possible implementation does not mean that is how > all implementations work. > Yes, there is MPI_Waitall inside the MPI_Neighbor_alltoallw before it returns. > > Jeff > > >> Thank you. >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ >

1 0