This proposal seems to confuse "filetype" and "storage type". The
canonical view of an MPI file is a globally ordered sequence of
etypes. The filetype restricts an individual process' view in two
ways: not all etypes are visible (relative to the canonical view),
and the ordering of these etypes may be permuted (relative to the
global ordering). The filetype does not have any effect on how or
where these etypes are stored on disk. (Note that I have introduced
the new term "storage type"---this is not an MPI facility, nor
would I advocate it.)
It seems that the functionality described in this proposal could be
supported via file hints using a new reserved info key
"MPI_DATA_CHUNKING". The info string value would have to specify the
number of dimensions and storage order in each dimension (and perhaps
the chunk sizes).
- bill
PS: I may have misunderstood this proposal; if so, I think a fully
fleshed-out example (from MPI_Init() to MPI_Finalize()) would
go a long way to correcting my understanding. Besides, it
would be nice to include some examples in the text.
"Rajesh R. Bordawekar" writes
>
> > I should have been more clear. What I would like to see is an example
> > where I use MPI_chunk, pass that on to MPI_Type_subarray, and then what
> > does the corresponding MPI_Write do? The main purpose of the MPI_*_ORDER
> > parameter was to specify whether array dimensions are overlayed from
> > highest to lowest or lowest to highest. This is necessary due to the
> > differences in array layouts between FORTRAN and C. I am not sure how
> > chunking fits in to this.
> >
>
> Lets consider the example from the chapter (page 275). The array
> (100,100) is distributed in column-block fashion over 4 processors.
> Instead of using MPI_C_ORDER, if the user uses MPI-Chunk with the following
> parameters, (extent[0]=25, extent[1]=25, primary_storage order=
> MPI_C_ORDER and secondary_storage_order = MPI_C_ORDER), the
> MPI_Type_subarray call will be
>
> MPI_Type_subarray(2,sizes,subsizes,starts, MPI_chunk, MPI_DOUBLE, &filetype);
>
> Note that in this case, the file will be writted as a sequence of chunks
> of size (25*25). Each chunk will have MPI_C_ORDER internally and the
> chunks will be ordered in a row-major order. Now the resultant filetype
> will not have a consecutive block, but a series of blocks with holes in
> it.
>
> ok. For processor 1 (figure 11.6), the current filetype is
>
> |---------------------XXXXXXXX-----------------------------------|
> |---------------------XXXXXXXX-----------------------------------|
>
>
> For the chunked storage order, the filetype will be
>
> |----------XXX-----------XXX-----------XXX---------XXX-----------|
> |----------XXX-----------XXX-----------XXX---------XXX-----------|
>
> There will be four blocks (since the file will be stored as a chunk of
> 25*25). Once the filetype is generated, any MPI read/write routine can
> access the appro. data.