Pros:
----
1. implementation easier. does not have to calculate where within the
current filetype is the file pointer or offset pointing.
2. simpler interface for the user. clears up any confusion about why
etype AND filetype (particularly that filetype also defines a
tiling, i.e. one need not define a filetype covering the entire
file, if the view is a mere replication of a single filetype)
Cons:
----
1. In some (relatively rare) cases, it may require changing the view
many times, and it may not be easy to specify these views. For
example, an out-of-core problem that uses a datatype created with
MPI_Type_darray. If the local array doesn't fit in memory, creating
the view for the subarray may be quite complex. but not impossible.
2. Should a change be made at this late stage?
Considering the above, I'm in favor of getting rid of etypes.
But the foll. must be specified carefully:
1. for each data access call, type signature in memory must match type
signature in file.
2. what happens if the user requests an amount of data that is not an
integral multiple of filetype?
Note that by deleting etypes, we are effectively changing a two-level
mapping of the file to a one-level mapping. This is consistent with
what happens in memory, both for I/O and communication: There is only
one datatype that describes the layout in memory, and count copies of
this datatype are moved around. In the file, the "count" is derived
from the request in memory. By restricting accesses to multiples of
filetypes, we are saying that
count*MPI_Type_size(buftype) must be a multiple of
MPI_Type_size(filetype).