The reason the MPI standard doesn't do something like this internally is 
that what you are doing doesn't work across the full range of 
environments the MPI standard was intended to support.   What you are 
doing will (probably) work in homogeneous MPI environments (i.e., those 
where all the processors are the same kind of hardware), as is most 
common today, but will almost certainly fail in heterogeneous 
environments, as was common when the standard was first developed.  The 
MPI routines are defined to transfer values, not bit patterns.  If you 
are transferring integers between two heterogeneous processors, this 
might involve swapping bytes because of a difference in endianness or 
propagating the sign bit to account for a difference in word length.  If 
any kind of transformation is done between processors, it will be likely 
to mess up your TRANSFER.  Even if no transformation is done on 
integers, you could have trouble if the kinds of values that actually 
make up a "something" have differing representations on the various 
types of processors.

The MPI standard does have its own facilities for supporting structured 
types, but as I remember, they are a little bit clunky.  Because the MPI 
library has no access to what the compiler knows about the composition 
of a structured type, it depends on you to make a series of calls to 
provide it that information.  In your example, you would have to tell it 
that a "something" has three real components and the locations of those 
components relative to the beginning of the "something".  (There are 
ways to use an actual "something" on each machine to compute these 
relative locations in a way that is independent of the kind of processor 
you are using.)  Once you've told the library what a "something" looks 
like (on both the sending and receiving ends), you can tell MPI to 
transmit a "something" (or array of "somethings") and it will 
automatically decompose the "something" into values it knows how to 
transmit correctly.  (I'm being intentionally a little bit sketchy here 
because I last looked at these facilities nearly a decade ago, and my 
memory of the details is far from complete.)

[Sometimes working with the tools available means understanding how the 
tools were intended to be used instead of complaining about how poorly a 
screwdriver pounds in nails.  :-)  ]

-Kurt

P.S. Having said the above, I would be sympathetic to complaints that in 
today's environments, MPI should support a method for untransformed 
transfer of bits between homogeneous processors, and that there ought to 
be a tool that accepts the textual definition of a Fortran TYPE and 
generates the necessary MPI calls to inform the library of the structure 
of that TYPE.

On 12/16/2010 2:30 PM, Ted Stern wrote:
> Thanks, Steve, for both the workaround and the promise of an eventual
> improvement.
>
> All I'm trying to do is get some data from a namelist and propagate it
> throughout the MPI job.
>
> IMO the MPI standard should be able to do something like this
> internally with Fortran derived types so you don't have to go through
> these shenanigans just to pass data around.
>
> But MPI is somewhat primitive in that respect and has more of an f77/c
> flavor.  I don't like the size(transfer(...)) syntax either, but one
> has to work with the tools available.
>
> Ted
>