type constructors (was Re: new filter proposal)

Rajeev Thakur (thakur@mcs.anl.gov)
Thu, 17 Apr 1997 15:44:38 -0500

I think a better solution is to allow all datatype constructors for
etypes and filetypes. The only restrictions to users is if they are
using internal or external data representations, they can use
hvector, hindexed, and struct constructors only with displacements
obtained from MPI_File_get_type_extent. i.e., the resulting datatype
should describe the layout in the file, not in memory.

Since the buftype need not be constructed out of etype (only type
signatures must match), the holes in etype that may correspond to
file-format-extents should not matter for buftype.

Being able to use MPI_Type_struct is a requirement, in my opinion.

On a different note, I think users will be confused about the word
"displacement," because we are using it to refer to
datatype-displacements as well as the initial displacement in the file
view. I suggest that we rename "file displacement" to something else.
How about "initial-offset" if nothing better?

Rajeev

> Date: Thu, 17 Apr 1997 13:18:16 -0700
> From: johnmay@llnl.gov (John May)
>
> Rajeev Thakur writes:
>
> > If MPI_Type_struct cannot be used to create a filetype in
> > heterogeneous env., how does one specify holes in the file with lb and
> > ub? One may be able to specify lb with MPI_Type_resize (even that's
> > not clear), but what about ub?
>
> I think MPI_Type_resize will do both. You set the lower bound
> explicitly, and the upper bound is implicitly defined by the
> extent you ask for. The rule I suggested says that these
> bounds have to be set on base-type increments. Am I missing
> your point?
>
> > Secondly, if my data structure in memory is an array of structures (in
> > C), how do I write it to the file?
>
> Beats me. Maybe we need to resurrect one of the struct constructors
> that got moved to the JOD?
>
> John