And, thanks for finding so many detailed corrections,
- bill
In message "Jean-Pierre Prost" wrote
>
> P216-L5-6: I cannot recall the initial definition of num_io_nodes. I
> thought it was the number of I/O devices that should be used to store
> the file (when io_node_list is not specified and when all I/O devices
> are kind of equivalent for the application). This number could be
> smaller than the number of I/O devices in the system. And I think we
> should also specify: "This hint is most relevant when the file is created."
I have added "This hint is most relevant when the file is created",
although I believe this hint is most useful when retrieved (it returns
the number of I/O nodes in the system).
> P218-L6 is stronger than the sentence on P240-L36-37. I think they
> should agree, and if P218-L6 is to be kept, I would like to add that it
> is erroneous to use MPI_TYPE_HINDEXED or MPI_TYPE_HVECTOR when
> constructing an etype or filetype. In addition, sentences on
> P205-L29-31 and on P205-L37-38 may be respectively incorrect and
> ambiguous if P218-L6 is to be kept
I believe P218-L6 is correct:
"It is erroneous to use absolute addresses in
the construction of the etype and filetype".
And does not conflict with P240-L36-37,
"... it is important to avoid absolute file addressing."
The term "absolute addresses" refers to a particular MPI datatype
construct where you hardwire a memory address into a datatype
(e.g., 0x00001372). "Absolute file addressing" was supposed to
mean using literal offsets into a file (e.g., seek to byte offset 8
to get to the second REAL value).
I have changed the language on P240-L36-37; it now reads:
Data representations in internal or external32 mode
may be smaller or larger than the equivalent native
representations. For this reason, it is important to
avoid using hardwired offsets for file positioning. <-- NEW
Displacements and seek offsets should be calculated
by using the \func{MPI\_FILE\_GET\_TYPE\_EXTENT} routine,
which returns the extent of an \MPI/ datatype in an
open file.
> P227-L34: A figure showing what the end of the view represents would help
Agreed. Volunteers?
> P228-L45-46: This sentence is not true for SHARED_ORDERED routines
I have added: "For the non-collective shared file pointer routines,"
in front of: " the serialization ordering is not deterministic."
> P240-L9: didn't we decide to call the canonical representation
> ``external'' instead of ``external32'' since there is only one now (if
> this is the case all occurrences of ``external32'' should be replaced
> with ``external''.
My memory fails me here, but you are not the first
to suggest this change... (This is an easy change to make later too.)
What do others remember?
> (From John May's revised version - formatting his Tex source file)
> P3-L34: "with the same datatype and userbuf arguments
> and appropriate values"
I don't believe MPI is required to pass the same value for userbuf.