While opening a file for writing, the file format (``formatted'' or ``unformatted'') and the conversion type (``native'', e.g. ``ieee_4'', ...) have to be specified.
The formatted ASCII data representation allows I/O independent of platform or compiler. It is useful for parameter files which can be read and edited by hand, for the direct inspection of data, the transfer between very different systems, or for the import of data which exist e.g. in a table format. From the specified conversion type only the default output format for numbers (e.g. ``E13.6'' for 4 byte reals) is determined.
The unformatted binary I/O is much faster and gives usually more compact
files with higher accuracy (ideally exact) in the numerical data representation.
But - in principle - the file format is machine dependent.
Fortunately, the IEEE format turns out to become a quasi-standard among a
variety of machines. Most workstations work internally with this format.
Some CRAYS which have a different internal data representation allow the hidden
transformation between the internal and IEEE format during the I/O process.
The UIO routines support this feature of CRAY FORTRAN compilers by means of a
uio_mac_module), individually designed for (two types of) CRAY
machines using certain CRAY specific system calls (CRAY FFIO assign logic).
Nevertheless, there is also a machine independent version of this module,
written completely in standard Fortran90 but providing less features
than the machine-dependent versions.
Besides the format, the conversion type (see table 4) has to be specified. The ``native'' conversion type is the internal binary-data representation, which is also standard for unformatted Fortran output. If this representation happens to be conformal with the IEEE standard the conversion type ``ieee_4'' should be used. It gives the same data format, but in the header of the file the term ``convert=ieee_4'' instead of ``convert=native'' describes the data format precisely - in a way also understandable by other machines. On CRAY machines the native format is equal to the conversion type ``crayxmp_8'', but also the conversion types ``ieee_4'', and ``ieee_8'' can be chosen. The last two conversion types correspond to the CRAY internal types ``ieee_32'' and ``ieee_64'', respectively.
On a machine with an internal data representation not within the list in
one could use the ``native'' conversion type only.
But it is better to invent an appropriate name for the new data format and
to build a proper machine-dependent branch with its own compiler switch.
However, it was possible in all cases so far to activate some
internal conversion process, which allowed the handling of UIO files in
the standard Big-Endian-IEEE format.
Some attention has to be paid if weird compiler switches (as e.g.
are used to modify the accuracy and standard memory size of variables.
If an existing file is opened for reading, the file format and conversion type are determined automatically from the file if the conversion type of the data in the file is among the conversion types supported by the compiler. If the file has a conversion type ``native'' but is created on a machine with different internal data representation, the file header might be readable, but an error will probably occur during the reading of a real variable.