Re: new filter proposal

Jean-Pierre Prost (jpprost@watson.ibm.com)
Thu, 17 Apr 1997 11:07:34 -0400

I am kind of confused. If MPI_TYPE_RESIZE is used for setting
new lower and upper bounds, these bounds are not sticky. In other
words, when replicating the new datatype, the natural lower and
upper bounds (cf page 211 of the MPI-2 draft) are used. I do not
see how MPI_TYPE_RESIZE could be used to define what John
refers to as external holes. It seems to me that the tiling would not
preserve these holes since the bounds are not sticky. Am I wrong ?
Jean-Pierre

johnmay @ llnl.gov
04/16/97 09:05 PM

To: mpi-io @ mcs.anl.gov
cc: (bcc: Jean-Pierre Prost/Watson/IBM Research)
Subject: Re: new filter proposal

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