> I think the current proposed hook, at least of MPI created file, is
> to specify the Access Mode of Canonical (aka External) representation.
Yes, I agree.
> 1) Where do you store that table when the MPI file is "exported" to
> the serial world? It must go to the beginning of the file. That
> violates the current MPI-view definition--the displacement is supposedly
> offset from the physical beginning of the file. ...
I always assumed that was for PROGRAM-generated bumf, like version numbers
and copyright statements. Yes, it could be used as a kludge for MPI-
generated stuff, but I don't see that MPI should be bound to make the
external ('unloaded') representation visible within the program.
> ... What you like to have
> is a self-described file but current MPIO definition tries to defer to
> it to some upper layer applications/libraries like netCDF, HDF, ...
No, the key difference is that the fields are NOT tagged. The Fortran,
MPI and above models all assume that the MPI program gets the types
'right' and perform no cross-checking. True self-describing formats
are entirely different, and have primitives to query what type the next
object is.
> 2) This approach also prevents forward compatibility. Say, I purchase
> a binary copy of a visualization tool that knows all the 32 and 64
> bits machine types. There comes this new machine that uses 12 bytes
> floating representation with some crazy new ideas (say compressed bits).
Didn't I mention that? Anyway, I agree, but would call it backwards
compatibility myself :-)
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679