- mpi-comments - mailman3.cels.anl.gov

Re: [Mpi-comments] buffer error
by Wesley Bland 10 Jun '13

10 Jun '13

This mailing list isn't the correct place to ask questions about using MPI. This is for asking questions about standardizing MPI. I'd encourage you to repost your question on discuss(a)mpich.org and you'll get assistance with MPICH there. Thanks, Wesley On Jun 10, 2013, at 9:04 AM, amin izadi <izadi.amin(a)gmail.com> wrote: > hi to all > I want to use mpich for running my SUNTANS code > when I dont use mpich my example code runs. but when I use mpich > this error creates. > what's the problem and how can I fix it? > thanks in advance > > Fatal error in PMPI_Gather: Invalid buffer pointer, error stack: > PMPI_Gather(856): MPI_Gather(sbuf=0xe176a0, scount=1, MPI_INT, rbuf=0xe176a0, rcount=1, MPI_INT, root=0, comm=0x84000000) failed > PMPI_Gather(797): Buffers must not be aliased > > =================================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = EXIT CODE: 1 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

buffer error
by amin izadi 10 Jun '13

10 Jun '13

hi to all I want to use mpich for running my SUNTANS code when I dont use mpich my example code runs. but when I use mpich this error creates. what's the problem and how can I fix it? thanks in advance Fatal error in PMPI_Gather: Invalid buffer pointer, error stack: PMPI_Gather(856): MPI_Gather(sbuf=0xe176a0, scount=1, MPI_INT, rbuf=0xe176a0, rcount=1, MPI_INT, root=0, comm=0x84000000) failed PMPI_Gather(797): Buffers must not be aliased =================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 1 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES

1 0

MPI_GET_COUNT for nonblocking collective operations?
by Martin Bernreuther 24 Apr '13

24 Apr '13

Dear MPI forum, probably it doesn't make much sense to use MPI_GET_COUNT to get a count for nonblocking collective operations (since there is only one single count for send and receive), but nevertheless IMHO there should be a comment about the behaviour of this combination in the MPI standard. Looking at the MPI Version 3.0 "green book", there's a statement that MPI_SOURCE and MPI_TAG are undefined in this context on page 197 line 32f, but there seems to be nothing about MPI_GET_COUNT here as well as on page 31 in the MPI_GET_COUNT section. Sorry, if I just missed something here. (But other persons obviously also didn't see it, e.g. http://www.open-mpi.org/community/lists/users/2013/04/21777.php) Best regards, Martin Bernreuther -- ________________________________________________________________________ Dr.-Ing. Martin Bernreuther University of Stuttgart High Performance Computing Center (HLRS) Nobelstrasse 19 (Office: 1.307) 70569 Stuttgart, Germany Phone: (++49-(0)711) 685-64542 Fax: (++49-(0)711) 685-54542, -65832 E-Mail: bernreuther(a)hlrs.de URL: http://www.hlrs.de/people/bernreuther/

1 0

Thread synchronization for MPI_Get_address
by Jeremiah Willcock 25 Mar '13

25 Mar '13

In MPI 3.0, is MPI_Get_address subject to the same threading rules as other MPI calls? In particular, in MPI_THREAD_SERIALIZED mode, am I required to ensure that MPI_Get_address is not called at the same time as itself or other MPI code? If it does require synchronization currently, would it make sense to change that requirement to be looser? -- Jeremiah Willcock

1 0

Re: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Jeff Squyres (jsquyres) 26 Feb '13

26 Feb '13

Thank you Tobias; this is an extremely detailed report -- it is most excellent. I'm going to forward it to the Fortran working group (which you might want to join if you represent the Pathscale fortran group?): http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran On Feb 26, 2013, at 7:19 AM, Tobias Burnus <burnus(a)net-b.de> wrote: > Dear all, > > Digest version: The Fortran 2008 interface should use "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". > > > MPI 3 [1] adds a new Fortran 2008 interface (or rather one using Fortran 2008 [2] plus TS 29113 [3]), which uses C binding ("bind(C)"). For instance the following (from "6.7.2 Communicators"): > > ABSTRACT INTERFACE > SUBROUTINE MPI_Comm_copy_attr_function(oldcomm, comm_keyval, extra_state, > attribute_val_in, attribute_val_out, flag, ierror) BIND(C) > TYPE(MPI_Comm) :: oldcomm > INTEGER :: comm_keyval, ierror > INTEGER(KIND=MPI_ADDRESS_KIND) :: extra_state, attribute_val_in, > attribute_val_out > LOGICAL :: flag > > > The code assumes that the default-kind INTEGER and LOGICAL are interoperable. It is very likely that default-kind integers are interoperable, given that C supports many integer types (signed char, short, int, long, long long) and that Fortran's default-kind integer typically matches "int". > > > However, for LOGICAL this is not necessarily the case. Fortran's default-kind LOGICAL is always [5] as wide as the default-kind INTEGER ("LOGICAL(kind=4)"). However, C99's [4] _Bool is on nearly all systems (one exception is 32bit Darwin) only one byte wide (sizeof(_Bool) == 1) [6]. The Fortran standard only defines interoperability with this logical kind: > > > Fortran 2008, "15.2.2 Named constants and derived types in the module": "The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1." > > Fortran 2008, "Table 15.2: Interoperability between Fortran and C types": > "Fortran type / Named constant from the ISO C BINDING module (kind type parameter if value is positive) / C type" > ... > "LOGICAL / C_BOOL / _Bool" > > > Hence, a conforming compiler might only accept a single interoperable LOGICAL kind, namely: C_BOOL. That's actually the case for the PathScale/pathf95 compiler ï¿½ and also GCC/gfortran (version >= 4.8) with -std=f2003/f2008/f2008ts only accepts LOGICAL(C_BOOL) but not LOGICAL [7]. > > > Note an additional potential issue: C99's _Bool only allows two values, 0 and 1; see C99's "6.3.1.2 Boolean type": "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." > > At least the GCC makes use of this restriction and sets TYPE_PRECISION to 1 for C99/C++'s _Bool/bool and Fortran's LOGICAL (for all KIND= values). As the hardware typically supports instructions of the form "jump if zero" or "jump if not zero", also other values work in "if (bool_var)". However, for negation (C/C++: "!", Fortran: ".not."), GCC only flips one bit. Hence, for C99's _Bool, C++'s bool and Fortran's LOGICAL (any kind), negating "-2" leads to "-1". > > Example: If you have in one file: > "signed char bool_var = -2; sub(bool_var)" > and in the other file either: > void sub(_Bool bool_var) > or > subroutine sub(bool_var) bind(C) > logical(kind=C_Bool), value :: bool_var > both "bool_var" and "!bool_var"/".not.bool_var" evaluate to true/.true. > > In that sense, Fortran's "LOGICAL :: v" is not interoperable with C's "int v" unless the value is restricted to 0 and 1. > > Note regarding C99: If you assign or cast to _Bool, the compiler ensures that only the value 0 and 1 is used. Additionally, many operations in C99 return an "int", for instance "&&" or "||" do (see C99, "6.5.13 Logical AND operator" and 6.5.14). Thus, in pure C code one does not easily run into this issue. Nor in pure Fortran code as one there typically doesn't mix LOGICAL with INTEGER. But when mixing C and Fortran (or mixes code compiled iwth different compilers [8]), this can lead to wrong code. > > > Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL to LOGICAL(C_Bool). For the three reasons above: (a) the standard only defines interop with kind=C_Bool; (b) pathf95 [and gfortran with -std=f2008ts] only support C_Bool kind logicals with Bind(C); (c) at least with GCC, using default-kind LOGICAL might lead to wrong results if the value is not 0 or 1. > > > Tobias > > PS: The issue came up with Open MPI's bug report https://svn.open-mpi.org/trac/ompi/ticket/3523 > > > [1] MPI 3: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf; erratum http://www.mpi-forum.org/docs/errata-30.pdf > [2] Fortran 2008 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf ; corrigenda 1 & 2: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1903.pdf , ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1958.pdf > [3] TS 29113 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf > [4] C99+TC1,TC2,TC3: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > [5] That's required in Fortran 2008's "16.5.3.2 Storage sequence": "a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit," > [6] That _Bool has is one byte wide is implied by C99's "The rank of _Bool shall be less than the rank of all other standard integer types." (6.3.1.1), but in my reading it does not formally demand it. With GCC, one can force this width for 32bit Darwin via -mone-byte-bool. > [7] Currently, GCC still accepts LOGICAL / LOGICAL(4) with default options (-std=gnu); however, that might change. See discussion at http://gcc.gnu.org/ml/fortran/2013-01/msg00090.html and http://gcc.gnu.org/PR55758 > [8] In particular, Intel's Fortran compiler uses "-1" for .true., independent of logical kind and bind(C); for the reasons outlined above, it thus interacts badly with GCC/gfortran. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-comments] suspending a process in MPICH2
by Jim Dinan 26 Feb '13

26 Feb '13

Hello, This mailing list is for discussion relating to the MPI standardization process. Please direct your question to the discuss(a)mpich.org mailing list: http://www.mpich.org/support/mailing-lists/ Best, ~Jim. On 02/25/2013 04:37 PM, Ali Bouaricha wrote: > Hello, > > > > I wanted to suspend a process in MPICH2 by using kill(procid, SIGSTOP) > > But it seems that when I do that, the whole run gets suspended. > > Is there any implication of kill(procid,SIGSTOP) on the remainder of > processes? > > > > Please help. > > > > Thank you and Regards, > > > Ali Bouaricha > > > > > > > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments >

1 0

MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 26 Feb '13

26 Feb '13

Dear all, Digest version: The Fortran 2008 interface should use "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". MPI 3 [1] adds a new Fortran 2008 interface (or rather one using Fortran 2008 [2] plus TS 29113 [3]), which uses C binding ("bind(C)"). For instance the following (from "6.7.2 Communicators"): ABSTRACT INTERFACE SUBROUTINE MPI_Comm_copy_attr_function(oldcomm, comm_keyval, extra_state, attribute_val_in, attribute_val_out, flag, ierror) BIND(C) TYPE(MPI_Comm) :: oldcomm INTEGER :: comm_keyval, ierror INTEGER(KIND=MPI_ADDRESS_KIND) :: extra_state, attribute_val_in, attribute_val_out LOGICAL :: flag The code assumes that the default-kind INTEGER and LOGICAL are interoperable. It is very likely that default-kind integers are interoperable, given that C supports many integer types (signed char, short, int, long, long long) and that Fortran's default-kind integer typically matches "int". However, for LOGICAL this is not necessarily the case. Fortran's default-kind LOGICAL is always [5] as wide as the default-kind INTEGER ("LOGICAL(kind=4)"). However, C99's [4] _Bool is on nearly all systems (one exception is 32bit Darwin) only one byte wide (sizeof(_Bool) == 1) [6]. The Fortran standard only defines interoperability with this logical kind: Fortran 2008, "15.2.2 Named constants and derived types in the module": "The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1." Fortran 2008, "Table 15.2: Interoperability between Fortran and C types": "Fortran type / Named constant from the ISO C BINDING module (kind type parameter if value is positive) / C type" ... "LOGICAL / C_BOOL / _Bool" Hence, a conforming compiler might only accept a single interoperable LOGICAL kind, namely: C_BOOL. That's actually the case for the PathScale/pathf95 compiler — and also GCC/gfortran (version >= 4.8) with -std=f2003/f2008/f2008ts only accepts LOGICAL(C_BOOL) but not LOGICAL [7]. Note an additional potential issue: C99's _Bool only allows two values, 0 and 1; see C99's "6.3.1.2 Boolean type": "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." At least the GCC makes use of this restriction and sets TYPE_PRECISION to 1 for C99/C++'s _Bool/bool and Fortran's LOGICAL (for all KIND= values). As the hardware typically supports instructions of the form "jump if zero" or "jump if not zero", also other values work in "if (bool_var)". However, for negation (C/C++: "!", Fortran: ".not."), GCC only flips one bit. Hence, for C99's _Bool, C++'s bool and Fortran's LOGICAL (any kind), negating "-2" leads to "-1". Example: If you have in one file: "signed char bool_var = -2; sub(bool_var)" and in the other file either: void sub(_Bool bool_var) or subroutine sub(bool_var) bind(C) logical(kind=C_Bool), value :: bool_var both "bool_var" and "!bool_var"/".not.bool_var" evaluate to true/.true. In that sense, Fortran's "LOGICAL :: v" is not interoperable with C's "int v" unless the value is restricted to 0 and 1. Note regarding C99: If you assign or cast to _Bool, the compiler ensures that only the value 0 and 1 is used. Additionally, many operations in C99 return an "int", for instance "&&" or "||" do (see C99, "6.5.13 Logical AND operator" and 6.5.14). Thus, in pure C code one does not easily run into this issue. Nor in pure Fortran code as one there typically doesn't mix LOGICAL with INTEGER. But when mixing C and Fortran (or mixes code compiled iwth different compilers [8]), this can lead to wrong code. Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL to LOGICAL(C_Bool). For the three reasons above: (a) the standard only defines interop with kind=C_Bool; (b) pathf95 [and gfortran with -std=f2008ts] only support C_Bool kind logicals with Bind(C); (c) at least with GCC, using default-kind LOGICAL might lead to wrong results if the value is not 0 or 1. Tobias PS: The issue came up with Open MPI's bug report https://svn.open-mpi.org/trac/ompi/ticket/3523 [1] MPI 3: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf; erratum http://www.mpi-forum.org/docs/errata-30.pdf [2] Fortran 2008 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf ; corrigenda 1 & 2: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1903.pdf , ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1958.pdf [3] TS 29113 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf [4] C99+TC1,TC2,TC3: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf [5] That's required in Fortran 2008's "16.5.3.2 Storage sequence": "a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit," [6] That _Bool has is one byte wide is implied by C99's "The rank of _Bool shall be less than the rank of all other standard integer types." (6.3.1.1), but in my reading it does not formally demand it. With GCC, one can force this width for 32bit Darwin via -mone-byte-bool. [7] Currently, GCC still accepts LOGICAL / LOGICAL(4) with default options (-std=gnu); however, that might change. See discussion at http://gcc.gnu.org/ml/fortran/2013-01/msg00090.html and http://gcc.gnu.org/PR55758 [8] In particular, Intel's Fortran compiler uses "-1" for .true., independent of logical kind and bind(C); for the reasons outlined above, it thus interacts badly with GCC/gfortran.

1 0

suspending a process in MPICH2
by Ali Bouaricha 25 Feb '13

25 Feb '13

Hello, I wanted to suspend a process in MPICH2 by using kill(procid, SIGSTOP) But it seems that when I do that, the whole run gets suspended. Is there any implication of kill(procid,SIGSTOP) on the remainder of processes? Please help. Thank you and Regards, Ali Bouaricha

1 0

Re: [Mpi-comments] mpirun command
by Jim Dinan 21 Feb '13

21 Feb '13

Hello, This mailing list is for discussion relating to the MPI standardization process. Please direct your question to the discuss(a)mpich.org mailing list: http://www.mpich.org/support/mailing-lists/ That version of MPICH is also several years old, please try a newer version before posting your question. Best, ~Jim. On 2/21/13 9:51 AM, amin izadi wrote: > hi > I use fedora 17 64 bit OS and I want to use mpich > my original aim is to use mpirun command. although I installed > mpich-1.2.7 and my installation completed but no commands run. > pleeas help me. > if i want to use mpcih2, how can I use mpirun command? > > > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments >

1 0

mpirun command
by amin izadi 21 Feb '13

21 Feb '13

hi I use fedora 17 64 bit OS and I want to use mpich my original aim is to use mpirun command. although I installed mpich-1.2.7 and my installation completed but no commands run. pleeas help me. if i want to use mpcih2, how can I use mpirun command?

1 0