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

VA_ARGS support
by James Long 25 Feb '14

25 Feb '14

Under debian 7.4, trying to compile mpich-3.1 with Portland Group 13.6, or 14.2, same error results in both cases: make[3]: Entering directory `/home/user/mpich-3.1/src/pm/hydra' CC utils/alloc/alloc.lo PGC/x86-64 Linux 13.6-0 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2013, STMicroelectronics, Inc. All Rights Reserved. PGC-F-0249-#error -- "hydra requires VA_ARGS support" (./include/hydra.h: 79) PGC/x86-64 Linux 13.6-0: compilation aborted environment variables used: $ unset F90 $ export CC=pgcc $ export FC=pgf90 $ export CXX=pgCC $ export CPPFLAGS="-DNDEBUG -DpgiFortran" $ export CFLAGS="-O2 -V" $ export FFLAGS="-O2 -w -V" Thanks, Jim -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% James Long International Arctic Research Center University of Alaska Fairbanks jlong|at|alaska.edu (907) 474-2440 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

1 0

Re: [mpich-discuss] Warning message during "make"
by "Antonio J. Peña" 25 Feb '14

25 Feb '14

Hi Raymond, That is just a performance warning, but has absolutely no correctness implications. That comes from the tradeoff of performance vs. space. Sometimes we choose to pack a structure in spite of memory usage rather than optimizing access time to all of its fields, as we may consider that being of more interest. I hope this answers your question. Best, Antonio On 02/25/2014 04:48 AM, Raymond D Wright wrote: > Hello, > > If I could ask a beginners question - I get this warning in "m.txt" at > the end of doing "make": > > sed -e 's/^C/\!/g' -e '/EXTERNAL/d' \ > -e '/REAL\*8/d' \ > -e '/DOUBLE PRECISION/d' \ > -e '/MPI_WTICK/d' src/binding/f77/mpif.h > src/binding/f90/mpifnoext.h > MOD src/binding/f90/mpi_constants.mod-stamp > src/binding/f90/mpi_constants.f90(7): warning #6379: The structure > contains one or more misaligned fields. [MPI_STATUS] > TYPE :: MPI_Status > ----------------^ > > Is it likely to cause trouble when I start using mpich? > > (I need it for "hdf5","netcdf","io/api" as infrastructure to > "models-3/cmaq") > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Warning message during "make"
by Raymond D Wright 25 Feb '14

25 Feb '14

Hello, If I could ask a beginners question - I get this warning in "m.txt" at the end of doing "make": sed -e 's/^C/\!/g' -e '/EXTERNAL/d' \ -e '/REAL\*8/d' \ -e '/DOUBLE PRECISION/d' \ -e '/MPI_WTICK/d' src/binding/f77/mpif.h > src/binding/f90/mpifnoext.h MOD src/binding/f90/mpi_constants.mod-stamp src/binding/f90/mpi_constants.f90(7): warning #6379: The structure contains one or more misaligned fields. [MPI_STATUS] TYPE :: MPI_Status ----------------^ Is it likely to cause trouble when I start using mpich? (I need it for "hdf5","netcdf","io/api" as infrastructure to "models-3/cmaq")

1 0

Re: [mpich-discuss] MPICH 3.1 packages for Ubuntu, Debian and Slackware (x86 and amd64)
by Balaji, Pavan 24 Feb '14

24 Feb '14

Thanks, I’ve updated the downloads page: http://www.mpich.org/downloads/ — Pavan On 2/24/14, 11:36 AM, "Marcelo Soares Souza" <marcelo(a)cebacad.net> wrote: >mpich-3.1 packages > >* Ubuntu 13.10 (Saucy Salamander) > >- amd64 >http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1/mpich_3.1-1ubuntu_amd6 >4.deb > >- x86 >http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1/mpich_3.1-1ubuntu_i386 >.deb > >* Debian Wheezy (7.4.0) > >- amd64 >http://www.cebacad.net/files/mpich/debian/mpich-3.1/mpich_3.1-1debian_amd6 >4.deb > >- x86 >http://www.cebacad.net/files/mpich/debian/mpich-3.1/mpich_3.1-1debian_i386 >.deb > >* Slackware 14.1 > >- amd64 >http://www.cebacad.net/files/mpich/slackware/mpich-3.1/mpich-3.1-x86_64-go >a-1.txz > >- x86 >http://www.cebacad.net/files/mpich/slackware/mpich-3.1/mpich-3.1-i486-goa- >1.txz > >Enjoy! ;) > >-- >Marcelo Soares Souza >https://marcelo.juntadados.org > >Diaspora* >https://diaspora.juntadados.org/u/marcelo > >Friendica >http://friendica.ambientedigital.org/profile/marcelo >_______________________________________________ >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] MPI_Comm_spawn under torque
by Suraj Prabhakaran 24 Feb '14

24 Feb '14

And a short update to the previous email, doing MPI_Comm_spawn even without the ssh launcher and using the native Torque TM interface does not work and returns the same error. So in general, I can do MPI_Comm_spawn under the Torque environment immaterial of the launcher that I use. Without the torque environment, it works fine. Best, Suraj On Feb 24, 2014, at 6:37 PM, Suraj Prabhakaran wrote: > Hello, > > I am trying to do an MPI_Comm_spawn under Torque environment. But I want to use the ssh launcher instead of TM interface since there seems to be a problem with launching large processes through the TM interface. mpiexec across nodes in general works fine but when I spawn using MPI_Comm_spawn to do a remote spawn on another node, I get the following error. > > mpiexec -launcher ssh -np 8 ./example > > [pid 12026] starting up on host grsacc01! > [pid 12027] starting up on host grsacc01! > [pid 12028] starting up on host grsacc01! > [pid 12021] starting up on host grsacc01! > [pid 12023] starting up on host grsacc01! > [pid 12025] starting up on host grsacc01! > [pid 12022] starting up on host grsacc01! > [pid 12024] starting up on host grsacc01! > 0 completed MPI_Init > 4 completed MPI_Init > Parent [pid 12025] about to spawn! > 5 completed MPI_Init > 3 completed MPI_Init > Parent [pid 12024] about to spawn! > Parent [pid 12026] about to spawn! > 2 completed MPI_Init > Parent [pid 12023] about to spawn! > 7 completed MPI_Init > Parent [pid 12028] about to spawn! > Parent [pid 12021] about to spawn! > 6 completed MPI_Init > Parent [pid 12027] about to spawn! > 1 completed MPI_Init > Parent [pid 12022] about to spawn! > [pid 20535] starting up on host grsacc02! > [pid 20536] starting up on host grsacc02! > Assertion failed in file src/util/procmap/local_proc.c at line 112: my_node_id <= max_node_id > internal ABORT - process 0 > Assertion failed in file src/util/procmap/local_proc.c at line 112: my_node_id <= max_node_id > internal ABORT - process 1 > > =================================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = PID 20535 RUNNING AT grsacc02 > = EXIT CODE: 1 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > =================================================================================== > [proxy:0:0@grsacc01] HYD_pmcd_pmip_control_cmd_cb (pm/pmiserv/pmip_cb.c:886): assert (!closed) failed > [proxy:0:0@grsacc01] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status > [proxy:0:0@grsacc01] main (pm/pmiserv/pmip.c:206): demux engine error waiting for event > [mpiexec@grsacc01] HYDT_bscu_wait_for_completion (tools/bootstrap/utils/bscu_wait.c:76): one of the processes terminated badly; aborting > [mpiexec@grsacc01] HYDT_bsci_wait_for_completion (tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion > [mpiexec@grsacc01] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:218): launcher returned error waiting for completion > [mpiexec@grsacc01] main (ui/mpich/mpiexec.c:336): process manager error waiting for completion > > > Is there a way to get rid of this? > > Best, > Suraj

1 0

MPI_Comm_spawn under torque
by Suraj Prabhakaran 24 Feb '14

24 Feb '14

Hello, I am trying to do an MPI_Comm_spawn under Torque environment. But I want to use the ssh launcher instead of TM interface since there seems to be a problem with launching large processes through the TM interface. mpiexec across nodes in general works fine but when I spawn using MPI_Comm_spawn to do a remote spawn on another node, I get the following error. mpiexec -launcher ssh -np 8 ./example [pid 12026] starting up on host grsacc01! [pid 12027] starting up on host grsacc01! [pid 12028] starting up on host grsacc01! [pid 12021] starting up on host grsacc01! [pid 12023] starting up on host grsacc01! [pid 12025] starting up on host grsacc01! [pid 12022] starting up on host grsacc01! [pid 12024] starting up on host grsacc01! 0 completed MPI_Init 4 completed MPI_Init Parent [pid 12025] about to spawn! 5 completed MPI_Init 3 completed MPI_Init Parent [pid 12024] about to spawn! Parent [pid 12026] about to spawn! 2 completed MPI_Init Parent [pid 12023] about to spawn! 7 completed MPI_Init Parent [pid 12028] about to spawn! Parent [pid 12021] about to spawn! 6 completed MPI_Init Parent [pid 12027] about to spawn! 1 completed MPI_Init Parent [pid 12022] about to spawn! [pid 20535] starting up on host grsacc02! [pid 20536] starting up on host grsacc02! Assertion failed in file src/util/procmap/local_proc.c at line 112: my_node_id <= max_node_id internal ABORT - process 0 Assertion failed in file src/util/procmap/local_proc.c at line 112: my_node_id <= max_node_id internal ABORT - process 1 =================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = PID 20535 RUNNING AT grsacc02 = EXIT CODE: 1 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES =================================================================================== [proxy:0:0@grsacc01] HYD_pmcd_pmip_control_cmd_cb (pm/pmiserv/pmip_cb.c:886): assert (!closed) failed [proxy:0:0@grsacc01] HYDT_dmxu_poll_wait_for_event (tools/demux/demux_poll.c:76): callback returned error status [proxy:0:0@grsacc01] main (pm/pmiserv/pmip.c:206): demux engine error waiting for event [mpiexec@grsacc01] HYDT_bscu_wait_for_completion (tools/bootstrap/utils/bscu_wait.c:76): one of the processes terminated badly; aborting [mpiexec@grsacc01] HYDT_bsci_wait_for_completion (tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion [mpiexec@grsacc01] HYD_pmci_wait_for_completion (pm/pmiserv/pmiserv_pmci.c:218): launcher returned error waiting for completion [mpiexec@grsacc01] main (ui/mpich/mpiexec.c:336): process manager error waiting for completion Is there a way to get rid of this? Best, Suraj

1 0

MPICH 3.1 packages for Ubuntu, Debian and Slackware (x86 and amd64)
by Marcelo Soares Souza 24 Feb '14

24 Feb '14

mpich-3.1 packages * Ubuntu 13.10 (Saucy Salamander) - amd64 http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1/mpich_3.1-1ubuntu_amd64… - x86 http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1/mpich_3.1-1ubuntu_i386.… * Debian Wheezy (7.4.0) - amd64 http://www.cebacad.net/files/mpich/debian/mpich-3.1/mpich_3.1-1debian_amd64… - x86 http://www.cebacad.net/files/mpich/debian/mpich-3.1/mpich_3.1-1debian_i386.… * Slackware 14.1 - amd64 http://www.cebacad.net/files/mpich/slackware/mpich-3.1/mpich-3.1-x86_64-goa… - x86 http://www.cebacad.net/files/mpich/slackware/mpich-3.1/mpich-3.1-i486-goa-1… Enjoy! ;) -- Marcelo Soares Souza https://marcelo.juntadados.org Diaspora* https://diaspora.juntadados.org/u/marcelo Friendica http://friendica.ambientedigital.org/profile/marcelo

1 0

Re: [mpich-discuss] [petsc-dev] turning off MPI abort messages
by Jed Brown 22 Feb '14

22 Feb '14

Junchao Zhang <jczhang(a)mcs.anl.gov> writes: > See the wiki here<http://wiki.mpich.org/mpich/index.php/Tool_interfaces_(MPI-T),_MPICH_parame…> > for how to add a cvar in MPICH. > See MPI 3.0 Chapter 14.3.6 for how to access cvars in MPI. I'm not familiar with the semantics for collective cvars, but the attached code works for me (with my fixes to Jeff's patches applied to MPICH). In practice, perhaps we should go find MPIR_CVAR_SUPPRESS_ABORT_MESSAGE in advance to avoid iterating in the exit handler.

1 0

Re: [mpich-discuss] turning off MPI abort messages
by Jeff Hammond 22 Feb '14

22 Feb '14

Thanks for catching this. I tested my patch but not through valgrind. Thanks also for figuring out the line break issue. I figured that was coming from the device but didn't track it down. Jeff On Sat, Feb 22, 2014 at 2:07 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Jeff Hammond <jeff.science(a)gmail.com> writes: > >> https://trac.mpich.org/projects/mpich/ticket/2038 has the patches. > > Although I thought I once had an account on Trac, it doesn't seem to > know about me any more. Anyway, this patch passes an undefined > abort_str on to MPID_Abort. > > char abort_str[100], comm_name[MPI_MAX_OBJECT_NAME]; > ... > if (!MPIR_CVAR_SUPPRESS_ABORT_MESSAGE) > /* FIXME: This is not internationalized */ > MPIU_Snprintf(abort_str, 100, "application called MPI_Abort(%s, %d) - process %d", comm_name, errorcode, comm_ptr->rank); > mpi_errno = MPID_Abort( comm_ptr, mpi_errno, errorcode, abort_str ); > > > ==27285== Conditional jump or move depends on uninitialised value(s) > ==27285== at 0x56F2AE8: vfprintf (in /usr/lib/libc-2.19.so) > ==27285== by 0x56F5630: buffered_vfprintf (in /usr/lib/libc-2.19.so) > ==27285== by 0x56F06BD: vfprintf (in /usr/lib/libc-2.19.so) > ==27285== by 0x4E96336: MPIU_Error_printf (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) > ==27285== by 0x4EC0D93: MPID_Abort (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) > ==27285== by 0x40795B6: MPI_Abort (in /home/jed/usr/mpich-clang/lib/libpmpich.so.12.0.0) > ==27285== by 0x400808: main (in /home/jed/lang/mpi/a.out) > ==27285== > ==27285== Syscall param write(buf) points to uninitialised byte(s) > ==27285== at 0x5783470: __write_nocancel (in /usr/lib/libc-2.19.so) > ==27285== by 0x571E472: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib/libc-2.19.so) > ==27285== by 0x571DB32: new_do_write (in /usr/lib/libc-2.19.so) > ==27285== by 0x571EA85: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.19.so) > ==27285== by 0x56F56C5: buffered_vfprintf (in /usr/lib/libc-2.19.so) > ==27285== by 0x56F06BD: vfprintf (in /usr/lib/libc-2.19.so) > ==27285== by 0x4E96336: MPIU_Error_printf (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) > ==27285== by 0x4EC0D93: MPID_Abort (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) > ==27285== by 0x40795B6: MPI_Abort (in /home/jed/usr/mpich-clang/lib/libpmpich.so.12.0.0) > ==27285== by 0x400808: main (in /home/jed/lang/mpi/a.out) > ==27285== Address 0xffeffd130 is on thread 1's stack > > So I fix this: > > diff --git i/src/mpi/init/abort.c w/src/mpi/init/abort.c > index f0b4cdc..bb1a63b 100644 > --- i/src/mpi/init/abort.c > +++ w/src/mpi/init/abort.c > @@ -74,7 +74,7 @@ int MPI_Abort(MPI_Comm comm, int errorcode) > int mpi_errno = MPI_SUCCESS; > MPID_Comm *comm_ptr = NULL; > /* FIXME: 100 is arbitrary and may not be long enough */ > - char abort_str[100], comm_name[MPI_MAX_OBJECT_NAME]; > + char abort_str[100] = "", comm_name[MPI_MAX_OBJECT_NAME]; > int len = MPI_MAX_OBJECT_NAME; > MPID_MPI_STATE_DECL(MPID_STATE_MPI_ABORT); > > > and now I can sort of suppress the output: > > $ MPIR_CVAR_SUPPRESS_ABORT_MESSAGE=1 ./a.out > > $ > > so it prints a blank line which may not be acceptable if it is producing > a stream, but is otherwise fine. Passing abort_str=NULL is already used > for something else ("internal ABORT"), but the following cleans up the > output. > > diff --git i/src/mpid/ch3/src/mpid_abort.c w/src/mpid/ch3/src/mpid_abort.c > index f0877ca..74b8a56 100644 > --- i/src/mpid/ch3/src/mpid_abort.c > +++ w/src/mpid/ch3/src/mpid_abort.c > @@ -94,7 +94,7 @@ int MPID_Abort(MPID_Comm * comm, int mpi_errno, int exit_code, > #elif defined(MPIDI_DEV_IMPLEMENTS_ABORT) > MPIDI_CH3I_PMI_Abort(exit_code, error_msg); > #else > - MPIU_Error_printf("%s\n", error_msg); > + if (error_msg[0]) MPIU_Error_printf("%s\n", error_msg); > fflush(stderr); > #endif > > If this is acceptable, a similar change should be applied to the other > devices. -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-discuss] turning off MPI abort messages
by Jed Brown 22 Feb '14

22 Feb '14

Jeff Hammond <jeff.science(a)gmail.com> writes: > https://trac.mpich.org/projects/mpich/ticket/2038 has the patches. Although I thought I once had an account on Trac, it doesn't seem to know about me any more. Anyway, this patch passes an undefined abort_str on to MPID_Abort. char abort_str[100], comm_name[MPI_MAX_OBJECT_NAME]; ... if (!MPIR_CVAR_SUPPRESS_ABORT_MESSAGE) /* FIXME: This is not internationalized */ MPIU_Snprintf(abort_str, 100, "application called MPI_Abort(%s, %d) - process %d", comm_name, errorcode, comm_ptr->rank); mpi_errno = MPID_Abort( comm_ptr, mpi_errno, errorcode, abort_str ); ==27285== Conditional jump or move depends on uninitialised value(s) ==27285== at 0x56F2AE8: vfprintf (in /usr/lib/libc-2.19.so) ==27285== by 0x56F5630: buffered_vfprintf (in /usr/lib/libc-2.19.so) ==27285== by 0x56F06BD: vfprintf (in /usr/lib/libc-2.19.so) ==27285== by 0x4E96336: MPIU_Error_printf (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) ==27285== by 0x4EC0D93: MPID_Abort (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) ==27285== by 0x40795B6: MPI_Abort (in /home/jed/usr/mpich-clang/lib/libpmpich.so.12.0.0) ==27285== by 0x400808: main (in /home/jed/lang/mpi/a.out) ==27285== ==27285== Syscall param write(buf) points to uninitialised byte(s) ==27285== at 0x5783470: __write_nocancel (in /usr/lib/libc-2.19.so) ==27285== by 0x571E472: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib/libc-2.19.so) ==27285== by 0x571DB32: new_do_write (in /usr/lib/libc-2.19.so) ==27285== by 0x571EA85: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.19.so) ==27285== by 0x56F56C5: buffered_vfprintf (in /usr/lib/libc-2.19.so) ==27285== by 0x56F06BD: vfprintf (in /usr/lib/libc-2.19.so) ==27285== by 0x4E96336: MPIU_Error_printf (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) ==27285== by 0x4EC0D93: MPID_Abort (in /home/jed/usr/mpich-clang/lib/libmpich.so.12.0.0) ==27285== by 0x40795B6: MPI_Abort (in /home/jed/usr/mpich-clang/lib/libpmpich.so.12.0.0) ==27285== by 0x400808: main (in /home/jed/lang/mpi/a.out) ==27285== Address 0xffeffd130 is on thread 1's stack So I fix this: diff --git i/src/mpi/init/abort.c w/src/mpi/init/abort.c index f0b4cdc..bb1a63b 100644 --- i/src/mpi/init/abort.c +++ w/src/mpi/init/abort.c @@ -74,7 +74,7 @@ int MPI_Abort(MPI_Comm comm, int errorcode) int mpi_errno = MPI_SUCCESS; MPID_Comm *comm_ptr = NULL; /* FIXME: 100 is arbitrary and may not be long enough */ - char abort_str[100], comm_name[MPI_MAX_OBJECT_NAME]; + char abort_str[100] = "", comm_name[MPI_MAX_OBJECT_NAME]; int len = MPI_MAX_OBJECT_NAME; MPID_MPI_STATE_DECL(MPID_STATE_MPI_ABORT); and now I can sort of suppress the output: $ MPIR_CVAR_SUPPRESS_ABORT_MESSAGE=1 ./a.out $ so it prints a blank line which may not be acceptable if it is producing a stream, but is otherwise fine. Passing abort_str=NULL is already used for something else ("internal ABORT"), but the following cleans up the output. diff --git i/src/mpid/ch3/src/mpid_abort.c w/src/mpid/ch3/src/mpid_abort.c index f0877ca..74b8a56 100644 --- i/src/mpid/ch3/src/mpid_abort.c +++ w/src/mpid/ch3/src/mpid_abort.c @@ -94,7 +94,7 @@ int MPID_Abort(MPID_Comm * comm, int mpi_errno, int exit_code, #elif defined(MPIDI_DEV_IMPLEMENTS_ABORT) MPIDI_CH3I_PMI_Abort(exit_code, error_msg); #else - MPIU_Error_printf("%s\n", error_msg); + if (error_msg[0]) MPIU_Error_printf("%s\n", error_msg); fflush(stderr); #endif If this is acceptable, a similar change should be applied to the other devices.

1 0