If the file data representation is other than ``native,'' care must be taken in constructing etypes and filetypes. Any of the datatype constructor functions may be used; however, for those functions that accept displacements in bytes, the displacements must be specified in terms of their values in the file for the file data representation being used. MPI will interpret these byte displacements as is; no scaling will be done. The function MPI_FILE_GET_TYPE_EXTENT can be used to calculate the extents of datatypes in the file. For etypes and filetypes that are portable datatypes (see Section Semantic Terms , page Semantic Terms ), MPI will scale any displacements in the datatypes to match the file data representation. Datatypes passed as arguments to read/write routines specify the data layout in memory; therefore, they must always be constructed using displacements corresponding to displacements in memory.
Advice to users.
One can logically think of the file as if it were stored in the memory of a
file server. The etype and filetype are interpreted
as if they were defined at this file server, by the same sequence of
calls used to define them at the calling process. If the data
representation is ``native'', then this logical file server runs on the
same architecture as the calling process, so that these types define
the same data layout on the file as they would define in the memory of
the calling process. If the etype and filetype are
portable datatypes, then the data layout defined in the file is the
same as would be defined in the calling process memory, up to a scaling
factor. The routine
MPI_FILE_GET_FILE_EXTENT
can be used to
calculate this scaling factor. Thus, two equivalent, portable
datatypes will define the same data layout in the file, even in a
heterogeneous environment with ``internal'', ``external32'', or user
defined data representations. Otherwise, the etype and
filetype must be constructed so that their typemap and extent
are the same on any architecture. This can be achieved if
they
have an explicit upper bound and lower bound (defined either using
MPI_LB and MPI_UB markers, or using
MPI_TYPE_CREATE_RESIZED). This condition must also be
fulfilled by any datatype that is used in the construction of the
etype and filetype, if this datatype is replicated
contiguously, either explicitly, by a call to
MPI_TYPE_CONTIGUOUS, or implictly, by a blocklength argument
that is greater than one. If an etype or filetype is
not portable, and has a typemap or extent that is architecture
dependent, then the data layout specified by it on a file is
implementation dependent.
File data representations other than ``native'' may
be different from corresponding data representations in
memory. Therefore, for these file data representations,
it is important not to use hardwired byte offsets for
file positioning, including the initial displacement that
specifies the view.
When a portable datatype
(see Section Semantic Terms
, page Semantic Terms
)
is used in a data access operation,
any holes in the datatype are scaled to match the data representation.
However,
note that this technique only works when all the processes
that created the file view build their etypes from the same
predefined datatypes.
For example, if one
process
uses an etype built from MPI_INT
and another uses an etype built from MPI_FLOAT,
the resulting views
may
be nonportable because the relative
sizes of these types may differ from one data representation to another.
( End of advice to users.)
int MPI_File_get_type_extent(MPI_File fh, MPI_Datatype datatype, MPI_Aint *extent)
Returns the extent of datatype in the file fh.
This extent will be the same for all processes accessing
the file fh.
If the current view uses a user-defined data representation
(see Section User-Defined Data Representations
, page User-Defined Data Representations
),
MPI uses the dtype_file_extent_fn callback
to calculate the extent.
In the case of user-defined data representations,
the extent of a derived datatype can be calculated
by first determining the extents of the predefined datatypes
in this derived datatype using dtype_file_extent_fn
(see Section User-Defined Data Representations
, page User-Defined Data Representations
).
( End of advice to implementors.)
MPI_FILE_GET_TYPE_EXTENT(fh, datatype, extent) IN fh file handle (handle) IN datatype datatype (handle) OUT extent datatype extent (integer)
MPI_FILE_GET_TYPE_EXTENT(FH, DATATYPE, EXTENT, IERROR)
INTEGER FH, DATATYPE, IERROR
INTEGER(KIND=MPI_ADDRESS_KIND) EXTENT
{ MPI::Aint MPI::File::Get_type_extent(const MPI::Datatype& datatype) const (binding deprecated, see Section Deprecated since MPI-2.2
) }
Advice
to implementors.
Up: File Interoperability
Next: External Data Representation: ``external32''
Previous: File Interoperability
Return to MPI-2.2 Standard Index
Return to MPI Forum Home Page
(Unofficial) MPI-2.2 of September 4, 2009
HTML Generated on September 10, 2009