The data block start is marked by a line of the form
# Begin: data <representation>
where <representation> is one of “text”, “binary 4”, or
“binary 8”. Text mode uses the ASCII specification, with
individual data items separated by an arbitrary amount of whitespace
(spaces, tabs and newlines). Comments are not allowed inside binary
mode data blocks, but are permitted inside text data blocks.
The binary representations are IEEE floating point in network byte
order (MSB). To insure that the byte order is correct, and to provide
a partial check that the file hasn’t been sent through a non 8-bit
clean channel, the first datum is a predefined value: 1234567.0 (Hex:
49 96 B4 38) for 4-byte mode, and 123456789012345.0 (Hex: 42 DC 12 21
83 77 DE 40) for 8-byte mode. The data immediately follow the check
value.
The structure of the data depends on whether the “meshtype” declared
in the header is “irregular” or “rectangular”. For irregular
meshes, each data element is a 6-tuple, consisting of the , and
components of the node position, followed by the , and
components of the field at that position. Ordering among the nodes is
not relevant. The number of nodes is specified in the “pointcount”
line in the segment header.
For rectangular meshes, data input is field values only, in , ,
component triples. These are ordered with the index
incremented first, then the index, and the index last. This
is nominally Fortran order, and is adopted here because commonly
will be the longest dimension, and the shortest, so this order is
more memory-access efficient than the normal C array indexing of ,
, . The size of each dimension is specified in the “xnodes,
ynodes, znodes” lines in the segment header.
In any case, the first character after the last data item should be a
newline, followed by
# End: data <representation>
where <representation> must match the value in the “Begin:
data” line. This is followed by a
# End: segment
line that ends the segment, and hence the file.
Note: An OVF 1.0 file with ASCII data and irregular meshtype is
also a valid OVF 0.0 (SVF) file, although as a
OVF 0.0 file the value scaling as specified by
“# valueunit” and “# valuemultiplier” header lines is
inactive.