- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI_Accumulate with MAXLOC does not error for incompatible types
by Jed Brown 01 Jan '13

01 Jan '13

On Tue, Jan 1, 2013 at 7:49 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > MPI_Accumulate permits the use of pre-defined reduction operations > with user-defined datatypes, provided the user-defined datatypes are > homogeneous. Your use of MPI_MAXLOC with MY_2INT for MPI_Accumulate > is legal in my reading of the standard. It may not be legal for > MPI_Reduce because of the stupid asymmetry (that I believe you have > pointed out in the past) wherein MPI_Reduce (and MPI_Allreduce) cannot > do things that MPI_Accumulate can do w.r.t. built-in MPI_Op with > user-defined MPI_Datatype. > > Perhaps MPI_Accumulate is correct in not generating but providing the > wrong answer for MPI_MAXLOC, which would be a bug of a different > nature. > Perhaps, but my reading is that the predefined Op is applied to the basic type from which I constructed MY_2INT (i.e., MPI_INT). Since MPI_MAXLOC does not apply to MPI_INT, this would be an error. I wouldn't know how to write precise language specifying the behavior that would lead to MPI_MAXLOC working with MY_2INT.

1 0

Re: [mpich-discuss] MPI_Accumulate with MAXLOC does not error for incompatible types
by Jeff Hammond 01 Jan '13

01 Jan '13

MPI_Accumulate permits the use of pre-defined reduction operations with user-defined datatypes, provided the user-defined datatypes are homogeneous. Your use of MPI_MAXLOC with MY_2INT for MPI_Accumulate is legal in my reading of the standard. It may not be legal for MPI_Reduce because of the stupid asymmetry (that I believe you have pointed out in the past) wherein MPI_Reduce (and MPI_Allreduce) cannot do things that MPI_Accumulate can do w.r.t. built-in MPI_Op with user-defined MPI_Datatype. Perhaps MPI_Accumulate is correct in not generating but providing the wrong answer for MPI_MAXLOC, which would be a bug of a different nature. Jeff On Tue, Jan 1, 2013 at 1:09 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > With MPI_Reduce, we get a nice helpful error message: > > Fatal error in PMPI_Reduce: Invalid MPI_Op, error stack: > PMPI_Reduce(1217)...........: MPI_Reduce(sbuf=0x7fff3e39fa50, > rbuf=0x7fff3e39fa40, count=1, dtype=USER<contig>, MPI_MAXLOC, root=0, > MPI_COMM_WORLD) failed > MPIR_MAXLOC_check_dtype(151): MPI_Op MPI_MAXLOC operation not defined for > this datatype > > > With MPI_Accumulate, we just get wrong results. See attached code using a > user-defined contiguous results. > > I care about this because I'm stuck [1] dispatching into alternative > mechanisms for type combinations that are not directly supported by MPI > (e.g., struct {int u; long long k;} and __float128). I missed a spot and had > a confusing bug that I think MPICH should be catching. > > > [1] As usual, the crud would evaporate if only MPI_Accumulate were > extensible over datatypes. > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

MPI_Accumulate with MAXLOC does not error for incompatible types
by Jed Brown 01 Jan '13

01 Jan '13

With MPI_Reduce, we get a nice helpful error message: Fatal error in PMPI_Reduce: Invalid MPI_Op, error stack: PMPI_Reduce(1217)...........: MPI_Reduce(sbuf=0x7fff3e39fa50, rbuf=0x7fff3e39fa40, count=1, dtype=USER<contig>, MPI_MAXLOC, root=0, MPI_COMM_WORLD) failed MPIR_MAXLOC_check_dtype(151): MPI_Op MPI_MAXLOC operation not defined for this datatype With MPI_Accumulate, we just get wrong results. See attached code using a user-defined contiguous results. I care about this because I'm stuck [1] dispatching into alternative mechanisms for type combinations that are not directly supported by MPI (e.g., struct {int u; long long k;} and __float128). I missed a spot and had a confusing bug that I think MPICH should be catching. [1] As usual, the crud would evaporate if only MPI_Accumulate were extensible over datatypes.

1 0

[PATCH] Use attribute layout_compatible for pair types
by Jed Brown 01 Jan '13

01 Jan '13

--- src/include/mpi.h.in | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)

1 0

Re: [mpich-discuss] Error in c.txt nemesis does not exist
by Pavan Balaji 01 Jan '13

01 Jan '13

On 01/01/2013 07:58 AM US Central Time, behzad moradi wrote: > can't exec > '/Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc-4.2' (No > such file or directory) > What is this error? Please don't use this mailing list unless it's an MPICH related error. FWIW, you just told us what the error is. You are not able to execute llvm-gcc-4.2. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Error in c.txt nemesis does not exist
by behzad moradi 01 Jan '13

01 Jan '13

can't exec '/Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc-4.2' (No such file or directory) What is this error? On Dec 24, 2012, at 5:33 AM, Pavan Balaji wrote: > > I'm cc'ing our Windows expert, Jayesh. He might know what's going on. > > -- Pavan > > On 12/05/2012 03:27 PM US Central Time, Ayesha Ghani wrote: >> Hi Dave >> >> >> Thanks for your help! I have tried to install a few versions of MPICH2 >> on cygwin now. >> >> For version 2-1.4, the c.txt file seems fine (no errors) but the m.txt >> file goes on for a while 'Entering directory' and 'Leaving directory' >> and then at the end outputs an error. >> >> make[1]: *** No rule to make target >> '/home/agha023/libraries/mpich2-1.4/src/mpl/Makefile.am' needed by >> '/home/agha023/libraries/mpich2-1.4/src/mpl/Makefile.in'. Stop >> make: *** [all-redirect] Error 1 >> >> >> From searching up forums this error occurs because make couldnt find >> instructions in the Makefile.in to build the target. However Makefile.am >> and Makefile.in both exist in the directory above. >> >> Again however I can't find a solution to this problem and would greatly >> appreciate any help. >> >> Should I email the m.txt and c.txt files? >> >> >> Kind Regards >> Ayesha Ghani >> >> >> >> >> >> >> >> >> On 6 December 2012 08:03, Dave Goodell <goodell(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> Try using mpich2-1.4 instead. It would not be surprising if there >> was a problem with 1.5 on cygwin. >> >> -Dave >> >> On Dec 4, 2012, at 8:48 PM PST, Ayesha Ghani wrote: >> >>> Hello >>> >>> >>> I was working through the installation instructions for mpich2 >> very carefully this time and my .c file has an error at the end: >>> 'immediate ERROR: nemesis does not exist' >>> >>> I would appreciate any assistance. >>> >>> >>> Kind Regards >>> Ayesha >>> <c.txt>_______________________________________________ >>> 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 >> > > -- > 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

building mpich2 with open64 compilers is difficult
by Michael Seman 31 Dec '12

31 Dec '12

I built mpich2 before with gcc and Intel compilers. I tried to compile with open64, so first tried mpich2-1.2.1p1 which I built with other compilers. The make proceeds, I see lot of CC commands, then at the first F90, it falls over. So I added the verbosity option V=1 to the make and tried again. When it got up to the offending "F90 mpi.f90" stage, I now see this at the tail of the make log: date > .libstamp1 make[4]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' make[4]: Entering directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' false -O2 -I. -c mpi.f90 -o _smpi.o mv -f _smpi.o mpi.lo make[4]: *** [mpi.lo] Error 1 make[4]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' make[3]: *** [all-redirect] Error 1 make[3]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' make[2]: *** [all-redirect] Error 1 make[2]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src' make: *** [all-redirect] Error 2 So "F90" has become "false" somewhere along the track. Configure variables were for 1.2.1p1: BUILD_DIR=/usr/local F90=openf90 F77=openf90 CC=opencc CXX=openCC CFLAGS="-fPIC -O" FFLAGS="-fPIC -fno-second-underscore -O" F90FLAGS="-fPIC -fno-second-underscore -O" FLAGS="--prefix=${BUILD_DIR} --enable-threads --enable-sharedlibs=gcc \ --enable-f77 --enable-f90 --enable-cxx" Next, I tried version 1.4 of mpich2, which requires changing a few things, such as F90 to FC and --enable-f90 to --enable-fc and adding --enabled-shared to flags. I used these configure variables with versions 1.3 to 1.5: BUILD_DIR=/usr/local F77=openf90 FC=openf90 CC=opencc CXX=openCC CFLAGS="-fPIC -O" FFLAGS="-fPIC -fno-second-underscore -O" FCFLAGS="-fPIC -fno-second-underscore -O" F77FLAGS="-fPIC -fno-second-underscore -O" FLAGS="--prefix=${BUILD_DIR} --enable-threads --enable-sharedlibs=gcc \ --enable-fc --enable-shared --enable-f77 --enable-cxx" Again this flops when make gets up to mpi.f90. I still see "false" instead of the FC compiler command. Only version 1.5 of mpich2 can be built okay with open64 compilers. I used version 4.2.4 of open64 under RHEL 5.8 64-bit. I also tried open64 version 4.2.1 Has anybody found other combinations to build mpich2 using open64?

1 0

Re: [mpich-discuss] [PATCH] Remove redundant declaration of PMPI_Comm_create_group
by Jim Dinan 31 Dec '12

31 Dec '12

Hi Jed, Thanks for the patch. I'll commit this to the MPICH trunk. ~Jim. On 12/31/12 2:28 PM, Jed Brown wrote: > --- > src/include/mpi.h.in | 1 - > 1 file changed, 1 deletion(-) > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

[PATCH] Remove redundant declaration of PMPI_Comm_create_group
by Jed Brown 31 Dec '12

31 Dec '12

--- src/include/mpi.h.in | 1 - 1 file changed, 1 deletion(-)

1 0

Re: [mpich-discuss] Paramesh with MPICH2 anyone?
by Angel de Vicente 31 Dec '12

31 Dec '12

Hi, Jeff Hammond <jeff.science(a)gmail.com> writes: > Per the instructions on the website, you should > contact paramesh_users(a)sourceforge.net. All evidence provided (which > is not much) indicates this is not a problem with MPICH and thus this > is the wrong list to handle these issues. Yes, I tried to get some information from the paramesh list (back in August), but the list is almost dead (7 messages (including mine) in the last three years), so that's why I thought to ask here in case somebody had tried it with MPICH2. > If you want help from this list, at least provide full details about > your system and MPICH build, all of the source code that is failing, > and the full output from failed jobs. When I have the chance to run it again and collect some info about the errors, I will post here again in case somebody can give some pointers about what could be causing Paramesh+MPICH2 to misbehave. Thanks, -- Ángel de Vicente http://www.iac.es/galeria/angelv/ --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protecci�n de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

1 0