4.3.1 Data Representation: ASCII or Binary

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 module (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'', ``ieee_4_limit'', and ``ieee_8'' can be chosen. The last three conversion types correspond to the CRAY internal types ``ieee_32'', ``ieee_dp'', and ``ieee_64'', respectively.

On a machine with an internal data representation not within the list in the existing uio_mac*_module.f90 files one could use the standard file uio_mac_module.f90 and is restricted to the ``native'' conversion type. But it is better to invent an appropriate name for the new data format and to build a proper machine dependent UIO file, e.g. from uio_mac_ieee_module.f90.

Table 4: UIO conversion types with length of integers, single precision reals, and double precision reals in bytes, and an explanation.

conversion type	I	R	D	description
native	?	?	?	internal data format on all machines
				(sometimes useful but not recommended)
ieee_4	4	4	8	standard IEEE big_endian format (recommended)
ieeele_4	4	4	8	IEEE little_endian format
ieee_8	8	8	16	double precision IEEE big_endian format
				(on some machines possible)
crayxmp_8	8	8	16	CRAY internal data format
idl	4	4	8	IDL format (but IDL also supports ieee_4)
xdr	4	4	8	format possible with IDL
ieee_4_limit	4	8	8	standard IEEE format $\rightarrow$ ieee_4
ieee	?	?	?	IEEE format, unknown length (not recommended)

Some attention has to be paid if weird compiler switches (as e.g. -r16 -i2) 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.