March 2013 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE
by Jeff Hammond 25 Mar '13

25 Mar '13

Hi Sayantan, Per Martin and Torsten, I've moved discussion of this issue to mpi3-coll(a)lists.mpi-forum.org. I'll respond to you on that list. Best, Jeff On Mon, Mar 25, 2013 at 12:24 PM, Sur, Sayantan <sayantan.sur(a)intel.com> wrote: > Does it make sense for some of these keys (esp. that deal with devices, multi-rail, paths etc.) to be part of the MPI Side documents? > > Sayantan > > >> -----Original Message----- >> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >> bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan >> Sent: Monday, March 25, 2013 7:16 AM >> To: mpi-forum(a)lists.mpi-forum.org >> Subject: Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE >> >> Hi Jeff, >> >> Please also include ticket #297 in the discussion (merge with your ticket, or >> otherwise): >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 >> >> This ticket proposes MPI_COMM_TYPE_NEIGHBORHOOD, which looks similar >> to MPI_COMM_TYPE_LOCALE. >> >> ~Jim. >> >> On 3/24/13 2:36 PM, Jeff Hammond wrote: >> > Martin encouraged me to socialize this with the Forum. The idea here >> > seems broader than just one working group so I'm sending to the entire >> > Forum for feedback. >> > >> > See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. The text >> > is included below in case it makes it easier to read on your >> > phone...because I know this is that urgent :-) >> > >> > Jeff >> > >> > >> > ---------- Forwarded message ---------- >> > From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >> > Date: Sun, Mar 24, 2013 at 1:50 PM >> > Subject: [MPI Forum] #372: additional keys for MPI_COMM_SPLIT_TYPE >> > To: >> > >> > >> > #372: additional keys for MPI_COMM_SPLIT_TYPE >> > -------------------------------------+-------------------------------- >> > -------------------------------------+----- >> > Reporter: | Owner: >> > jhammond | Status: new >> > Type: | Milestone: >> > Enhancements to standard | 2013/03/11 Chicago, USA >> > Priority: | Keywords: >> > Forum feedback requested | Author: Bill Gropp: 0 >> > Version: MPI | Author: Adam Moody: 0 >> > <next> | Author: Dick Treumann: 0 >> > Implementation status: | Author: George Bosilca: 0 >> > Waiting | Author: Bronis de Supinski: 0 >> > Author: Rich Graham: 0 | Author: Jeff Squyres: 0 >> > Author: Torsten Hoefler: 0 | Author: Rolf Rabenseifner: 0 >> > Author: Jesper Larsson Traeff: 0 | >> > Author: David Solt: 0 | >> > Author: Rajeev Thakur: 0 | >> > Author: Alexander Supalov: 0 | >> > -------------------------------------+-------------------------------- >> > -------------------------------------+----- >> > {{{MPI_COMM_SPLIT_TYPE}}} currently supports only on key, >> > {{{MPI_COMM_TYPE_SHARED}}}, which refers to shared memory >> domains, as >> > supported by shared memory windows >> ({{{MPI_WIN_ALLOCATE_SHARED}}}). >> > >> > This ticket proposes additional keys that appear useful enough to justify >> > standardization. >> > >> > The first key address the need for users to have a portable way of >> > querying properties of the filesystem. This key requires the user to >> > specify the specific file path of interest using an MPI_Info object. The >> > communicator returned represents the set of processes that can write to >> a >> > single instance of that file path. For a local disk, it is likely (but >> > not necessary) that this communicator be the same as returned by >> > {{{MPI_COMM_TYPE_SHARED}}}. On the other hand, globally shared >> > filesystems will return a duplicate of {{{MPI_COMM_WORLD}}}. When >> the >> > implementation cannot determine the answer, the resulting >> communicator is >> > {{{MPI_COMM_NULL}}} and users cannot assume any information about >> the >> > path. >> > >> > To be perfectly honest, the choice of {{{key = >> MPI_COMM_TYPE_SHARED}}} to >> > be only used for shared-memory is unfortunately, because we could have >> > instead used this key for anything that could be shared and let the >> > differences be enumerated by {{{MPI_Info}}}. For exampled, shared >> memory >> > windows could use {{{(key,value)=("memory","shared")}}} (granted, this >> is >> > a somewhat silly set of options, but it would naturally permit one to use >> > e.g. {{{(key,value)=("filepath","/home")}}} and >> > {{{(key,value)=("device","gpu0")}}}. We could implement the new set of >> > options using the existing key if we standardize {{{MPI_INFO_NULL}}} to >> > mean "shared memory" but that isn't particularly appealing. >> > >> > In addition to {{{MPI_COMM_TYPE_FILEPATH}}}, which is illustrated >> below, I >> > think that {{{MPI_COMM_TYPE_DEVICE}}} is useful to standardize as a key >> > without specifying the possible options that the {{{MPI_Info}}} can take, >> > with the exception of noting that, if this key is used with >> > {{{MPI_INFO_NULL}}}, the result is always {{{MPI_COMM_NULL}}}. >> Devices >> > that implementations could define include coprocessors (aka accelerators >> > or GPUs), NICs (e.g. in the case of multi-rail IB systems) and any number >> > of other machine-specific cases. The purpose of standardizing the key is >> > to encourage implementations to take the most portable route when >> trying >> > to implement this type of feature, thus confining all of the non-portable >> > aspects to the definition of the {{{(key,value)}}} pair in the info >> > object. >> > >> > I have also considered {{{MPI_COMM_TYPE_LOCALE}}}, which would also >> allow >> > the implementation to define info keys to specific, e.g. subcomms sharing >> > an IO node on Cray or Blue Gene, but this could just as easily be >> > implemented using the {{{MPI_COMM_TYPE_DEVICE}}} key. >> Furthermore, since >> > devices can be specified as a filepath (they often have an associated with >> > a {{{/dev/something}}} on Linux systems), there is no compelling reason >> to >> > add more than one key. This is, of course, the reason why overloading >> > {{{MPI_COMM_TYPE_SHARED}}} via info objects seems like the most >> > straightforward choice except in regards to backwards compatibility. >> > >> > What do people think? Can we augment {{{MPI_COMM_TYPE_SHARED}}} >> with info >> > keys and leave the case of {{{MPI_INFO_NULL}}} to mean shared >> memory, do >> > we break backwards compatibility or do we add a new key that has the >> > desired catch-all properties? >> > >> > Here is an example program illustrating the use of the proposed >> > functionality for {{{MPI_COMM_TYPE_FILEPATH}}}: >> > {{{ >> > >> > #include <stdio.h> >> > #include <stdlib.h> >> > #include <string.h> >> > #include <mpi.h> >> > >> > int main( int argc, char *argv[] ) >> > { >> > int rank; >> > MPI_Info i1, i2, i3, i4, i5; >> > MPI_Comm c0, c1, c2, c3, c4, c5; >> > int result, happy=0; >> > >> > MPI_Init(&argc,&argv); >> > MPI_Comm_rank(MPI_COMM_WORLD, &rank); >> > >> > MPI_Info_create( &i1 ); >> > MPI_Info_create( &i2 ); >> > MPI_Info_create( &i3 ); >> > MPI_Info_create( &i4 ); >> > MPI_Info_create( &i5 ); >> > >> > MPI_Info_set( i1, (char*)"path", (char*)"/global-shared-fs" ); >> > MPI_Info_set( i2, (char*)"path", (char*)"/proc-local-fs" ); >> > MPI_Info_set( i3, (char*)"path", (char*)"/node-local-fs" ); >> > MPI_Info_set( i4, (char*)"path", (char*)"/proc-zero-fs" ); >> > MPI_Info_set( i5, (char*)"path", (char*)"/dev/rand" ); >> > >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_SHARED, 0, >> > MPI_INFO_NULL, &c0 ); >> > >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_FILEPATH, 0, i1, >> > &c1 ); >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_FILEPATH, 0, i2, >> > &c2 ); >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_FILEPATH, 0, i3, >> > &c3 ); >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_FILEPATH, 0, i4, >> > &c4 ); >> > MPI_Comm_split_type( MPI_COMM_WORLD, >> MPI_COMM_TYPE_FILEPATH, 0, i5, >> > &c5 ); >> > >> > /* a globally visible shared filesystem should result in a comm that >> > is equivalent to world */ >> > MPI_Comm_compare( MPI_COMM_WORLD, c1, &result ); >> > if ( result == MPI_CONGRUENT) happy++; >> > >> > /* a process-local filesystem should result in MPI_COMM_SELF */ >> > MPI_Comm_compare( MPI_COMM_SELF, c2, &result ); >> > if ( result == MPI_CONGRUENT) happy++; >> > >> > /* a filesystem shared within the node is likely to result in a >> > communicator equivalent >> > to the one that supports shared memory, provided shared memory is >> > available */ >> > MPI_Comm_compare( c0, c3, &result ); >> > if ( result == MPI_CONGRUENT) happy++; >> > >> > /* the /proc-zero-fs is only visible from rank 0 of world... */ >> > if (rank==0) { >> > MPI_Comm_compare( MPI_COMM_SELF, c4, &result ); >> > if ( result == MPI_CONGRUENT) happy++; >> > } else { >> > if ( c4 == MPI_COMM_NULL) happy++; >> > } >> > >> > /* the sharable nature of /dev/rand is probably a meaningless concept >> > so >> > we expect the implementation to return MPI_COMM_NULL for c5 */ >> > if ( c5 == MPI_COMM_NULL) happy++; >> > >> > MPI_Comm_free( &c1 ); >> > MPI_Comm_free( &c2 ); >> > MPI_Comm_free( &c3 ); >> > MPI_Comm_free( &c4 ); >> > MPI_Comm_free( &c5 ); >> > >> > MPI_Info_free( &i1 ); >> > MPI_Info_free( &i2 ); >> > MPI_Info_free( &i3 ); >> > MPI_Info_free( &i4 ); >> > MPI_Info_free( &i5 ); >> > >> > MPI_Finalize( ); >> > return 0; >> > } >> > }}} >> > >> > -- >> > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372> >> > MPI Forum <https://svn.mpi-forum.org/> MPI Forum >> > >> > >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- 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

Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE
by Sur, Sayantan 25 Mar '13

25 Mar '13

Does it make sense for some of these keys (esp. that deal with devices, multi-rail, paths etc.) to be part of the MPI Side documents? Sayantan > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- > bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan > Sent: Monday, March 25, 2013 7:16 AM > To: mpi-forum(a)lists.mpi-forum.org > Subject: Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE > > Hi Jeff, > > Please also include ticket #297 in the discussion (merge with your ticket, or > otherwise): > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 > > This ticket proposes MPI_COMM_TYPE_NEIGHBORHOOD, which looks similar > to MPI_COMM_TYPE_LOCALE. > > ~Jim. > > On 3/24/13 2:36 PM, Jeff Hammond wrote: > > Martin encouraged me to socialize this with the Forum. The idea here > > seems broader than just one working group so I'm sending to the entire > > Forum for feedback. > > > > See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. The text > > is included below in case it makes it easier to read on your > > phone...because I know this is that urgent :-) > > > > Jeff > > > > > > ---------- Forwarded message ---------- > > From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> > > Date: Sun, Mar 24, 2013 at 1:50 PM > > Subject: [MPI Forum] #372: additional keys for MPI_COMM_SPLIT_TYPE > > To: > > > > > > #372: additional keys for MPI_COMM_SPLIT_TYPE > > -------------------------------------+-------------------------------- > > -------------------------------------+----- > > Reporter: | Owner: > > jhammond | Status: new > > Type: | Milestone: > > Enhancements to standard | 2013/03/11 Chicago, USA > > Priority: | Keywords: > > Forum feedback requested | Author: Bill Gropp: 0 > > Version: MPI | Author: Adam Moody: 0 > > <next> | Author: Dick Treumann: 0 > > Implementation status: | Author: George Bosilca: 0 > > Waiting | Author: Bronis de Supinski: 0 > > Author: Rich Graham: 0 | Author: Jeff Squyres: 0 > > Author: Torsten Hoefler: 0 | Author: Rolf Rabenseifner: 0 > > Author: Jesper Larsson Traeff: 0 | > > Author: David Solt: 0 | > > Author: Rajeev Thakur: 0 | > > Author: Alexander Supalov: 0 | > > -------------------------------------+-------------------------------- > > -------------------------------------+----- > > {{{MPI_COMM_SPLIT_TYPE}}} currently supports only on key, > > {{{MPI_COMM_TYPE_SHARED}}}, which refers to shared memory > domains, as > > supported by shared memory windows > ({{{MPI_WIN_ALLOCATE_SHARED}}}). > > > > This ticket proposes additional keys that appear useful enough to justify > > standardization. > > > > The first key address the need for users to have a portable way of > > querying properties of the filesystem. This key requires the user to > > specify the specific file path of interest using an MPI_Info object. The > > communicator returned represents the set of processes that can write to > a > > single instance of that file path. For a local disk, it is likely (but > > not necessary) that this communicator be the same as returned by > > {{{MPI_COMM_TYPE_SHARED}}}. On the other hand, globally shared > > filesystems will return a duplicate of {{{MPI_COMM_WORLD}}}. When > the > > implementation cannot determine the answer, the resulting > communicator is > > {{{MPI_COMM_NULL}}} and users cannot assume any information about > the > > path. > > > > To be perfectly honest, the choice of {{{key = > MPI_COMM_TYPE_SHARED}}} to > > be only used for shared-memory is unfortunately, because we could have > > instead used this key for anything that could be shared and let the > > differences be enumerated by {{{MPI_Info}}}. For exampled, shared > memory > > windows could use {{{(key,value)=("memory","shared")}}} (granted, this > is > > a somewhat silly set of options, but it would naturally permit one to use > > e.g. {{{(key,value)=("filepath","/home")}}} and > > {{{(key,value)=("device","gpu0")}}}. We could implement the new set of > > options using the existing key if we standardize {{{MPI_INFO_NULL}}} to > > mean "shared memory" but that isn't particularly appealing. > > > > In addition to {{{MPI_COMM_TYPE_FILEPATH}}}, which is illustrated > below, I > > think that {{{MPI_COMM_TYPE_DEVICE}}} is useful to standardize as a key > > without specifying the possible options that the {{{MPI_Info}}} can take, > > with the exception of noting that, if this key is used with > > {{{MPI_INFO_NULL}}}, the result is always {{{MPI_COMM_NULL}}}. > Devices > > that implementations could define include coprocessors (aka accelerators > > or GPUs), NICs (e.g. in the case of multi-rail IB systems) and any number > > of other machine-specific cases. The purpose of standardizing the key is > > to encourage implementations to take the most portable route when > trying > > to implement this type of feature, thus confining all of the non-portable > > aspects to the definition of the {{{(key,value)}}} pair in the info > > object. > > > > I have also considered {{{MPI_COMM_TYPE_LOCALE}}}, which would also > allow > > the implementation to define info keys to specific, e.g. subcomms sharing > > an IO node on Cray or Blue Gene, but this could just as easily be > > implemented using the {{{MPI_COMM_TYPE_DEVICE}}} key. > Furthermore, since > > devices can be specified as a filepath (they often have an associated with > > a {{{/dev/something}}} on Linux systems), there is no compelling reason > to > > add more than one key. This is, of course, the reason why overloading > > {{{MPI_COMM_TYPE_SHARED}}} via info objects seems like the most > > straightforward choice except in regards to backwards compatibility. > > > > What do people think? Can we augment {{{MPI_COMM_TYPE_SHARED}}} > with info > > keys and leave the case of {{{MPI_INFO_NULL}}} to mean shared > memory, do > > we break backwards compatibility or do we add a new key that has the > > desired catch-all properties? > > > > Here is an example program illustrating the use of the proposed > > functionality for {{{MPI_COMM_TYPE_FILEPATH}}}: > > {{{ > > > > #include <stdio.h> > > #include <stdlib.h> > > #include <string.h> > > #include <mpi.h> > > > > int main( int argc, char *argv[] ) > > { > > int rank; > > MPI_Info i1, i2, i3, i4, i5; > > MPI_Comm c0, c1, c2, c3, c4, c5; > > int result, happy=0; > > > > MPI_Init(&argc,&argv); > > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > > > > MPI_Info_create( &i1 ); > > MPI_Info_create( &i2 ); > > MPI_Info_create( &i3 ); > > MPI_Info_create( &i4 ); > > MPI_Info_create( &i5 ); > > > > MPI_Info_set( i1, (char*)"path", (char*)"/global-shared-fs" ); > > MPI_Info_set( i2, (char*)"path", (char*)"/proc-local-fs" ); > > MPI_Info_set( i3, (char*)"path", (char*)"/node-local-fs" ); > > MPI_Info_set( i4, (char*)"path", (char*)"/proc-zero-fs" ); > > MPI_Info_set( i5, (char*)"path", (char*)"/dev/rand" ); > > > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_SHARED, 0, > > MPI_INFO_NULL, &c0 ); > > > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_FILEPATH, 0, i1, > > &c1 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_FILEPATH, 0, i2, > > &c2 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_FILEPATH, 0, i3, > > &c3 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_FILEPATH, 0, i4, > > &c4 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, > MPI_COMM_TYPE_FILEPATH, 0, i5, > > &c5 ); > > > > /* a globally visible shared filesystem should result in a comm that > > is equivalent to world */ > > MPI_Comm_compare( MPI_COMM_WORLD, c1, &result ); > > if ( result == MPI_CONGRUENT) happy++; > > > > /* a process-local filesystem should result in MPI_COMM_SELF */ > > MPI_Comm_compare( MPI_COMM_SELF, c2, &result ); > > if ( result == MPI_CONGRUENT) happy++; > > > > /* a filesystem shared within the node is likely to result in a > > communicator equivalent > > to the one that supports shared memory, provided shared memory is > > available */ > > MPI_Comm_compare( c0, c3, &result ); > > if ( result == MPI_CONGRUENT) happy++; > > > > /* the /proc-zero-fs is only visible from rank 0 of world... */ > > if (rank==0) { > > MPI_Comm_compare( MPI_COMM_SELF, c4, &result ); > > if ( result == MPI_CONGRUENT) happy++; > > } else { > > if ( c4 == MPI_COMM_NULL) happy++; > > } > > > > /* the sharable nature of /dev/rand is probably a meaningless concept > > so > > we expect the implementation to return MPI_COMM_NULL for c5 */ > > if ( c5 == MPI_COMM_NULL) happy++; > > > > MPI_Comm_free( &c1 ); > > MPI_Comm_free( &c2 ); > > MPI_Comm_free( &c3 ); > > MPI_Comm_free( &c4 ); > > MPI_Comm_free( &c5 ); > > > > MPI_Info_free( &i1 ); > > MPI_Info_free( &i2 ); > > MPI_Info_free( &i3 ); > > MPI_Info_free( &i4 ); > > MPI_Info_free( &i5 ); > > > > MPI_Finalize( ); > > return 0; > > } > > }}} > > > > -- > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372> > > MPI Forum <https://svn.mpi-forum.org/> MPI Forum > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE
by Jim Dinan 25 Mar '13

25 Mar '13

Hi Jeff, Please also include ticket #297 in the discussion (merge with your ticket, or otherwise): https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 This ticket proposes MPI_COMM_TYPE_NEIGHBORHOOD, which looks similar to MPI_COMM_TYPE_LOCALE. ~Jim. On 3/24/13 2:36 PM, Jeff Hammond wrote: > Martin encouraged me to socialize this with the Forum. The idea here > seems broader than just one working group so I'm sending to the entire > Forum for feedback. > > See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. The text > is included below in case it makes it easier to read on your > phone...because I know this is that urgent :-) > > Jeff > > > ---------- Forwarded message ---------- > From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> > Date: Sun, Mar 24, 2013 at 1:50 PM > Subject: [MPI Forum] #372: additional keys for MPI_COMM_SPLIT_TYPE > To: > > > #372: additional keys for MPI_COMM_SPLIT_TYPE > -------------------------------------+------------------------------------- > Reporter: | Owner: > jhammond | Status: new > Type: | Milestone: > Enhancements to standard | 2013/03/11 Chicago, USA > Priority: | Keywords: > Forum feedback requested | Author: Bill Gropp: 0 > Version: MPI | Author: Adam Moody: 0 > <next> | Author: Dick Treumann: 0 > Implementation status: | Author: George Bosilca: 0 > Waiting | Author: Bronis de Supinski: 0 > Author: Rich Graham: 0 | Author: Jeff Squyres: 0 > Author: Torsten Hoefler: 0 | Author: Rolf Rabenseifner: 0 > Author: Jesper Larsson Traeff: 0 | > Author: David Solt: 0 | > Author: Rajeev Thakur: 0 | > Author: Alexander Supalov: 0 | > -------------------------------------+------------------------------------- > {{{MPI_COMM_SPLIT_TYPE}}} currently supports only on key, > {{{MPI_COMM_TYPE_SHARED}}}, which refers to shared memory domains, as > supported by shared memory windows ({{{MPI_WIN_ALLOCATE_SHARED}}}). > > This ticket proposes additional keys that appear useful enough to justify > standardization. > > The first key address the need for users to have a portable way of > querying properties of the filesystem. This key requires the user to > specify the specific file path of interest using an MPI_Info object. The > communicator returned represents the set of processes that can write to a > single instance of that file path. For a local disk, it is likely (but > not necessary) that this communicator be the same as returned by > {{{MPI_COMM_TYPE_SHARED}}}. On the other hand, globally shared > filesystems will return a duplicate of {{{MPI_COMM_WORLD}}}. When the > implementation cannot determine the answer, the resulting communicator is > {{{MPI_COMM_NULL}}} and users cannot assume any information about the > path. > > To be perfectly honest, the choice of {{{key = MPI_COMM_TYPE_SHARED}}} to > be only used for shared-memory is unfortunately, because we could have > instead used this key for anything that could be shared and let the > differences be enumerated by {{{MPI_Info}}}. For exampled, shared memory > windows could use {{{(key,value)=("memory","shared")}}} (granted, this is > a somewhat silly set of options, but it would naturally permit one to use > e.g. {{{(key,value)=("filepath","/home")}}} and > {{{(key,value)=("device","gpu0")}}}. We could implement the new set of > options using the existing key if we standardize {{{MPI_INFO_NULL}}} to > mean "shared memory" but that isn't particularly appealing. > > In addition to {{{MPI_COMM_TYPE_FILEPATH}}}, which is illustrated below, I > think that {{{MPI_COMM_TYPE_DEVICE}}} is useful to standardize as a key > without specifying the possible options that the {{{MPI_Info}}} can take, > with the exception of noting that, if this key is used with > {{{MPI_INFO_NULL}}}, the result is always {{{MPI_COMM_NULL}}}. Devices > that implementations could define include coprocessors (aka accelerators > or GPUs), NICs (e.g. in the case of multi-rail IB systems) and any number > of other machine-specific cases. The purpose of standardizing the key is > to encourage implementations to take the most portable route when trying > to implement this type of feature, thus confining all of the non-portable > aspects to the definition of the {{{(key,value)}}} pair in the info > object. > > I have also considered {{{MPI_COMM_TYPE_LOCALE}}}, which would also allow > the implementation to define info keys to specific, e.g. subcomms sharing > an IO node on Cray or Blue Gene, but this could just as easily be > implemented using the {{{MPI_COMM_TYPE_DEVICE}}} key. Furthermore, since > devices can be specified as a filepath (they often have an associated with > a {{{/dev/something}}} on Linux systems), there is no compelling reason to > add more than one key. This is, of course, the reason why overloading > {{{MPI_COMM_TYPE_SHARED}}} via info objects seems like the most > straightforward choice except in regards to backwards compatibility. > > What do people think? Can we augment {{{MPI_COMM_TYPE_SHARED}}} with info > keys and leave the case of {{{MPI_INFO_NULL}}} to mean shared memory, do > we break backwards compatibility or do we add a new key that has the > desired catch-all properties? > > Here is an example program illustrating the use of the proposed > functionality for {{{MPI_COMM_TYPE_FILEPATH}}}: > {{{ > > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <mpi.h> > > int main( int argc, char *argv[] ) > { > int rank; > MPI_Info i1, i2, i3, i4, i5; > MPI_Comm c0, c1, c2, c3, c4, c5; > int result, happy=0; > > MPI_Init(&argc,&argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > > MPI_Info_create( &i1 ); > MPI_Info_create( &i2 ); > MPI_Info_create( &i3 ); > MPI_Info_create( &i4 ); > MPI_Info_create( &i5 ); > > MPI_Info_set( i1, (char*)"path", (char*)"/global-shared-fs" ); > MPI_Info_set( i2, (char*)"path", (char*)"/proc-local-fs" ); > MPI_Info_set( i3, (char*)"path", (char*)"/node-local-fs" ); > MPI_Info_set( i4, (char*)"path", (char*)"/proc-zero-fs" ); > MPI_Info_set( i5, (char*)"path", (char*)"/dev/rand" ); > > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_SHARED, 0, > MPI_INFO_NULL, &c0 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i1, > &c1 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i2, > &c2 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i3, > &c3 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i4, > &c4 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i5, > &c5 ); > > /* a globally visible shared filesystem should result in a comm that > is equivalent to world */ > MPI_Comm_compare( MPI_COMM_WORLD, c1, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* a process-local filesystem should result in MPI_COMM_SELF */ > MPI_Comm_compare( MPI_COMM_SELF, c2, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* a filesystem shared within the node is likely to result in a > communicator equivalent > to the one that supports shared memory, provided shared memory is > available */ > MPI_Comm_compare( c0, c3, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* the /proc-zero-fs is only visible from rank 0 of world... */ > if (rank==0) { > MPI_Comm_compare( MPI_COMM_SELF, c4, &result ); > if ( result == MPI_CONGRUENT) happy++; > } else { > if ( c4 == MPI_COMM_NULL) happy++; > } > > /* the sharable nature of /dev/rand is probably a meaningless concept > so > we expect the implementation to return MPI_COMM_NULL for c5 */ > if ( c5 == MPI_COMM_NULL) happy++; > > MPI_Comm_free( &c1 ); > MPI_Comm_free( &c2 ); > MPI_Comm_free( &c3 ); > MPI_Comm_free( &c4 ); > MPI_Comm_free( &c5 ); > > MPI_Info_free( &i1 ); > MPI_Info_free( &i2 ); > MPI_Info_free( &i3 ); > MPI_Info_free( &i4 ); > MPI_Info_free( &i5 ); > > MPI_Finalize( ); > return 0; > } > }}} > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum > >

1 0

Re: [Mpi-forum] additional keys for MPI_COMM_SPLIT_TYPE
by Schulz, Martin 24 Mar '13

24 Mar '13

Hi Jeff, all, On Mar 24, 2013, at 12:36 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > Martin encouraged me to socialize this with the Forum. The idea here > seems broader than just one working group so I'm sending to the entire > Forum for feedback. I still think it would be good to have one WG take responsibility for this discussion. It seems to fit best into the collectives WG (and/or the communicator/groups chapter). Torsten: as the lead for the collectives group, does this sound reasonable to you? Thanks, Martin > > See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. The text > is included below in case it makes it easier to read on your > phone...because I know this is that urgent :-) > > Jeff > > > ---------- Forwarded message ---------- > From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> > Date: Sun, Mar 24, 2013 at 1:50 PM > Subject: [MPI Forum] #372: additional keys for MPI_COMM_SPLIT_TYPE > To: > > > #372: additional keys for MPI_COMM_SPLIT_TYPE > -------------------------------------+------------------------------------- > Reporter: | Owner: > jhammond | Status: new > Type: | Milestone: > Enhancements to standard | 2013/03/11 Chicago, USA > Priority: | Keywords: > Forum feedback requested | Author: Bill Gropp: 0 > Version: MPI | Author: Adam Moody: 0 > <next> | Author: Dick Treumann: 0 > Implementation status: | Author: George Bosilca: 0 > Waiting | Author: Bronis de Supinski: 0 > Author: Rich Graham: 0 | Author: Jeff Squyres: 0 > Author: Torsten Hoefler: 0 | Author: Rolf Rabenseifner: 0 > Author: Jesper Larsson Traeff: 0 | > Author: David Solt: 0 | > Author: Rajeev Thakur: 0 | > Author: Alexander Supalov: 0 | > -------------------------------------+------------------------------------- > {{{MPI_COMM_SPLIT_TYPE}}} currently supports only on key, > {{{MPI_COMM_TYPE_SHARED}}}, which refers to shared memory domains, as > supported by shared memory windows ({{{MPI_WIN_ALLOCATE_SHARED}}}). > > This ticket proposes additional keys that appear useful enough to justify > standardization. > > The first key address the need for users to have a portable way of > querying properties of the filesystem. This key requires the user to > specify the specific file path of interest using an MPI_Info object. The > communicator returned represents the set of processes that can write to a > single instance of that file path. For a local disk, it is likely (but > not necessary) that this communicator be the same as returned by > {{{MPI_COMM_TYPE_SHARED}}}. On the other hand, globally shared > filesystems will return a duplicate of {{{MPI_COMM_WORLD}}}. When the > implementation cannot determine the answer, the resulting communicator is > {{{MPI_COMM_NULL}}} and users cannot assume any information about the > path. > > To be perfectly honest, the choice of {{{key = MPI_COMM_TYPE_SHARED}}} to > be only used for shared-memory is unfortunately, because we could have > instead used this key for anything that could be shared and let the > differences be enumerated by {{{MPI_Info}}}. For exampled, shared memory > windows could use {{{(key,value)=("memory","shared")}}} (granted, this is > a somewhat silly set of options, but it would naturally permit one to use > e.g. {{{(key,value)=("filepath","/home")}}} and > {{{(key,value)=("device","gpu0")}}}. We could implement the new set of > options using the existing key if we standardize {{{MPI_INFO_NULL}}} to > mean "shared memory" but that isn't particularly appealing. > > In addition to {{{MPI_COMM_TYPE_FILEPATH}}}, which is illustrated below, I > think that {{{MPI_COMM_TYPE_DEVICE}}} is useful to standardize as a key > without specifying the possible options that the {{{MPI_Info}}} can take, > with the exception of noting that, if this key is used with > {{{MPI_INFO_NULL}}}, the result is always {{{MPI_COMM_NULL}}}. Devices > that implementations could define include coprocessors (aka accelerators > or GPUs), NICs (e.g. in the case of multi-rail IB systems) and any number > of other machine-specific cases. The purpose of standardizing the key is > to encourage implementations to take the most portable route when trying > to implement this type of feature, thus confining all of the non-portable > aspects to the definition of the {{{(key,value)}}} pair in the info > object. > > I have also considered {{{MPI_COMM_TYPE_LOCALE}}}, which would also allow > the implementation to define info keys to specific, e.g. subcomms sharing > an IO node on Cray or Blue Gene, but this could just as easily be > implemented using the {{{MPI_COMM_TYPE_DEVICE}}} key. Furthermore, since > devices can be specified as a filepath (they often have an associated with > a {{{/dev/something}}} on Linux systems), there is no compelling reason to > add more than one key. This is, of course, the reason why overloading > {{{MPI_COMM_TYPE_SHARED}}} via info objects seems like the most > straightforward choice except in regards to backwards compatibility. > > What do people think? Can we augment {{{MPI_COMM_TYPE_SHARED}}} with info > keys and leave the case of {{{MPI_INFO_NULL}}} to mean shared memory, do > we break backwards compatibility or do we add a new key that has the > desired catch-all properties? > > Here is an example program illustrating the use of the proposed > functionality for {{{MPI_COMM_TYPE_FILEPATH}}}: > {{{ > > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <mpi.h> > > int main( int argc, char *argv[] ) > { > int rank; > MPI_Info i1, i2, i3, i4, i5; > MPI_Comm c0, c1, c2, c3, c4, c5; > int result, happy=0; > > MPI_Init(&argc,&argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > > MPI_Info_create( &i1 ); > MPI_Info_create( &i2 ); > MPI_Info_create( &i3 ); > MPI_Info_create( &i4 ); > MPI_Info_create( &i5 ); > > MPI_Info_set( i1, (char*)"path", (char*)"/global-shared-fs" ); > MPI_Info_set( i2, (char*)"path", (char*)"/proc-local-fs" ); > MPI_Info_set( i3, (char*)"path", (char*)"/node-local-fs" ); > MPI_Info_set( i4, (char*)"path", (char*)"/proc-zero-fs" ); > MPI_Info_set( i5, (char*)"path", (char*)"/dev/rand" ); > > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_SHARED, 0, > MPI_INFO_NULL, &c0 ); > > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i1, > &c1 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i2, > &c2 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i3, > &c3 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i4, > &c4 ); > MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i5, > &c5 ); > > /* a globally visible shared filesystem should result in a comm that > is equivalent to world */ > MPI_Comm_compare( MPI_COMM_WORLD, c1, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* a process-local filesystem should result in MPI_COMM_SELF */ > MPI_Comm_compare( MPI_COMM_SELF, c2, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* a filesystem shared within the node is likely to result in a > communicator equivalent > to the one that supports shared memory, provided shared memory is > available */ > MPI_Comm_compare( c0, c3, &result ); > if ( result == MPI_CONGRUENT) happy++; > > /* the /proc-zero-fs is only visible from rank 0 of world... */ > if (rank==0) { > MPI_Comm_compare( MPI_COMM_SELF, c4, &result ); > if ( result == MPI_CONGRUENT) happy++; > } else { > if ( c4 == MPI_COMM_NULL) happy++; > } > > /* the sharable nature of /dev/rand is probably a meaningless concept > so > we expect the implementation to return MPI_COMM_NULL for c5 */ > if ( c5 == MPI_COMM_NULL) happy++; > > MPI_Comm_free( &c1 ); > MPI_Comm_free( &c2 ); > MPI_Comm_free( &c3 ); > MPI_Comm_free( &c4 ); > MPI_Comm_free( &c5 ); > > MPI_Info_free( &i1 ); > MPI_Info_free( &i2 ); > MPI_Info_free( &i3 ); > MPI_Info_free( &i4 ); > MPI_Info_free( &i5 ); > > MPI_Finalize( ); > return 0; > } > }}} > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum > > > -- > 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 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

additional keys for MPI_COMM_SPLIT_TYPE
by Jeff Hammond 24 Mar '13

24 Mar '13

Martin encouraged me to socialize this with the Forum. The idea here seems broader than just one working group so I'm sending to the entire Forum for feedback. See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. The text is included below in case it makes it easier to read on your phone...because I know this is that urgent :-) Jeff ---------- Forwarded message ---------- From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> Date: Sun, Mar 24, 2013 at 1:50 PM Subject: [MPI Forum] #372: additional keys for MPI_COMM_SPLIT_TYPE To: #372: additional keys for MPI_COMM_SPLIT_TYPE -------------------------------------+------------------------------------- Reporter: | Owner: jhammond | Status: new Type: | Milestone: Enhancements to standard | 2013/03/11 Chicago, USA Priority: | Keywords: Forum feedback requested | Author: Bill Gropp: 0 Version: MPI | Author: Adam Moody: 0 <next> | Author: Dick Treumann: 0 Implementation status: | Author: George Bosilca: 0 Waiting | Author: Bronis de Supinski: 0 Author: Rich Graham: 0 | Author: Jeff Squyres: 0 Author: Torsten Hoefler: 0 | Author: Rolf Rabenseifner: 0 Author: Jesper Larsson Traeff: 0 | Author: David Solt: 0 | Author: Rajeev Thakur: 0 | Author: Alexander Supalov: 0 | -------------------------------------+------------------------------------- {{{MPI_COMM_SPLIT_TYPE}}} currently supports only on key, {{{MPI_COMM_TYPE_SHARED}}}, which refers to shared memory domains, as supported by shared memory windows ({{{MPI_WIN_ALLOCATE_SHARED}}}). This ticket proposes additional keys that appear useful enough to justify standardization. The first key address the need for users to have a portable way of querying properties of the filesystem. This key requires the user to specify the specific file path of interest using an MPI_Info object. The communicator returned represents the set of processes that can write to a single instance of that file path. For a local disk, it is likely (but not necessary) that this communicator be the same as returned by {{{MPI_COMM_TYPE_SHARED}}}. On the other hand, globally shared filesystems will return a duplicate of {{{MPI_COMM_WORLD}}}. When the implementation cannot determine the answer, the resulting communicator is {{{MPI_COMM_NULL}}} and users cannot assume any information about the path. To be perfectly honest, the choice of {{{key = MPI_COMM_TYPE_SHARED}}} to be only used for shared-memory is unfortunately, because we could have instead used this key for anything that could be shared and let the differences be enumerated by {{{MPI_Info}}}. For exampled, shared memory windows could use {{{(key,value)=("memory","shared")}}} (granted, this is a somewhat silly set of options, but it would naturally permit one to use e.g. {{{(key,value)=("filepath","/home")}}} and {{{(key,value)=("device","gpu0")}}}. We could implement the new set of options using the existing key if we standardize {{{MPI_INFO_NULL}}} to mean "shared memory" but that isn't particularly appealing. In addition to {{{MPI_COMM_TYPE_FILEPATH}}}, which is illustrated below, I think that {{{MPI_COMM_TYPE_DEVICE}}} is useful to standardize as a key without specifying the possible options that the {{{MPI_Info}}} can take, with the exception of noting that, if this key is used with {{{MPI_INFO_NULL}}}, the result is always {{{MPI_COMM_NULL}}}. Devices that implementations could define include coprocessors (aka accelerators or GPUs), NICs (e.g. in the case of multi-rail IB systems) and any number of other machine-specific cases. The purpose of standardizing the key is to encourage implementations to take the most portable route when trying to implement this type of feature, thus confining all of the non-portable aspects to the definition of the {{{(key,value)}}} pair in the info object. I have also considered {{{MPI_COMM_TYPE_LOCALE}}}, which would also allow the implementation to define info keys to specific, e.g. subcomms sharing an IO node on Cray or Blue Gene, but this could just as easily be implemented using the {{{MPI_COMM_TYPE_DEVICE}}} key. Furthermore, since devices can be specified as a filepath (they often have an associated with a {{{/dev/something}}} on Linux systems), there is no compelling reason to add more than one key. This is, of course, the reason why overloading {{{MPI_COMM_TYPE_SHARED}}} via info objects seems like the most straightforward choice except in regards to backwards compatibility. What do people think? Can we augment {{{MPI_COMM_TYPE_SHARED}}} with info keys and leave the case of {{{MPI_INFO_NULL}}} to mean shared memory, do we break backwards compatibility or do we add a new key that has the desired catch-all properties? Here is an example program illustrating the use of the proposed functionality for {{{MPI_COMM_TYPE_FILEPATH}}}: {{{ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <mpi.h> int main( int argc, char *argv[] ) { int rank; MPI_Info i1, i2, i3, i4, i5; MPI_Comm c0, c1, c2, c3, c4, c5; int result, happy=0; MPI_Init(&argc,&argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Info_create( &i1 ); MPI_Info_create( &i2 ); MPI_Info_create( &i3 ); MPI_Info_create( &i4 ); MPI_Info_create( &i5 ); MPI_Info_set( i1, (char*)"path", (char*)"/global-shared-fs" ); MPI_Info_set( i2, (char*)"path", (char*)"/proc-local-fs" ); MPI_Info_set( i3, (char*)"path", (char*)"/node-local-fs" ); MPI_Info_set( i4, (char*)"path", (char*)"/proc-zero-fs" ); MPI_Info_set( i5, (char*)"path", (char*)"/dev/rand" ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_SHARED, 0, MPI_INFO_NULL, &c0 ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i1, &c1 ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i2, &c2 ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i3, &c3 ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i4, &c4 ); MPI_Comm_split_type( MPI_COMM_WORLD, MPI_COMM_TYPE_FILEPATH, 0, i5, &c5 ); /* a globally visible shared filesystem should result in a comm that is equivalent to world */ MPI_Comm_compare( MPI_COMM_WORLD, c1, &result ); if ( result == MPI_CONGRUENT) happy++; /* a process-local filesystem should result in MPI_COMM_SELF */ MPI_Comm_compare( MPI_COMM_SELF, c2, &result ); if ( result == MPI_CONGRUENT) happy++; /* a filesystem shared within the node is likely to result in a communicator equivalent to the one that supports shared memory, provided shared memory is available */ MPI_Comm_compare( c0, c3, &result ); if ( result == MPI_CONGRUENT) happy++; /* the /proc-zero-fs is only visible from rank 0 of world... */ if (rank==0) { MPI_Comm_compare( MPI_COMM_SELF, c4, &result ); if ( result == MPI_CONGRUENT) happy++; } else { if ( c4 == MPI_COMM_NULL) happy++; } /* the sharable nature of /dev/rand is probably a meaningless concept so we expect the implementation to return MPI_COMM_NULL for c5 */ if ( c5 == MPI_COMM_NULL) happy++; MPI_Comm_free( &c1 ); MPI_Comm_free( &c2 ); MPI_Comm_free( &c3 ); MPI_Comm_free( &c4 ); MPI_Comm_free( &c5 ); MPI_Info_free( &i1 ); MPI_Info_free( &i2 ); MPI_Info_free( &i3 ); MPI_Info_free( &i4 ); MPI_Info_free( &i5 ); MPI_Finalize( ); return 0; } }}} -- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372> MPI Forum <https://svn.mpi-forum.org/> MPI Forum -- 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

Re: [Mpi-forum] MPI 4.0 Chapter Committees
by Schulz, Martin 18 Mar '13

18 Mar '13

Hi Rolf, On Mar 18, 2013, at 4:59 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear Martin, > > You missed to include the new chapter: > > ï¿½ Removed Interfaces : ??? ï¿½ Thanks for catching this - I added this to my list. > > It would be nice, if other could assist especially in > the four non-automated one/zero-person-chapters, i.e., > >> ï¿½ Deprecated Functions : Rolf Rabenseifner(c) > ï¿½ Removed Interfaces : ??? (c) >> ï¿½ Annex Language Bindings Summary : Rolf Rabenseifner(c) > (A.1 is non-automated, A.2 - A.4 are mainly automated) >> ï¿½ Annex Change-Log : Rolf Rabenseifner(c) > > Although I'll come rearly this year to the meetings, > you can keep me for my tasks: > >> ï¿½ Terms and Definitions : Jeff Squyres, Rolf Rabenseifner(c), >> Bill Gropp, David Solt >> ï¿½ Deprecated Functions : Rolf Rabenseifner(c) >> ï¿½ Language Bindings : Jeffrey M. Squyres(c), Rolf Rabenseifner, >> Craig Rasmussen, Martin Schulz >> ï¿½ Annex Language Bindings Summary : Rolf Rabenseifner(c) >> ï¿½ Annex Change-Log : Rolf Rabenseifnerï¿½ Thanks, Martin > > Best regards > Rolf > > ----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Monday, March 18, 2013 7:39:52 AM >> Subject: [Mpi-forum] MPI 4.0 Chapter Committees >> Hi all, >> >> Another outcome of the discussions during the last forum meeting was a >> strong suggestion to introduce and socialize any new addition to MPI >> through the respective working groups and chapter committees first. >> This does, however, require active chapter committees, which currently >> is not always the case. Below is the list of the chapter committees >> that we used for MPI 3.0 - please take a look at the list and let me >> (directly or through the email list) know, if you are listed, whether >> you are still interested in serving on this committee, or, if you are >> not listed, if you would like to be included in one of the chapter >> committees. Members of chapter committees will be expected to help >> with the review process for items (errata, new functionality, minor >> changes, ï¿½) in their chapter and to actively provide overall guidance >> for new proposals that affect the respective chapters. If I don't hear >> back from people, I'll assume they are not or no longer interested. >> >> Thanks! >> >> Martin >> >> >> >> MPI 3.0 Chapter Committees >> http://localhost/~schulz6/trunk/mpi3.0_chapter_wgs.php >> >> ï¿½ Front matter : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler >> ï¿½ Introduction : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler >> ï¿½ Terms and Definitions : Jeff Squyres, Rolf Rabenseifner(c), Bill >> Gropp, David Solt >> ï¿½ Point-to-Point Communication : Richard Graham(c), Anthony Skjellum, >> Fab Tillier, Brian Smith, Devendar Bureddy, Bill Gropp, Torsten >> Hoefler, Adam Moody, Martin Schulz, Brian Barrett >> ï¿½ Datatypes - George Bosilca (c), Quincey Koziol, Anthony Skjellum, >> James Dinan, Dave Goodell, Adam Moody, David Solt, Fab Tillier >> ï¿½ Collective Communication : Adam Moody, Torsten Hoefler, Hideyuki >> Jitsumoto, Brian Smith, Fab Tillier >> ï¿½ Process Topologies : Torsten Hoefler(c), Puri Bangalore, Shinji >> Sumimoto, Dave Goodell, Adam Moody >> ï¿½ Groups, Contexts, and Communicators : Bill Gropp(c), Puri Bangalore, >> Bronis de Supinski, James Dinan, Dave Goodell, Josh Hursey, Adam >> Moody, Pavan Balaji >> ï¿½ Environmental Management : George Bosilca(c), Josh Hursey, Terry >> Dontje, Scott McMillan, Martin Shultz >> ï¿½ Info-Object : Darius Buntinas(c), Dave Goodell, Torsten Hoefler, >> Terry Dontje >> ï¿½ Process Creation and Management : David Solt(c), Josh Hursey, Terry >> Dontje, Scott McMillan, Douglas Miller >> ï¿½ One-Sided Communications : Bill Gropp(c), Rajeev Thakur(c), Sayantan >> Sur, Pavan Balaji, Devendar Bureddy, James Dinan, Torsten Hoefler, >> Douglas Miller, Adam Moody, Sreeram Potluri, Rajeev Thakur, Brian >> Barrett >> ï¿½ External Interfaces : Bronis R. de Supinski(c), Pavan Balaji, Pavan >> Balaji, James Dinan, Douglas Miller >> ï¿½ I/O : Rajeev Thakur(c), Quincey Koziol, Brian Smith, Mohamad >> Chaarawi, Adam Moody >> ï¿½ Profiling interface : Bronis R. de Supinski(c), Martin Schulz, Dave >> Goodell, Kathryn Mohror >> ï¿½ Deprecated Functions : Rolf Rabenseifner(c) >> ï¿½ Language Bindings : Jeffrey M. Squyres(c), Rolf Rabenseifner, Craig >> Rasmussen, Martin Schulz >> ï¿½ Annex Language Bindings Summary : Rolf Rabenseifner(c) >> ï¿½ Annex Change-Log : Rolf Rabenseifner(c) >> ï¿½ Bibliography : Bill Gropp(c) >> >> >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI 4.0 Chapter Committees
by Rolf Rabenseifner 18 Mar '13

18 Mar '13

Dear Martin, You missed to include the new chapter: • Removed Interfaces : ??? (c) It would be nice, if other could assist especially in the four non-automated one/zero-person-chapters, i.e., > • Deprecated Functions : Rolf Rabenseifner(c) • Removed Interfaces : ??? (c) > • Annex Language Bindings Summary : Rolf Rabenseifner(c) (A.1 is non-automated, A.2 - A.4 are mainly automated) > • Annex Change-Log : Rolf Rabenseifner(c) Although I'll come rearly this year to the meetings, you can keep me for my tasks: > • Terms and Definitions : Jeff Squyres, Rolf Rabenseifner(c), > Bill Gropp, David Solt > • Deprecated Functions : Rolf Rabenseifner(c) > • Language Bindings : Jeffrey M. Squyres(c), Rolf Rabenseifner, > Craig Rasmussen, Martin Schulz > • Annex Language Bindings Summary : Rolf Rabenseifner(c) > • Annex Change-Log : Rolf Rabenseifner(c) Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, March 18, 2013 7:39:52 AM > Subject: [Mpi-forum] MPI 4.0 Chapter Committees > Hi all, > > Another outcome of the discussions during the last forum meeting was a > strong suggestion to introduce and socialize any new addition to MPI > through the respective working groups and chapter committees first. > This does, however, require active chapter committees, which currently > is not always the case. Below is the list of the chapter committees > that we used for MPI 3.0 - please take a look at the list and let me > (directly or through the email list) know, if you are listed, whether > you are still interested in serving on this committee, or, if you are > not listed, if you would like to be included in one of the chapter > committees. Members of chapter committees will be expected to help > with the review process for items (errata, new functionality, minor > changes, …) in their chapter and to actively provide overall guidance > for new proposals that affect the respective chapters. If I don't hear > back from people, I'll assume they are not or no longer interested. > > Thanks! > > Martin > > > > MPI 3.0 Chapter Committees > http://localhost/~schulz6/trunk/mpi3.0_chapter_wgs.php > > • Front matter : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler > • Introduction : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler > • Terms and Definitions : Jeff Squyres, Rolf Rabenseifner(c), Bill > Gropp, David Solt > • Point-to-Point Communication : Richard Graham(c), Anthony Skjellum, > Fab Tillier, Brian Smith, Devendar Bureddy, Bill Gropp, Torsten > Hoefler, Adam Moody, Martin Schulz, Brian Barrett > • Datatypes - George Bosilca (c), Quincey Koziol, Anthony Skjellum, > James Dinan, Dave Goodell, Adam Moody, David Solt, Fab Tillier > • Collective Communication : Adam Moody, Torsten Hoefler, Hideyuki > Jitsumoto, Brian Smith, Fab Tillier > • Process Topologies : Torsten Hoefler(c), Puri Bangalore, Shinji > Sumimoto, Dave Goodell, Adam Moody > • Groups, Contexts, and Communicators : Bill Gropp(c), Puri Bangalore, > Bronis de Supinski, James Dinan, Dave Goodell, Josh Hursey, Adam > Moody, Pavan Balaji > • Environmental Management : George Bosilca(c), Josh Hursey, Terry > Dontje, Scott McMillan, Martin Shultz > • Info-Object : Darius Buntinas(c), Dave Goodell, Torsten Hoefler, > Terry Dontje > • Process Creation and Management : David Solt(c), Josh Hursey, Terry > Dontje, Scott McMillan, Douglas Miller > • One-Sided Communications : Bill Gropp(c), Rajeev Thakur(c), Sayantan > Sur, Pavan Balaji, Devendar Bureddy, James Dinan, Torsten Hoefler, > Douglas Miller, Adam Moody, Sreeram Potluri, Rajeev Thakur, Brian > Barrett > • External Interfaces : Bronis R. de Supinski(c), Pavan Balaji, Pavan > Balaji, James Dinan, Douglas Miller > • I/O : Rajeev Thakur(c), Quincey Koziol, Brian Smith, Mohamad > Chaarawi, Adam Moody > • Profiling interface : Bronis R. de Supinski(c), Martin Schulz, Dave > Goodell, Kathryn Mohror > • Deprecated Functions : Rolf Rabenseifner(c) > • Language Bindings : Jeffrey M. Squyres(c), Rolf Rabenseifner, Craig > Rasmussen, Martin Schulz > • Annex Language Bindings Summary : Rolf Rabenseifner(c) > • Annex Change-Log : Rolf Rabenseifner(c) > • Bibliography : Bill Gropp(c) > > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

MPI 4.0 Chapter Committees
by Schulz, Martin 18 Mar '13

18 Mar '13

Hi all, Another outcome of the discussions during the last forum meeting was a strong suggestion to introduce and socialize any new addition to MPI through the respective working groups and chapter committees first. This does, however, require active chapter committees, which currently is not always the case. Below is the list of the chapter committees that we used for MPI 3.0 - please take a look at the list and let me (directly or through the email list) know, if you are listed, whether you are still interested in serving on this committee, or, if you are not listed, if you would like to be included in one of the chapter committees. Members of chapter committees will be expected to help with the review process for items (errata, new functionality, minor changes, ï¿½) in their chapter and to actively provide overall guidance for new proposals that affect the respective chapters. If I don't hear back from people, I'll assume they are not or no longer interested. Thanks! Martin MPI 3.0 Chapter Committees http://localhost/~schulz6/trunk/mpi3.0_chapter_wgs.php ï¿½ Front matter : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler ï¿½ Introduction : Bill Gropp(c), Bronis de Supinski, Torsten Hoefler ï¿½ Terms and Definitions : Jeff Squyres, Rolf Rabenseifner(c), Bill Gropp, David Solt ï¿½ Point-to-Point Communication : Richard Graham(c), Anthony Skjellum, Fab Tillier, Brian Smith, Devendar Bureddy, Bill Gropp, Torsten Hoefler, Adam Moody, Martin Schulz, Brian Barrett ï¿½ Datatypes - George Bosilca (c), Quincey Koziol, Anthony Skjellum, James Dinan, Dave Goodell, Adam Moody, David Solt, Fab Tillier ï¿½ Collective Communication : Adam Moody, Torsten Hoefler, Hideyuki Jitsumoto, Brian Smith, Fab Tillier ï¿½ Process Topologies : Torsten Hoefler(c), Puri Bangalore, Shinji Sumimoto, Dave Goodell, Adam Moody ï¿½ Groups, Contexts, and Communicators : Bill Gropp(c), Puri Bangalore, Bronis de Supinski, James Dinan, Dave Goodell, Josh Hursey, Adam Moody, Pavan Balaji ï¿½ Environmental Management : George Bosilca(c), Josh Hursey, Terry Dontje, Scott McMillan, Martin Shultz ï¿½ Info-Object : Darius Buntinas(c), Dave Goodell, Torsten Hoefler, Terry Dontje ï¿½ Process Creation and Management : David Solt(c), Josh Hursey, Terry Dontje, Scott McMillan, Douglas Miller ï¿½ One-Sided Communications : Bill Gropp(c), Rajeev Thakur(c), Sayantan Sur, Pavan Balaji, Devendar Bureddy, James Dinan, Torsten Hoefler, Douglas Miller, Adam Moody, Sreeram Potluri, Rajeev Thakur, Brian Barrett ï¿½ External Interfaces : Bronis R. de Supinski(c), Pavan Balaji, Pavan Balaji, James Dinan, Douglas Miller ï¿½ I/O : Rajeev Thakur(c), Quincey Koziol, Brian Smith, Mohamad Chaarawi, Adam Moody ï¿½ Profiling interface : Bronis R. de Supinski(c), Martin Schulz, Dave Goodell, Kathryn Mohror ï¿½ Deprecated Functions : Rolf Rabenseifner(c) ï¿½ Language Bindings : Jeffrey M. Squyres(c), Rolf Rabenseifner, Craig Rasmussen, Martin Schulz ï¿½ Annex Language Bindings Summary : Rolf Rabenseifner(c) ï¿½ Annex Change-Log : Rolf Rabenseifner(c) ï¿½ Bibliography : Bill Gropp(c) ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] Voting / those who left early this week
by Schulz, Martin 18 Mar '13

18 Mar '13

Thanks, Jeff, for the summary. For those of you who were not at the meeting and/or haven't seen the new rules, yet, they are now also available on the MPI 4.0 page. Let me also reiterate Jeff's comments - based on the new rules, we'll enforce a quorum on all votes and if not enough organizations are present during the actual vote (following the new rules, especially if attendees leave early), we can't follow through with any votes. We also had a brief discussion on the scheduling of votes and we'll generally schedule them for the last day of the meeting (to leave the most time for discussions and errata readings before the votes). Hence, please plan travel accordingly. Thanks! Martin On Mar 15, 2013, at 6:48 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > As of today, the new voting rules are in effect. I have attached a copy of the 2013-03-15 procedures for your reading pleasure. We'll get this PDF up on the web site soon, too. > > *** THESE RULES HAVE IMPLICATIONS ON YOUR TRAVEL PLANS TO FORUM MEETINGS *** > > The new rules have a notion of "quorum". If enough organizations leave early, no ballots can take place. For example, the following organizations attended the Forum meetings earlier in the week, but skipped Thursday's meeting (i.e., the voting): > > - Kyushu U. > - Mellanox > - The Ohio State U. > - U. Alabama Birmingham > - U. Tokyo > > Under the old rules, these abstains counted as "no", but luckily we still had plenty of "yes" votes to successfully vote in the errata. > > Under the new rules: > > - Number of OOE organizations: 23 > - Number of IMOVE organization: 21 > - Meeting quorum: >2/3 OOE, or >15 organizations > - Individual ballot quorum: >3/4 IMOVE, or >15.75 organizations > > With 5 organizations leaving early, we had 16 voting organizations. This would have met quorum... barely. > > Voting is important. The schedule is published ahead of time. Please plan your travel accordingly. FWIW, I believe that the votes will be on the last day of the next meeting, too. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > <procedures-2013-03-15.pdf>_______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Voting / those who left early this week
by Jeff Squyres (jsquyres) 15 Mar '13

15 Mar '13

As of today, the new voting rules are in effect. I have attached a copy of the 2013-03-15 procedures for your reading pleasure. We'll get this PDF up on the web site soon, too. *** THESE RULES HAVE IMPLICATIONS ON YOUR TRAVEL PLANS TO FORUM MEETINGS *** The new rules have a notion of "quorum". If enough organizations leave early, no ballots can take place. For example, the following organizations attended the Forum meetings earlier in the week, but skipped Thursday's meeting (i.e., the voting): - Kyushu U. - Mellanox - The Ohio State U. - U. Alabama Birmingham - U. Tokyo Under the old rules, these abstains counted as "no", but luckily we still had plenty of "yes" votes to successfully vote in the errata. Under the new rules: - Number of OOE organizations: 23 - Number of IMOVE organization: 21 - Meeting quorum: >2/3 OOE, or >15 organizations - Individual ballot quorum: >3/4 IMOVE, or >15.75 organizations With 5 organizations leaving early, we had 16 voting organizations. This would have met quorum... barely. Voting is important. The schedule is published ahead of time. Please plan your travel accordingly. FWIW, I believe that the votes will be on the last day of the next meeting, too. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0