The OVF 1.0 format

A commented sample OVF 1.0 file is provided
below.
An OVF file has an ASCII header and trailer, and a data block that
may be either ASCII or binary. All non-data lines begin with a `#'
character; double `##' mark the start of a comment, which
continues until the end of the line. There is no line continuation
character. Lines starting with a `#' but containing only whitespace
characters are ignored.

All non-empty non-comment lines in the file header are structured as
label+value pairs. The label tag consists of all characters after the
initial `#' up to the first colon (`:') character. Case is ignored,
and all space and tab characters are eliminated. The value consists
of all characters after the first colon, continuing up to a `##'
comment designator or the end of the line.

The first line of an OVF file should be a file type identification
line, having the form

# OOMMF: rectangular mesh v1.0

or

# OOMMF: irregular mesh v1.0

where the value ``rectangular mesh v1.0'' or ``irregular mesh v1.0''
identifies the mesh type and revision. While the OVF 1.0 format was
under development in earlier OOMMF releases, the revision strings
0.99 and 0.0a0 were sometimes recorded on the file type
identification line. OOMMF treats all of these as synonyms for
1.0 when reading OVF files.

The remainder of the file is conceptually broken into Segment
blocks, and each Segment block is composed of a
(Segment) Header block and a Data block. Each block begins with a
``# Begin: <block type>'' line, and ends with a corresponding
``# End: <block type>'' line. The number of Segment blocks is
specified in the

# Segment count: 1

line. Currently only 1 segment is allowed. This may be changed in
the future to allow for multiple vector fields per file.
This is followed by

# Begin: Segment

to start the first segment.

Segment Header block

The Segment Header block start is marked by the line
``# Begin: Header'' and the end by ``# End: Header''. Everything
between these lines should be either comments or one of the following
file descriptor lines. They are order independent. All are required
unless otherwise stated. Numeric values are floating point values
unless ``integer'' is explicitly stated.

title: Long file name or title.

desc: Description line. Optional. Use as many as desired.
Description lines may be displayed by post-processing programs,
unlike comment lines which are ignored by all automated processing.

meshunit: Fundamental mesh spatial unit, treated as a
label. The comment marker `##' is not allowed in this label.
Example value: ``nm''.

valueunit: Fundamental field value unit, treated as a
label. The comment marker `##' is not allowed in this label.
Example: ``kA/m.''

valuemultiplier: Values in the data block are multiplied by
this to get true values in units of ``valueunit.'' This simplifies
the use of normalized values.

xmin, ymin, zmin, xmax, ymax, zmax: Six separate lines,
specifying the bounding box for the mesh, in units of ``meshunit.''
This may be used by display programs to limit the display area,
and may be used for drawing a boundary frame if ``boundary'' is not
specified.

boundary: List of (x,y,z) triples specifying the
vertices of a boundary frame. Optional.

ValueRangeMaxMag, ValueRangeMinMag: The maximum and
minimum field magnitudes in the data block, in the same
units and scale as used in the data block. These are for optional
use as hints by postprocessing programs; for example, mmDisp
will not display any vector with magnitude smaller than
ValueRangeMinMag. If both ValueRangeMinMag and ValueRangeMaxMag
are zero, then the values should be ignored.

xbase, ybase, zbase: Three separate lines, denoting the
position of the first point in the data section, in units of
``meshunit.'' For rectangular grids only.

xstepsize, ystepsize, zstepsize: Three separate lines,
specifying the distance between adjacent grid points, in units
of ``meshunit.'' Required for rectangular grids, but may be
specified as a display hint for irregular grids.

xnodes, ynodes, znodes: Three separate lines, specifying
the number of nodes along each axis (integers). For
rectangular grids only.

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 x
, y
and
z
components of the node position, followed by the x
, y
and z
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 x
, y
,
z
component triples. These are ordered with the x
index
incremented first, then the y
index, and the z
index last. This
is nominally Fortran order, and is adopted here because commonly x
will be the longest dimension, and z
the shortest, so this order is
more memory-access efficient than the normal C array indexing of z
,
y
, x
. 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.