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

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

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 09 May '20

09 May '20

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. > 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. 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

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

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. 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. Thank you.

1 0

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

09 May '20

> 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] Run mpich on localhost
by Martin Ivanov 09 May '20

09 May '20

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 " With 5, 6, 7, or 8 cores most of the time the command is successful, that is all cores print as expected, but sometimes the command also hangs just as with 2 cores. Testing with icpi and 10^10 intervals gives the following output with 1 core: " marto@dragonfly% mpiexec -n 1 mpich-3.0.4/examples/icpi Enter the number of intervals: (0 quits) 10000000000 pi is approximately 3.1415926535895782, Error is 0.0000000000002149 wall clock time = 19.997830 " and the following with 5 cores, when it does not hang: " marto@dragonfly% mpiexec -n 5 mpich-3.0.4/examples/icpi Enter the number of intervals: (0 quits) 10000000000 pi is approximately 3.1415926535899605, Error is 0.0000000000001674 wall clock time = 4.475224 " As you can see, the calculation scales nicely. However, I am lost trying to figure out this unreliable behaviour. Maybe it has something to do with the hwloc warnings I get at configure? I am attaching the output of running the configure script. Thank you very much for your helpful advices. I am looking forward to your reply. Best regards, Martin On Fri, May 8, 2020 at 2:48 PM Tony Curtis <anthony.curtis(a)stonybrook.edu> wrote: > > > On May 8, 2020, at 1:41 AM, Martin Ivanov <marto1980(a)gmail.com> wrote: > > Hello, > Thank you for your replies. I think another version of MPICH may not work > as I am following a tutorial ( > https://www2.mmm.ucar.edu/wrf/OnLineTutorial/compilation_tutorial.php) > that requires specific library versions. > My /etc/hosts file contains only these two lines: > > " > ::1 localhost localhost.my.domain > 127.0.0.1 localhost localhost.my.domain > " > > uname -n returns an empty string as I have not set a hostname. I guess I > do not need this because I need to run MPICH only on this machine, that is > on localhost? uname -a gives the following output: > > > Thing is, though, your initial post showed ssh being used as launcher. So > in that case you would definitely need a hostname so you can resolve back > to yourself (your shell prompt was a big clue, by the way). Setting a > hostname and making it an alias of localhost in /etc/hosts would probably > do wonders no matter the underlying launch. > > The -info output is pretty much the same as I see on FreeBSD. > > If you run a hello world with a sleep in it to allow you to react, what > does “ps x” show? > > (Not familiar much with DragonFly beyond “poking at it” so I don’t have > any particular insight there.) > > Tony > > >

1 0

Re: [mpich-discuss] Speed up issue with CFD solver.
by hritikesh semwal 08 May '20

08 May '20

What do you mean by logical partition? For 2 partitions it a single slice and for 4 partitions it is a plus shape slice partitioning. The computation is decreasing continuously but communication time is increasing from 0.69% to 8.9% of the total time from 2 to 4 processes. I am using MPI_Neighbor_alltoallw for exchanging data after forming distributed graph topology. On Fri, May 8, 2020 at 8:34 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > I would first analyze the logical partition and the effects on computation > and communications. Do they continuously change from 2 process and up or is > there a bump? > > > > -- > Hui Zhou > > > > > > *From: *hritikesh semwal via discuss <discuss(a)mpich.org> > *Reply-To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Date: *Thursday, May 7, 2020 at 11:19 PM > *To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Cc: *hritikesh semwal <hritikesh.semwal(a)gmail.com> > *Subject: *[mpich-discuss] Speed up issue with CFD solver. > > > > Hello, > > > > I am developing a parallel CFD solver for unstructured grids with finite > volume explicit time integration method and the global mesh count is 97336 > cells. I am trying to get the speed up results of my code but something > strange is happening. Following are my timing results after the second time > step with the different number of processors; > > > > 2 processors- 182.284 seconds > > 4 processors- 251.7035 seconds > > 8 processors- 190.8578 seconds > > 16 processors- 129.7989 seconds > > 24 processors- 121.0303 seconds > > 32 processors- 111.3772 seconds > > > > I am not getting why there is a sharp rise in time from 2 processors to 4 > processors and after that, it is decreasing. I had run the same code 2 > weeks ago and at that time the results were different from the present > results and time was continuously decreasing at that time. Could someone > please help me with this matter by suggesting the probable cause/s of this > behaviour? > > > > Thank you. >

1 0

Re: [mpich-discuss] Speed up issue with CFD solver.
by Zhou, Hui 08 May '20

08 May '20

I would first analyze the logical partition and the effects on computation and communications. Do they continuously change from 2 process and up or is there a bump? -- Hui Zhou From: hritikesh semwal via discuss <discuss(a)mpich.org> Reply-To: "discuss(a)mpich.org" <discuss(a)mpich.org> Date: Thursday, May 7, 2020 at 11:19 PM To: "discuss(a)mpich.org" <discuss(a)mpich.org> Cc: hritikesh semwal <hritikesh.semwal(a)gmail.com> Subject: [mpich-discuss] Speed up issue with CFD solver. Hello, I am developing a parallel CFD solver for unstructured grids with finite volume explicit time integration method and the global mesh count is 97336 cells. I am trying to get the speed up results of my code but something strange is happening. Following are my timing results after the second time step with the different number of processors; 2 processors- 182.284 seconds 4 processors- 251.7035 seconds 8 processors- 190.8578 seconds 16 processors- 129.7989 seconds 24 processors- 121.0303 seconds 32 processors- 111.3772 seconds I am not getting why there is a sharp rise in time from 2 processors to 4 processors and after that, it is decreasing. I had run the same code 2 weeks ago and at that time the results were different from the present results and time was continuously decreasing at that time. Could someone please help me with this matter by suggesting the probable cause/s of this behaviour? Thank you.

1 0