Re: new filter proposal

Rajeev Thakur (thakur@mcs.anl.gov)
Thu, 17 Apr 1997 10:35:05 -0500

This raises another question.
Sec. 10.5.1 on pg 240 says that to ensure file interoperability, the
etype must be a "portable" datatype constructed out of contig, vector,
indexed, indexed_block, subarray, and darray type constructors.
Shouldn't that restriction also apply to filetypes?
Or are filetypes allowed to be constructed with other constructors as
long as the user uses displacements obtained from
MPI_File_get_type_extent?

Rajeev

> Date: Wed, 16 Apr 1997 18:05:51 -0700
> From: johnmay@llnl.gov (John May)
>
> Bill Nitzberg writes:
> > I think I'm missing the problem.
> >
> > If an etype contains a hole the size of a float (e.g., Type_vector
> > example), then the implementation must keep track of the fact that
> > the hole is float-sized. When the implementation goes to skip over
> > that space in the file, it will use dtype_file_extent_fn to find the
> > size of a float, and skip that amount.
> >
> > In the Type_struct example, the user has created a "non-portable"
> > datatype, and gets what they deserve.
>
> I just wanted to verify that that's the behavior we're specifying
> (implicitly, anyway). Given the earlier discussion about tiling
> rules, the user will have to bound any external holes using a
> call to MPI_Type_resize. I suppose the rule will be:
>
> IF
> (1) the type is a basic type or was created by MPI_Type_vector,
> MPI_Type_indexed, or MPI_Type_contiguous
> AND
> (2) the upper and lower bounds are set at a offsets equal to an
> integral multiple of the size of the base type
>
> THEN
> Any internal or external holes in the type will be expanded or
> contracted in proportion to the change in size of the base type.
>
> I think this is intuitively the right thing. Do others agree?
>
> John