- Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation
by unknown＠example.com 12 Mar '09

12 Mar '09

More importantly, how is const handled? Is it just cast away inside the MPI library? On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > Since the main purpose of an implementation for something like > adding const is to see how invasive the change is, would it be > possible to get a diff against the trees that these were created from? > > Thanks, > Keith > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Thursday, March 12, 2009 12:24 PM > To: MPI 2.2 > Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - > implementation > > > Implementation for ticket #46 is now available from ANL (thanks Pavan) > > > tarballs > http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… > > > thanks, > .Erez > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation
by unknown＠example.com 12 Mar '09

12 Mar '09

Since the main purpose of an implementation for something like adding const is to see how invasive the change is, would it be possible to get a diff against the trees that these were created from? Thanks, Keith ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Thursday, March 12, 2009 12:24 PM To: MPI 2.2 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Implementation for ticket #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46> is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… thanks, .Erez *

1 0

Ticket #46: Add const Keyword to the C bindings - implementation
by unknown＠example.com 12 Mar '09

12 Mar '09

Implementation for ticket #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46> is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… thanks, .Erez *

1 0

Re: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 09 Mar '09

09 Mar '09

On Mar 9, 2009, at 2:34 PM, Rajeev Thakur wrote: > Address-sized variables in MPI can be passed from C to Fortran or vice > versa, and I know of no c2f or f2c conversion functions for them. So > I think > MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of > the same > size at least implicitly. > I agree. Should we state this explicitly somewhere (if we didn't already)? > > Rajeev > > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave > Goodell > > Sent: Friday, March 06, 2009 1:09 PM > > To: MPI 2.2 > > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket > #18 > > > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > > ticket #18 [1]. Part of the proposal for ticket #18 is to add > > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > > Rolf's point was that it isn't defined in the standard > > whether or not > > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > > type. Obviously we cannot define a new predefined datatype > > corresponding to two different language types. I believe > > Rolf's view > > (correct me if I'm misrepresenting you, Rolf) was that the > > forum ought > > to make their equivalence explicit, irrespective of what > > happens with > > ticket #18. I'm ambivalent about this issue, but I need a > > resolution > > on it in order to get #18 into a final voteable state. > > > > So the larger question to the Forum is: Are these types exactly the > > same between the two languages? > > > > Looking at MPICH2 it seems that we try to make them the same > > size but > > there are some convoluted code paths in the build logic that might > > result in different sizes. I would not consider this to be a > > compelling argument that they are permitted to differ because the > > logic in question may simply be buggy or never exercised. > > Does anyone > > have an example from other MPI implementations where the > > types do/may > > differ? Do any Fortran experts out there know of instances where > > MPI_ADDRESS_KIND would be different from MPI_Aint? > > > > As for the impact on ticket #18, there are several ways to deal with > > this: > > > > 1) If the Forum decides that the types are always equivalent, > > add text > > to that effect (probably in a separate ticket) and otherwise stick > > with the current proposal. > > 2) If the Forum decides that the type equivalence is undefined, drop > > the new MPI_AINT/MPI_OFFSET types from the proposal. > > 3) If the Forum decides that the type equivalence is > > undefined, create > > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > > MPI_F_OFFSET (or some such names). > > 4) If the Forum decides that the type equivalence is undefined, make > > MPI_AINT/MPI_OFFSET only correspond to the C types. > > > > I'm inclined towards either #1 or #2, depending on what the Forum > > decides about the type equivalence. I also can separate the > > MPI_AINT/ > > MPI_OFFSET types out into a separate ticket if this becomes too > > contentious of an issue, but I'd like to keep it together for now > > since the text changes are easier to describe correctly in just one > > place. > > > > -Dave > > > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 09 Mar '09

09 Mar '09

Address-sized variables in MPI can be passed from C to Fortran or vice versa, and I know of no c2f or f2c conversion functions for them. So I think MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of the same size at least implicitly. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 06, 2009 1:09 PM > To: MPI 2.2 > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > ticket #18 [1]. Part of the proposal for ticket #18 is to add > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > Rolf's point was that it isn't defined in the standard > whether or not > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > type. Obviously we cannot define a new predefined datatype > corresponding to two different language types. I believe > Rolf's view > (correct me if I'm misrepresenting you, Rolf) was that the > forum ought > to make their equivalence explicit, irrespective of what > happens with > ticket #18. I'm ambivalent about this issue, but I need a > resolution > on it in order to get #18 into a final voteable state. > > So the larger question to the Forum is: Are these types exactly the > same between the two languages? > > Looking at MPICH2 it seems that we try to make them the same > size but > there are some convoluted code paths in the build logic that might > result in different sizes. I would not consider this to be a > compelling argument that they are permitted to differ because the > logic in question may simply be buggy or never exercised. > Does anyone > have an example from other MPI implementations where the > types do/may > differ? Do any Fortran experts out there know of instances where > MPI_ADDRESS_KIND would be different from MPI_Aint? > > As for the impact on ticket #18, there are several ways to deal with > this: > > 1) If the Forum decides that the types are always equivalent, > add text > to that effect (probably in a separate ticket) and otherwise stick > with the current proposal. > 2) If the Forum decides that the type equivalence is undefined, drop > the new MPI_AINT/MPI_OFFSET types from the proposal. > 3) If the Forum decides that the type equivalence is > undefined, create > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > MPI_F_OFFSET (or some such names). > 4) If the Forum decides that the type equivalence is undefined, make > MPI_AINT/MPI_OFFSET only correspond to the C types. > > I'm inclined towards either #1 or #2, depending on what the Forum > decides about the type equivalence. I also can separate the > MPI_AINT/ > MPI_OFFSET types out into a separate ticket if this becomes too > contentious of an issue, but I'd like to keep it together for now > since the text changes are easier to describe correctly in just one > place. > > -Dave > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >

1 0

MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 06 Mar '09

06 Mar '09

At the last meeting in San Jose, Rolf brought up a good point w.r.t. ticket #18 [1]. Part of the proposal for ticket #18 is to add MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. Rolf's point was that it isn't defined in the standard whether or not MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same type. Obviously we cannot define a new predefined datatype corresponding to two different language types. I believe Rolf's view (correct me if I'm misrepresenting you, Rolf) was that the forum ought to make their equivalence explicit, irrespective of what happens with ticket #18. I'm ambivalent about this issue, but I need a resolution on it in order to get #18 into a final voteable state. So the larger question to the Forum is: Are these types exactly the same between the two languages? Looking at MPICH2 it seems that we try to make them the same size but there are some convoluted code paths in the build logic that might result in different sizes. I would not consider this to be a compelling argument that they are permitted to differ because the logic in question may simply be buggy or never exercised. Does anyone have an example from other MPI implementations where the types do/may differ? Do any Fortran experts out there know of instances where MPI_ADDRESS_KIND would be different from MPI_Aint? As for the impact on ticket #18, there are several ways to deal with this: 1) If the Forum decides that the types are always equivalent, add text to that effect (probably in a separate ticket) and otherwise stick with the current proposal. 2) If the Forum decides that the type equivalence is undefined, drop the new MPI_AINT/MPI_OFFSET types from the proposal. 3) If the Forum decides that the type equivalence is undefined, create four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, MPI_F_OFFSET (or some such names). 4) If the Forum decides that the type equivalence is undefined, make MPI_AINT/MPI_OFFSET only correspond to the C types. I'm inclined towards either #1 or #2, depending on what the Forum decides about the type equivalence. I also can separate the MPI_AINT/ MPI_OFFSET types out into a separate ticket if this becomes too contentious of an issue, but I'd like to keep it together for now since the text changes are easier to describe correctly in just one place. -Dave [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 12 Feb '09

12 Feb '09

Possibly. I guess we could add the typedef vs #define argument into an advice to implementors. I personally have reasons to believe that the #define way could simplify adoption of this new useful feature in the foreseeable future. The unsigned Pandora box better stays closed. Was just a fancy thought of mine. Let's go with the default signed long for now. I'll probably add a comment to this end during review. Thanks for putting together this comprehensive proposal! -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 8:09 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Alexander, Isn't the representation of MPI_Count (#define vs typedef) a choice best left to each MPI implementation? At the standard level, we just mention that it is equivalent to an int in MPI 2.2. I pretty much modelled this after MPI_Offset and MPI_Aint. There has been no discussion so far MPI_Count being on long vs unsigned long in MPI 3.0. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 11:00 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Preparing for the next MPI Forum meeting
by unknown＠example.com 11 Feb '09

11 Feb '09

I've moved all pending tickets for MPI 2.2 to Milestone "2009/4/6 Chicago". Over the next few weeks, please: 1) Consider carefully the proposals that have had their first reading or vote. We will vote on these. 2) For tickets requiring reviews or rework, these *must* be in state "reviewed" *before* the next Forum meeting. Any item that is not ready for a first reading at the *beginning* of the next meeting will not be considered for MPI 2.2 (we're out of time). They need to have a single, readable proposal. If you need guidance or a straw vote, please conduct that by email in advance of the meeting. 3) Make sure that any ticket that should be considered has the "2009/4/6 Chicago" milestone - there are two with "Future", numbers 48 and 50. There are 41 items on which we will vote. Please come prepared to vote on these items. If you feel strongly about an item (particularly negatively), please use the comment feature on the wiki to make your case. That will help streamline the discussions at the Forum meeting. Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Alexander, Isn't the representation of MPI_Count (#define vs typedef) a choice best left to each MPI implementation? At the standard level, we just mention that it is equivalent to an int in MPI 2.2. I pretty much modelled this after MPI_Offset and MPI_Aint. There has been no discussion so far MPI_Count being on long vs unsigned long in MPI 3.0. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 11:00 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0