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

Re: [mpich-discuss] f77 bindings and profiling
by Jan Bierbaum 28 Nov '14

28 Nov '14

On 19.11.2014 16:43, Isaila, Florin D. wrote: > Thanks Jan, this works indeed for me with mpich-3.1 (by using mpif77 > compiler, I think this is what you meant). However, it does not work > with mpich-3.1.3. You're right. When I try to use MPICH 3.1.3, I get the very same problem - the profiling library is not linked into the binary. Looking at the two fortran wrapper libraries, they do indeed define different symbols: | $ nm ${MPICH_3_1}/lib/libfmpich.a | grep -i 'MPI_Init_*$' | 0000000000000000 W MPI_INIT | U MPI_Init | 0000000000000000 W mpi_init | 0000000000000000 T mpi_init_ | 0000000000000000 W mpi_init__ | $ nm ${MPICH_3_1_3}/lib/libmpifort.a | grep -i 'MPI_Init_*$' | 0000000000000000 W MPI_INIT | 0000000000000000 W PMPI_INIT | U PMPI_Init | 0000000000000000 W mpi_init | 0000000000000000 W mpi_init_ | 0000000000000000 W mpi_init__ | 0000000000000000 W pmpi_init | 0000000000000000 T pmpi_init_ | 0000000000000000 W pmpi_init__ It doesn't really make sense, though. PMPI is supposed to work by redefining the 'MPI_*' functions. So a Fortran wrapper should refer to these functions as the old version did; 'MPI_Init' is the only undefined reference there. The new version, however, refers to 'PMPI_Init' and thus circumvents the profiler. Is this a bug or are we missing something here? Regards, Jan _______________________________________________ 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] Problem with MPICH3/OpenPA on IBM P755
by Victor Vysotskiy 28 Nov '14

28 Nov '14

Hi Pavan, enclosed please find the requested config.log file. BTW, I am trying to compile MPICH3 on P775 (Power7 running under AIX) rather than on P755. However, I can check the issue on P755 (Power7 running under Linux) too, if it is needed. With best regards, Victor. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-ibm] [mpich-discuss] Problem with MPICH3/OpenPA on IBM P755
by Balaji, Pavan 27 Nov '14

27 Nov '14

Hmm. That's not a good sign. OPA's configure seems to think that it can use some inbuilt atomic capability while the compiler/hardware is clearly not supporting it. Can you send us the OPA config.log (src/openpa/config.log) so we can look into it? Also cc'ed the IBM folks. IBM folks, any thoughts? -- Pavan > On Nov 27, 2014, at 6:11 AM, Victor Vysotskiy <victor.vysotskiy(a)teokem.lu.se> wrote: > > Hi, > > I am trying to compile the latest ('v3.2a2-24-g4ad367d0') nightly snapshot on the IBM P775 machine. The MPICH3 is configured with the following options: > > export OBJECT_MODE=64 > ./configure --enable-f77 --enable-fc --enable-cxx --enable-smpcoll --with-thread-package=pthreads --with-pami=/opt/ibmhpc/pecurrent/ppe.pami --with-pami-lib=/opt/ibmhpc/pecurrent/ppe.pami/lib --with-pami-include=/opt/ibmhpc/pecurrent/ppe.pami/include64 --enable-mpe --enable-error-messages=all CC="xlc_r -q64 -qmaxmem=-1" CPP=/usr/ccs/lib/cpp CXX="xlC_r -q64 -qmaxmem=-1" F77="xlf_r -q64 -qmaxmem=-1" FC="xlf90_r -q64 -qmaxmem=-1" CFLAGS="-q64 -qmaxmem=-1" CXXFLAGS="-q64 -qmaxmem=-1" FCFLAGS="-qmaxmem=-1 -q64" FFLAGS="-q64 -qmaxmem=-1" OBJECT_MODE=64 AR="ar -X 64" --with-file-system=bg+bglockless > > No problem with compiling it, but there is a problem with running OpenPA tests: > > Testing simple integer load-linked/store-conditional functionality -SKIP- > LL/SC not available > Testing simple pointer load-linked/store-conditional functionality -SKIP- > LL/SC not available > Testing integer LL/SC ABA -SKIP- > LL/SC not available > Testing pointer LL/SC ABA -SKIP- > LL/SC not available > Testing integer load/store with 1 thread *FAILED* > at test_primitives.c:371 in test_threaded_loadstore_int()... > Testing pointer load/store with 1 thread *FAILED* > at test_primitives.c:556 in test_threaded_loadstore_ptr()... > Testing add with 1 thread *FAILED* > at test_primitives.c:750 in test_threaded_add()... > Testing incr and decr with 1 thread PASSED > Testing decr and test with 1 thread *FAILED* > at test_primitives.c:1093 in test_threaded_decr_and_test()... > Testing fetch and add with 1 thread *FAILED* > at test_primitives.c:1344 in test_threaded_faa()... > Testing fetch and add return values with 1 thread *FAILED* > at test_primitives.c:1490 in test_threaded_faa_ret()... > Testing fetch and incr/decr with 1 thread PASSED > Testing fetch and incr return values with 1 thread *FAILED* > at test_primitives.c:1796 in test_threaded_fai_ret()... > Testing fetch and decr return values with 1 thread *FAILED* > at test_primitives.c:1953 in test_threaded_fad_ret()... > Testing integer compare-and-swap with 1 thread *FAILED* > at test_primitives.c:2191 in test_threaded_cas_int()... > Testing pointer compare-and-swap with 1 thread *FAILED* > at test_primitives.c:2346 in test_threaded_cas_ptr()... > Testing grouped integer compare-and-swap with 1 thread *FAILED* > at test_primitives.c:2506 in test_grouped_cas_int()... > Testing grouped pointer compare-and-swap with 1 thread *FAILED* > at test_primitives.c:2683 in test_grouped_cas_ptr()... > Testing integer compare-and-swap fairness with 1 thread *FAILED* > at test_primitives.c:2890 in test_threaded_cas_int_fairness()... > Testing pointer compare-and-swap fairness with 1 thread *FAILED* > at test_primitives.c:3087 in test_threaded_cas_ptr_fairness()... > Testing integer swap with 1 thread *FAILED* > at test_primitives.c:3341 in test_threaded_swap_int()... > Testing pointer swap with 1 thread *FAILED* > at test_primitives.c:3496 in test_threaded_swap_ptr()... > Testing integer LL/SC stack -SKIP- > LL/SC not available > Testing pointer LL/SC stack -SKIP- > LL/SC not available > Testing integer LL/SC stack -SKIP- > LL/SC not available > Testing pointer LL/SC stack -SKIP- > LL/SC not available > Testing integer LL/SC stack -SKIP- > LL/SC not available > Testing pointer LL/SC stack -SKIP- > LL/SC not available > Testing integer LL/SC stack -SKIP- > LL/SC not available > Testing pointer LL/SC stack -SKIP- > LL/SC not available > ***** 16 PRIMITIVES TESTS FAILED! ***** > > Apparently, a bunch of tests failed. Is there anything to worry about? Or, I can simply skip these failed test and can use the compiled MPICH3 for production? > > The software stack used: > AIX v7.1.0.0 > XLC/XLF compiler v14.01.0000.0008 > POE v1-1.2.0.3 > > Best, > Victor. > _______________________________________________ > 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 _______________________________________________ ibm mailing list ibm(a)lists.mpich.org https://lists.mpich.org/mailman/listinfo/ibm

1 0

Problem with MPICH3/OpenPA on IBM P755
by Victor Vysotskiy 27 Nov '14

27 Nov '14

Hi, I am trying to compile the latest ('v3.2a2-24-g4ad367d0') nightly snapshot on the IBM P775 machine. The MPICH3 is configured with the following options: export OBJECT_MODE=64 ./configure --enable-f77 --enable-fc --enable-cxx --enable-smpcoll --with-thread-package=pthreads --with-pami=/opt/ibmhpc/pecurrent/ppe.pami --with-pami-lib=/opt/ibmhpc/pecurrent/ppe.pami/lib --with-pami-include=/opt/ibmhpc/pecurrent/ppe.pami/include64 --enable-mpe --enable-error-messages=all CC="xlc_r -q64 -qmaxmem=-1" CPP=/usr/ccs/lib/cpp CXX="xlC_r -q64 -qmaxmem=-1" F77="xlf_r -q64 -qmaxmem=-1" FC="xlf90_r -q64 -qmaxmem=-1" CFLAGS="-q64 -qmaxmem=-1" CXXFLAGS="-q64 -qmaxmem=-1" FCFLAGS="-qmaxmem=-1 -q64" FFLAGS="-q64 -qmaxmem=-1" OBJECT_MODE=64 AR="ar -X 64" --with-file-system=bg+bglockless No problem with compiling it, but there is a problem with running OpenPA tests: Testing simple integer load-linked/store-conditional functionality -SKIP- LL/SC not available Testing simple pointer load-linked/store-conditional functionality -SKIP- LL/SC not available Testing integer LL/SC ABA -SKIP- LL/SC not available Testing pointer LL/SC ABA -SKIP- LL/SC not available Testing integer load/store with 1 thread *FAILED* at test_primitives.c:371 in test_threaded_loadstore_int()... Testing pointer load/store with 1 thread *FAILED* at test_primitives.c:556 in test_threaded_loadstore_ptr()... Testing add with 1 thread *FAILED* at test_primitives.c:750 in test_threaded_add()... Testing incr and decr with 1 thread PASSED Testing decr and test with 1 thread *FAILED* at test_primitives.c:1093 in test_threaded_decr_and_test()... Testing fetch and add with 1 thread *FAILED* at test_primitives.c:1344 in test_threaded_faa()... Testing fetch and add return values with 1 thread *FAILED* at test_primitives.c:1490 in test_threaded_faa_ret()... Testing fetch and incr/decr with 1 thread PASSED Testing fetch and incr return values with 1 thread *FAILED* at test_primitives.c:1796 in test_threaded_fai_ret()... Testing fetch and decr return values with 1 thread *FAILED* at test_primitives.c:1953 in test_threaded_fad_ret()... Testing integer compare-and-swap with 1 thread *FAILED* at test_primitives.c:2191 in test_threaded_cas_int()... Testing pointer compare-and-swap with 1 thread *FAILED* at test_primitives.c:2346 in test_threaded_cas_ptr()... Testing grouped integer compare-and-swap with 1 thread *FAILED* at test_primitives.c:2506 in test_grouped_cas_int()... Testing grouped pointer compare-and-swap with 1 thread *FAILED* at test_primitives.c:2683 in test_grouped_cas_ptr()... Testing integer compare-and-swap fairness with 1 thread *FAILED* at test_primitives.c:2890 in test_threaded_cas_int_fairness()... Testing pointer compare-and-swap fairness with 1 thread *FAILED* at test_primitives.c:3087 in test_threaded_cas_ptr_fairness()... Testing integer swap with 1 thread *FAILED* at test_primitives.c:3341 in test_threaded_swap_int()... Testing pointer swap with 1 thread *FAILED* at test_primitives.c:3496 in test_threaded_swap_ptr()... Testing integer LL/SC stack -SKIP- LL/SC not available Testing pointer LL/SC stack -SKIP- LL/SC not available Testing integer LL/SC stack -SKIP- LL/SC not available Testing pointer LL/SC stack -SKIP- LL/SC not available Testing integer LL/SC stack -SKIP- LL/SC not available Testing pointer LL/SC stack -SKIP- LL/SC not available Testing integer LL/SC stack -SKIP- LL/SC not available Testing pointer LL/SC stack -SKIP- LL/SC not available ***** 16 PRIMITIVES TESTS FAILED! ***** Apparently, a bunch of tests failed. Is there anything to worry about? Or, I can simply skip these failed test and can use the compiled MPICH3 for production? The software stack used: AIX v7.1.0.0 XLC/XLF compiler v14.01.0000.0008 POE v1-1.2.0.3 Best, Victor. _______________________________________________ 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 error
by fereshteh komijani 27 Nov '14

27 Nov '14

dar masiri ke swan_only.in dar an hast gharar ghirid va : mpirun -np 2 ./ coawstG swan_only.in mpirun -np 2 ./ coawstM swan_only.in On Wed, Nov 26, 2014 at 5:30 PM, Bland, Wesley B. <wbland(a)anl.gov> wrote: > I think the error description itself it pretty accurate. MPICH can’t find > the executable in the location you specified. You need to make sure that > the executable is in the correct place. > > On Nov 26, 2014, at 1:51 AM, نازنین <nazanin.mirshokraei(a)gmail.com> > wrote: > > hi > i am using mpich 3.0.4 and it is my first time running it > and i do my run like : > > mpirun -np 2 ./Projects/g/swan_only.in > > and i receive this error . will u please help me how to solve this error? > [proxy:0:0@nazanin-VirtualBox] HYDU_create_process > (./utils/launch/launch.c:75): execvp error on file ./Projects/g/ > swan_only.in (No such file or directory) > > > =================================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = EXIT CODE: 255 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > > =================================================================================== > > _______________________________________________ > 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 > -- ***Angel*** _______________________________________________ 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] code from different version of LINUX
by Shuchi Yang 26 Nov '14

26 Nov '14

Yes, I can get right results, but it does not always happen. It happen sometimes, sometimes it is OK. It is really weird. On Wed, Nov 26, 2014 at 2:26 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Do you run your program on one node with 20 processes, and the result is > correct except the time is slower? > If yes, then it seems only one CPU of the node is used, which is weird. > > > > > --Junchao Zhang > > On Wed, Nov 26, 2014 at 1:22 PM, Shuchi Yang <yang.shuchi(a)gmail.com> > wrote: > >> I am doing CFD simulation. >> With MPI, I can split the computational domain to different parts so that >> each process works on different part. In this case, we can reduce the total >> computational time. >> >> When I tried to run at another different system, it looks all the cpu are >> working on the whole computational domain. It looks like every CPU is >> working on the whole computational domain so that the computational >> efficiency is very low. >> >> >> >> On Wed, Nov 26, 2014 at 11:45 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >>> I guess it is not an MPI problem. When you say "every CPU works on all >>> the data", you need a clear idea of what is the data decomposition in your >>> code. >>> >>> >>> --Junchao Zhang >>> >>> On Wed, Nov 26, 2014 at 11:28 AM, Shuchi Yang <yang.shuchi(a)gmail.com> >>> wrote: >>> >>>> Thanks for your reply. I am trying it in the way you mentioned. >>>> But I met one problem is that on my original machine, I can run the >>>> code with 20 CPUs so that each CPU works on part of the job. But at the new >>>> machine, it starts the process with 20 CPUS, but every CPU works on all the >>>> data, so that it looks like it is running 20 times the job at same time. Is >>>> that because of MPI problem? >>>> Thanks, >>>> >>>> Shuchi >>>> >>>> On Wed, Nov 26, 2014 at 9:50 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>> wrote: >>>> >>>>> You can copy MPI libraries installed on the Ubuntu machine to the Suse >>>>> machine, then add that path to LD_LIBRARY_PATH on the Suse. >>>>> >>>>> --Junchao Zhang >>>>> >>>>> On Wed, Nov 26, 2014 at 9:55 AM, Shuchi Yang <yang.shuchi(a)gmail.com> >>>>> wrote: >>>>> >>>>>> I met some problem. >>>>>> The question is that >>>>>> I compile a fortran code at ubuntu, but I need run the code at Suse >>>>>> Linux, I was always told >>>>>> * error while loading shared libraries: libmpifort.so.12: cannot >>>>>> open shared object file: No such file or directory* >>>>>> >>>>>> Furthermore, will this be a problem, I mean, if I compile the code >>>>>> with mpich-gcc and run the code at another type of Linux? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Shuchi >>>>>> >>>>>> _______________________________________________ >>>>>> discuss mailing list discuss(a)mpich.org >>>>>> To manage subscription options or unsubscribe: >>>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] having problem running MPICH on multiple nodes
by Junchao Zhang 26 Nov '14

26 Nov '14

I have no idea. You may try to trace all events as said at http://wiki.mpich.org/mpich/index.php/Debug_Event_Logging

1 0

Re: [mpich-discuss] having problem running MPICH on multiple nodes
by Amin Hassani 26 Nov '14

26 Nov '14

I disabled the whole firewall in those machines but, still get the same problem. connection refuse. I run the program in another set of totally different machines that we have, but still same problem. Any other thought where can be the problem? Thanks. Amin Hassani, CIS department at UAB, Birmingham, AL, USA. On Wed, Nov 26, 2014 at 9:25 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > The connection refused makes me think a firewall is getting in the way. Is > TCP communication limited to specific ports on the cluster? If so, you can > use this envvar to enforce a range of ports in MPICH. > > MPIR_CVAR_CH3_PORT_RANGE > Description: The MPIR_CVAR_CH3_PORT_RANGE environment variable allows > you to specify the range of TCP ports to be used by the process manager and > the MPICH library. The format of this variable is <low>:<high>. To specify > any available port, use 0:0. > Default: {0,0} > > > On 11/25/2014 11:50 PM, Amin Hassani wrote: > >> Tried with the new configure too. same problem :( >> >> $ mpirun -hostfile hosts-hydra -np 2 test_dup >> Fatal error in MPI_Send: Unknown error class, error stack: >> MPI_Send(174)..............: MPI_Send(buf=0x7fffd90c76c8, count=1, >> MPI_INT, dest=1, tag=0, MPI_COMM_WORLD) failed >> MPID_nem_tcp_connpoll(1832): Communication error with rank 1: Connection >> refused >> >> ============================================================ >> ======================= >> = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES >> = PID 5459 RUNNING AT oakmnt-0-a >> = EXIT CODE: 1 >> = CLEANING UP REMAINING PROCESSES >> = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES >> ============================================================ >> ======================= >> [proxy:0:1@oakmnt-0-b] HYD_pmcd_pmip_control_cmd_cb >> (../../../../src/pm/hydra/pm/pmiserv/pmip_cb.c:885): assert (!closed) >> failed >> [proxy:0:1@oakmnt-0-b] HYDT_dmxu_poll_wait_for_event >> (../../../../src/pm/hydra/tools/demux/demux_poll.c:76): callback >> returned error status >> [proxy:0:1@oakmnt-0-b] main >> (../../../../src/pm/hydra/pm/pmiserv/pmip.c:206): demux engine error >> waiting for event >> [mpiexec@oakmnt-0-a] HYDT_bscu_wait_for_completion >> (../../../../src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:76): one of >> the processes terminated badly; aborting >> [mpiexec@oakmnt-0-a] HYDT_bsci_wait_for_completion >> (../../../../src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): launcher >> returned error waiting for completion >> [mpiexec@oakmnt-0-a] HYD_pmci_wait_for_completion >> (../../../../src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:218): launcher >> returned error waiting for completion >> [mpiexec@oakmnt-0-a] main >> (../../../../src/pm/hydra/ui/mpich/mpiexec.c:344): process manager error >> waiting for completion >> >> >> Amin Hassani, >> CIS department at UAB, >> Birmingham, AL, USA. >> >> On Tue, Nov 25, 2014 at 11:44 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> So the error only happens when there is communication. >> >> It may be caused by IB as your guessed before. Could you try to >> reconfigure MPICH using "./configure --with-device=ch3:nemesis:tcp” >> and try again? >> >> — >> Huiwei >> >> > On Nov 25, 2014, at 11:23 PM, Amin Hassani <ahassani(a)cis.uab.edu >> <mailto:[email protected]>> wrote: >> > >> > Yes it works. >> > output: >> > >> > $ mpirun -hostfile hosts-hydra -np 2 test >> > rank 1 >> > rank 0 >> > >> > >> > Amin Hassani, >> > CIS department at UAB, >> > Birmingham, AL, USA. >> > >> > On Tue, Nov 25, 2014 at 11:20 PM, Lu, Huiwei >> <huiweilu(a)mcs.anl.gov <mailto:[email protected]>> wrote: >> > Could you try to run the following simple code to see if it works? >> > >> > #include <mpi.h> >> > #include <stdio.h> >> > int main(int argc, char** argv) >> > { >> > int rank, size; >> > MPI_Init(&argc, &argv); >> > MPI_Comm_rank(MPI_COMM_WORLD, &rank); >> > printf("rank %d\n", rank); >> > MPI_Finalize(); >> > return 0; >> > } >> > >> > — >> > Huiwei >> > >> > > On Nov 25, 2014, at 11:11 PM, Amin Hassani >> <ahassani(a)cis.uab.edu <mailto:[email protected]>> wrote: >> > > >> > > No, I checked. Also I always install my MPI's in >> /nethome/students/ahassani/usr/mpi. I never install them in >> /nethome/students/ahassani/usr. So MPI files will never get there. >> Even if put the /usr/mpi/bin in front of /usr/bin, it won't affect >> anything. There has never been any mpi installed in /usr/bin. >> > > >> > > 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 >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] code from different version of LINUX
by Junchao Zhang 26 Nov '14

26 Nov '14

Do you run your program on one node with 20 processes, and the result is correct except the time is slower? If yes, then it seems only one CPU of the node is used, which is weird. --Junchao Zhang On Wed, Nov 26, 2014 at 1:22 PM, Shuchi Yang <yang.shuchi(a)gmail.com> wrote: > I am doing CFD simulation. > With MPI, I can split the computational domain to different parts so that > each process works on different part. In this case, we can reduce the total > computational time. > > When I tried to run at another different system, it looks all the cpu are > working on the whole computational domain. It looks like every CPU is > working on the whole computational domain so that the computational > efficiency is very low. > > > > On Wed, Nov 26, 2014 at 11:45 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> > wrote: > >> I guess it is not an MPI problem. When you say "every CPU works on all >> the data", you need a clear idea of what is the data decomposition in your >> code. >> >> >> --Junchao Zhang >> >> On Wed, Nov 26, 2014 at 11:28 AM, Shuchi Yang <yang.shuchi(a)gmail.com> >> wrote: >> >>> Thanks for your reply. I am trying it in the way you mentioned. >>> But I met one problem is that on my original machine, I can run the code >>> with 20 CPUs so that each CPU works on part of the job. But at the new >>> machine, it starts the process with 20 CPUS, but every CPU works on all the >>> data, so that it looks like it is running 20 times the job at same time. Is >>> that because of MPI problem? >>> Thanks, >>> >>> Shuchi >>> >>> On Wed, Nov 26, 2014 at 9:50 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>> wrote: >>> >>>> You can copy MPI libraries installed on the Ubuntu machine to the Suse >>>> machine, then add that path to LD_LIBRARY_PATH on the Suse. >>>> >>>> --Junchao Zhang >>>> >>>> On Wed, Nov 26, 2014 at 9:55 AM, Shuchi Yang <yang.shuchi(a)gmail.com> >>>> wrote: >>>> >>>>> I met some problem. >>>>> The question is that >>>>> I compile a fortran code at ubuntu, but I need run the code at Suse >>>>> Linux, I was always told >>>>> * error while loading shared libraries: libmpifort.so.12: cannot >>>>> open shared object file: No such file or directory* >>>>> >>>>> Furthermore, will this be a problem, I mean, if I compile the code >>>>> with mpich-gcc and run the code at another type of Linux? >>>>> >>>>> Thanks, >>>>> >>>>> Shuchi >>>>> >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] code from different version of LINUX
by Shuchi Yang 26 Nov '14

26 Nov '14

I am doing CFD simulation. With MPI, I can split the computational domain to different parts so that each process works on different part. In this case, we can reduce the total computational time. When I tried to run at another different system, it looks all the cpu are working on the whole computational domain. It looks like every CPU is working on the whole computational domain so that the computational efficiency is very low. On Wed, Nov 26, 2014 at 11:45 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > I guess it is not an MPI problem. When you say "every CPU works on all > the data", you need a clear idea of what is the data decomposition in your > code. > > > --Junchao Zhang > > On Wed, Nov 26, 2014 at 11:28 AM, Shuchi Yang <yang.shuchi(a)gmail.com> > wrote: > >> Thanks for your reply. I am trying it in the way you mentioned. >> But I met one problem is that on my original machine, I can run the code >> with 20 CPUs so that each CPU works on part of the job. But at the new >> machine, it starts the process with 20 CPUS, but every CPU works on all the >> data, so that it looks like it is running 20 times the job at same time. Is >> that because of MPI problem? >> Thanks, >> >> Shuchi >> >> On Wed, Nov 26, 2014 at 9:50 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >>> You can copy MPI libraries installed on the Ubuntu machine to the Suse >>> machine, then add that path to LD_LIBRARY_PATH on the Suse. >>> >>> --Junchao Zhang >>> >>> On Wed, Nov 26, 2014 at 9:55 AM, Shuchi Yang <yang.shuchi(a)gmail.com> >>> wrote: >>> >>>> I met some problem. >>>> The question is that >>>> I compile a fortran code at ubuntu, but I need run the code at Suse >>>> Linux, I was always told >>>> * error while loading shared libraries: libmpifort.so.12: cannot >>>> open shared object file: No such file or directory* >>>> >>>> Furthermore, will this be a problem, I mean, if I compile the code with >>>> mpich-gcc and run the code at another type of Linux? >>>> >>>> Thanks, >>>> >>>> Shuchi >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0