[Mpi-forum] Maximum limit of MPI identifiers

Tue Mar 15 20:38:04 CDT 2011

Hi Martin,
Nice work by the tools WG for putting this all together.  I've reviewed 
up to 1.3.7.  Here are some comments so far:

p 5 line 30, change "." to ","
"some of the MPI functions.  libpmpi.a" --> "some of the MPI functions, 
libpmpi.a"

p 7, line 44
I'm confused by the phrase "relative mesasure of complexity (basic, 
detailed or all)".  I think this refers to the amount of info provided, 
so perhaps "relative measure of information provided" or "relative 
measure of level of details" or something like that would be a better 
phrase.

p 8, line 15
"compexity level" --> something more descriptive, can't think of a good 
replacement right now, ideally would match replacement phrase above

p 7, line 45
Table number seems to be off for Table 1.3.1 vs 1.1?

p 8 lines 23-24
The following sounds strange:
    "These variables can apply globally to no specific object ..."
in
    "These variables can apply globally to no specific object or can 
refer to a particular MPI object such as ..."
Reword this to talk about the objects first, and then the global settings.
    "A variable may refer to a particular MPI object such as ..., or the 
variable may refer more generally to the MPI environment of the process."

Related question:  When you say "global", do you mean the MPI 
environment of a process, the environment of all processes, or both?
(Seems to be answered in Table 1.2)

p 8, lines 44-48
I'm confused by the rationale.  On the one hand, it says MPI should 
associate a variable with an object, but then is says it can reuse the 
variable on all objects of the respective type.  I probably need to 
think about it longer, but perhaps it can be reworded to be clearer.

p 9, line 12
Change
    "the size of the buffer as the length argument (n)."
to
    "the size of the buffer (n) as the length argument."
In the current wording, it's not clear whether "n" is the size of the 
buffer, or whether "n" is the name of the length argument.

p 9, line 19
"users" --> "user"

p 9, line 43-44
Change
    "It can be one of the four values listed above."
to
    "It can be one of the four values listed in Section ??."

p 9, line 47
Some rewording
    "The MPI specification does not require all MPI processes to exist 
before the call to MPI_INIT.  If MPI_T is used before MPI_INIT has been 
called, MPI_T_INIT_THREAD must be called on each process that exists."

p 10, line 28
Change
    "(for the concept of Sessions see Section 1.3.7)"
to just
    "(see Section 1.3.7)"

p 10, line 33
A rationale on why MPI_T_INIT_THREAD / MPI_T_FINALIZE can be called 
multiple times might be useful here.  Or perhaps this explanation could 
be placed in the intro at p 9, lie 29.

p 11, line 1
Change "datatype class" to just "class" -- lots of datatype words in 
that sentence.

p 11, line 4 and 5
Table reference seems to be off again (Table 1.3.5?)

p 11, line 5
What happens if datatype does not represent a valid datatype?  Erroneous 
call I presume.

p 12, line 13
Change
    "This routine returns, if datatpye represents a valid enumeration 
datatype, N representing the range of the enumeration 0 to N-1 as well 
as a string with a name for it."
    "The arguments name and ..."
to
    "If datatype is a valid enumeration datatype, this routine returns 
the enumeration range and the name of the datatype.  If the range runs 
from 0 to N-1, the value N is returned in num.  The arguments name and ..."

p 12, line 15
What happens if datatype is not a valid enumeration datatype?

p 12, line 34
We should specify that "item" should be an integer in the range of 0 to 
N-1, where N is the value returned from the call to 
MPI_T_DATATYPE_ENUM_GET_INFO.

p 14, line 25-29
I'd move rationale after the advice to users discussion of the function 
to p 14, line 47

p 14, line 38
"processor" --> "process"

p 14, line 41
Table 1.3.6 ??

p 15, line 14
Capitalize MPI_INIT and MPI_FINALIZE (lang neutral reference).

p 15, line 30-32
Reword first two sentences for clarity.  How about...
    "This routine binds the control variable specified by the argument 
index to the MPI object specified by the argument obj_handle and returns 
an allocated handle in the argument handle.  The value of index should 
be in the range 0 to N-1, where N is the number of available control 
variables as determined from a prior call to MPI_T_CVAR_GET_NUM.  The 
value of obj_handle must be the memory address of the object's MPI 
handle, and the type of MPI handle must be consistent with the type 
returned in the bind argument in a prior call to MPI_T_CVAR_GET_INFO."

p 16, line 13
Change
    "appropriate size and fits the entire value ..."
to
    "appropriate size to hold the entire value ..."

p 16, line 26
Same as above

Question: Is there a collective function to set a variable value on all 
processes at the same time?  Or maybe this is what you mean by 
consistent?  I think it would be good to expand upon this.  For example, 
if you increase the eager limit, you really need to make sure that all 
receivers increase the limit before a sender sends a new message of that 
size.

-Adam

Martin Schulz wrote:

>On Mar 15, 2011, at 1:59 PM, Adam T. Moody wrote:
>
>  
>
>>Hi Marin,
>>This is from an earlier email I sent.  I didn't get a reply, so I wasn't 
>>sure whether you missed it or not.  The page and line numbers are 
>>relative to MPI 2.2.
>>
>>That reminds me.  In reviewing the intro text for MPI_Count issues, I 
>>also came across these lines which may need to be tweaked for MPIT.
>>- You may want to warn users about "MPIT" and / or "mpit" prefixes on p 
>>16 lines 28-30, p 17 lines 42-43, p 18 line 16 and p 18 line 38.
>>- You may want to mention that MPIT errors are not fatal on p 22 line 46.
>>    
>>
>
>Thanks - yes, I missed those. I'll update the document in
>a third color :).
>
>Martin
>
>
>  
>
>>These may be minor issues, but I thought I'd double check with you anyway.
>>-Adam
>>
>>
>>Adam T. Moody wrote:
>>
>>    
>>
>>>Hi Martin,
>>>Interesting that this limit still applies.
>>>
>>>That reminds me.  In reviewing the intro text for MPI_Count issues, I 
>>>also came across these lines which may need to be tweaked for MPIT.
>>>- You may want to warn users about "MPIT" and / or "mpit" prefixes on p 
>>>16 lines 28-30, p 17 lines 42-43, p 18 line 16 and p 18 line 38.
>>>- You may want to mention that MPIT errors are not fatal on p 22 line 46.
>>>-Adam
>>>
>>>Martin Schulz wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi Adam,
>>>>
>>>>Thanks again for bringing this up - this is actually still
>>>>a valid concern (we had a discussion in the tools WG
>>>>today), since the official C99 standard only guarantees
>>>>identifiers of up to 31 characters. We'll change our 
>>>>names accordingly.
>>>>
>>>>Martin
>>>>
>>>>
>>>>
>>>>On Feb 8, 2011, at 2:12 PM, Moody, Adam T. wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi Martin,
>>>>>Here is the pointer to the lines about the maximum length of MPI identifiers.  I guess this applies to function names and predefined constants, etc.  This statement should be updated to address MPIT.
>>>>>
>>>>>Page 10, line 17-19.
>>>>>-Adam
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>________________________________________________________________________
>>>>Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
>>>>CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>
>________________________________________________________________________
>Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
>CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
>  
>