I agree with what you have said, but I think you are considering
too hard of a problem.
Here's the functionality I'm asking for:
1. User has a data element in their program, say a struct
{ double** ; char* ; float; float; long[]; char* }
2. They describe it to MPI, 1st by describing the vector subtypes,
then the entire struct:
MPI_type_vector(C1,B1,S1, MPI_DOUBLE_PRECISION, &mydarray )
MPI_type_commit( &mydarray )
...
...
(build arrays for MPI_type_struct)
...
MPI_type_struct( ... , &mystruct )
MPI_type_commit( &mystruct )
3. Now, I would like to instantiate a structure on a "foreign"
process which is capable of receiving data stored in the above
datatype -- and manipulating it with at least MPI collective
I/O operations. By "foreign", I mean that it was not compiled
or executed with the above user code. So, if the above user
code performed:
MPI_GET_CHAR_DATA_TYPE( mystruct, mystructStr, L )
and sent this string via inter-communicator to the "foreign"
process, it could perform something like
~MPI_PUT_CHAR_DATA_TYPE( &userdef, userdefStr, L )
MPI_type_commit( &userdef )
along with
MPI_Type_size( userdef, &userdefSize )
userdata = malloc( userdefSize )
to create a memory location for receiving and manipulating
the user data.
Here, I assumed that an MPI_PUT_CHAR_DATA_TYPE() would
create new types as if they were laid out contiguously
in memory. Further I assume that a schedule is created
which dictates how packed "on-the-wire" data transmissions
are laid out on the foreign process side (including
floating-point and byte length conversions).
This is not a lot different than HDF, NetCDF, Tecate, etc. with the major
exception that the data are now distributed.
On Mon, 6 Nov 1995, James Cownie <jcownie@bbn.com> wrote:
> > Raw C structures are not portable even if you have a homogeneous
> > architecture.
> True
>
> > Many C compilers play games with the ordering of data elements within a
> > structure as a means of packing data (such as grouping all the char`s together
> > at the end of the structure). The ANSI C specification specifically says that
> > they make no assumptions about how the compiler implements a C structure,
> > except that it must not start or end with a "hole."
> False.
>
> This is simply an incorrect statement. I don't have a copy of the
> standard to hand, but I'm absolutely certain that
> 1) You can't start with a hole
> 2) The compiler is *not* allowed to re-order structure members
> 3) You *can* end with a hole. (Indeed this is very common).
>
> However the point being made is correct. It's impossible for MPI to
> know enough about the layout of a structure to be able to transfer it
> without you telling it in detail (i.e. down to the byte offsets of the
> structure components), because the properties of structure layout can
> depend on not only the target machine, but also
>
> 1) the compiler
> 2) compile time flags to the compiler
> 3) #pragma directives associated with the structure definition.
>
> Since the MPI library can see none of these properties, it cannot
> possibly determine the structure layout.
>
> Of course, as soon as you detail the layout of the structure, then you
> need different versions on heterogeneous machines (or even when you
> transfer data in a homeogenous environment between structures compiled
> with different options...)
>
> -- Jim
>
> James Cownie
> BBN UK Ltd
> Phone : +44 117 9071438
> E-Mail: jcownie@bbn.com
>
>
>
Richard Frost
SDSC