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

Re: [mpich-discuss] Problem running with Mingw64 on Windows 7
by Wesley Bland 03 Nov '13

03 Nov '13

Unfortunately, we haven't supported Windows since MPICH version 1.4.1p1. You can find out more at the FAQ page: http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… Thanks, Wesley On Nov 3, 2013, at 4:22 PM, Bill Greene <w.h.greene(a)gmail.com> wrote: > I am using the x86_64 distribution from the download page. > > I have no problems building the examples with both g++ and gfortran. > I can run the cxxpi.cxx example using mpiexec with no problems but when > I run the fpi.f example, I get this error message: > > /cygdrive/c/progra~1/MPICH2/bin/mpiexec.exe: error while loading shared libraries: ?: cannot open shared object file: No > such file or directory > > Using dumpbin, I can see that cxxpi.exe imports mpich2mpi.dll while fpi.exe imports > fmpich2g.dll and libgfortran_64-3.dll. > > The paths to both dlls are on my path. > > By the way, I can run fpi.exe directly from the command line with no problems. > > If anyone has ideas about what the problem is, I would be much obliged. > > Bill > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Problem running with Mingw64 on Windows 7
by Bill Greene 03 Nov '13

03 Nov '13

I am using the x86_64 distribution from the download page. I have no problems building the examples with both g++ and gfortran. I can run the cxxpi.cxx example using mpiexec with no problems but when I run the fpi.f example, I get this error message: /cygdrive/c/progra~1/MPICH2/bin/mpiexec.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Using dumpbin, I can see that cxxpi.exe imports mpich2mpi.dll while fpi.exe imports fmpich2g.dll and libgfortran_64-3.dll. The paths to both dlls are on my path. By the way, I can run fpi.exe directly from the command line with no problems. If anyone has ideas about what the problem is, I would be much obliged. Bill

1 0

Re: [mpich-discuss] Failed to allocate memory for an unexpected message
by Luiz Carlos da Costa Junior 01 Nov '13

01 Nov '13

Thanks On 1 November 2013 22:00, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On Nov 1, 2013, at 4:30 PM, Luiz Carlos da Costa Junior <lcjunior(a)ufrj.br> > wrote: > > I understand that I will have to have N buffers, one for each posted > MPI_Irecv. I will also have to TEST (using MPI_PROBE or MPI_WAITANY) until > a message comes. The result of this test will identify which one of the > posted MPI_Irecv has actually received the message and then process the > right buffer. Is this correct? > > Correct. > > > Should I have to change anything at the sender's processes? > > Likely not. But you need to think through your algorithm to confirm that. > > > At the end, my receiver process receives a message identifying that it > should exit this routine. What should I do with the already posted > MPI_Irecv's? Can I cancel them? > > Yes, you can with MPI_CANCEL. > > —- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > 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] Failed to allocate memory for an unexpected message
by Pavan Balaji 01 Nov '13

01 Nov '13

On Nov 1, 2013, at 4:30 PM, Luiz Carlos da Costa Junior <lcjunior(a)ufrj.br> wrote: > I understand that I will have to have N buffers, one for each posted MPI_Irecv. I will also have to TEST (using MPI_PROBE or MPI_WAITANY) until a message comes. The result of this test will identify which one of the posted MPI_Irecv has actually received the message and then process the right buffer. Is this correct? Correct. > Should I have to change anything at the sender's processes? Likely not. But you need to think through your algorithm to confirm that. > At the end, my receiver process receives a message identifying that it should exit this routine. What should I do with the already posted MPI_Irecv's? Can I cancel them? Yes, you can with MPI_CANCEL. —- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Failed to allocate memory for an unexpected message
by Luiz Carlos da Costa Junior 01 Nov '13

01 Nov '13

Hi Pavan, Ok, I got the point about unexpected messages. I can modify the program according to your note. But things aren't clear enough for me yet. You said: You don’t need to know how many messages you will receive. You only need > to make sure that whenever a message comes in, it knows which buffer it > should go into. One way to fix that is to post N receives with ANY_SOURCE > and ANY_TAG: I understand that I will have to have N buffers, one for each posted MPI_Irecv. I will also have to TEST (using MPI_PROBE or MPI_WAITANY) until a message comes. The result of this test will identify which one of the posted MPI_Irecv has actually received the message and then process the right buffer. Is this correct? Should I have to change anything at the sender's processes? At the end, my receiver process receives a message identifying that it should exit this routine. What should I do with the already posted MPI_Irecv's? Can I cancel them? Sorry for the newbie questions and thanks in advance for your attention. Regards, Luiz On 31 October 2013 16:31, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On Oct 31, 2013, at 12:14 PM, Luiz Carlos da Costa Junior < > lcjunior(a)ufrj.br> wrote: > > I noticed that the numbers of 261895 or 261894 unexpected messages > appear every time. > > I am using AWS machine with 60GB of RAM memory to run my application. We > could see during the execution that there was more than 30 GB available. > > Is this a internal limitation of MPICH implementation? Would it be > possible to recompile MPICH setting a different parameter? > > Do you know where exactly this limitation occurs? > > Unexpected messages is a bad idea in general. Even if it’s an internal > parameter setting (which it isn’t), it’s not a good idea to just increase > it. > > Can you modify your application to not have that many unexpected messages? > See my note on how you can post Irecvs to avoid this. > > —- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > 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.0.4 fails to compile on 32 bit Arch Linux
by Junchao Zhang 31 Oct '13

31 Oct '13

My two cents: Download a stand-alone hwloc and try to build it to see whose problem it is: hwloc, mpich, or gcc? --Junchao Zhang On Thu, Oct 31, 2013 at 9:05 PM, Mark E. Lee <mark(a)markelee.com> wrote: > Salutations! > > Find attached to this message my config.log and m.txt > > Regards, > Mark > > >Hi Mark, > > > >When reporting installation problems, we need you to also include full > >configure and make logs (config.log and m.txt). Please refer to > >http://www.mpich.org/static/downloads/3.0.4/mpich-3.0.4-installguide.pdf > > > >Best, > > Antonio > > > > > >On Thursday, October 31, 2013 06:14:15 PM Mark E. Lee wrote: > >> Salutations! > >> > >> I get an error while compiling mpich-3.0.4 on 32-bit Arch Linux with > >>GCC > >> 4.8.2-3 (from Arch official repositories). I am getting the following > >> error: > >> > >> > /home/test/build/src/mpich-3.0.5/src/pm/hydra/tools/topo/hwloc/hwloc/include > >> /private/cpuid.h:39: Error: symbol 'Lhwloc1' is already defined > >> Makefile:708: recipe for target 'topology-x86.lo' failed > >> > >> Any help would be greatly appreciated! > >> > >> Regards, > >> Mark > -- > Mark E. Lee <mark(a)markelee.com> > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Mpich 3.0.4 fails to compile on 32 bit Arch Linux
by Mark E. Lee 31 Oct '13

31 Oct '13

Salutations! Find attached to this message my config.log and m.txt Regards, Mark >Hi Mark, > >When reporting installation problems, we need you to also include full >configure and make logs (config.log and m.txt). Please refer to >http://www.mpich.org/static/downloads/3.0.4/mpich-3.0.4-installguide.pdf > >Best, > Antonio > > >On Thursday, October 31, 2013 06:14:15 PM Mark E. Lee wrote: >> Salutations! >> >> I get an error while compiling mpich-3.0.4 on 32-bit Arch Linux with >>GCC >> 4.8.2-3 (from Arch official repositories). I am getting the following >> error: >> >> /home/test/build/src/mpich-3.0.5/src/pm/hydra/tools/topo/hwloc/hwloc/include >> /private/cpuid.h:39: Error: symbol 'Lhwloc1' is already defined >> Makefile:708: recipe for target 'topology-x86.lo' failed >> >> Any help would be greatly appreciated! >> >> Regards, >> Mark -- Mark E. Lee <mark(a)markelee.com>

1 0