Re: new filter proposal
Bill Nitzberg (nitzberg@nas.nasa.gov)
Wed, 16 Apr 1997 13:45:41 -0700
In message <199704161906.OAA10309@abacus> Rajeev Thakur writes
>
> > Date: Wed, 16 Apr 1997 11:45:50 -0700
> > From: Bill Nitzberg <nitzberg@nas.nasa.gov>
> >
> > Since dtype_file_extent_fn will also be called when the user calls
> > MPI_FILE_GET_TYPE_EXTENT (for user defined data representations),
> > I think we should either make no restrictions at all, or have
> > something like:
>
> Since dtype_file_extent_fn is likely to be written by an expert,
> I'd prefer not having any restrictions, so that
> MPI_File_get_type_extent can work as it's supposed to.
>
> However, I think it is sufficient for dtype_file_extent_fn to work
> only for basic datatypes. Even etype is not needed, because if etype
> is derived, the MPI-IO implementation anyhow needs to work in terms of
> the basic datatypes within the etype. The extent of the etype can be
> calculated from that. Similarly, basic datatypes are sufficient for
> MPI_File_get_type_extent to figure out the rest.
>
> Therefore, I think we should require that dtype_file_extent_fn works
> for all basic datatypes only.
I like this solution much better. I was trying to figure out
how to avoid forcing everyone write the code to decompose datatypes
inside their dtype_file_extent_fn.
So, I suggest the following change to the one paragraph description
of the dtype_file_extent_fn callback:
Old text:
The function \mpifunc{dtype\_file\_extent\_fn}
returns in \mpiarg{file\_extent}
the number of bytes required to store
\mpiarg{datatype}
in the file representation.
Suggested text:
The \mpifunc{dtype\_file\_extent\_fn} routine
must return, in \mpiarg{file\_extent},
the number of bytes required to store
an \MPI/ basic datatype, \mpiarg{datatype},
in the file representation.
Only basic datatypes (e.g., \const{MPI\_INT}, \const{MPI\_REAL})
will be passed to \mpifunc{dtype\_file\_extent\_fn}.
- bill
(Of course, this means that we could change dtype_file_extent_fn to
an array_of_dsizes ...)