The OVF 1.0 format
Keywords: userguide

Next: The OVF 2.0 format Up: Vector Field File Format Previous: The OVF 0.0 format
Subsections

- Segment Header block
- Data block

##
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.
- meshtype: Grid structure; should be either ``rectangular'' or ``irregular.'' Irregular grid files should specify ``pointcount'' in the header; rectangular grid files should specify instead ``xbase, ybase, zbase,'' ``xstepsize, ystepsize, zstepsize,'' and ``xnodes, ynodes, znodes.''
- pointcount: Number of data sample points/locations, i.e., nodes (integer). For irregular grids only.
- 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.

### Data block

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 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.

    # OOMMF: rectangular mesh v1.0
    #
    ## This is a comment.
    ## No comments allowed in the first line.
    #
    # Segment count: 1   ## Number of segments.  Should be 1 for now.
    #
    # Begin: Segment
    # Begin: Header
    #
    # Title: Long file name or title goes here
    #
    # Desc: 'Description' tag, which may be used or ignored by postprocessing
    # Desc: programs. You can put anything you want here, and can have as many
    # Desc: 'Desc' lines as you want.  The ## comment marker is disabled in
    # Desc: description lines.
    #
    ## Fundamental mesh measurement unit.  Treated as a label:
    # meshunit: nm
    #
    # meshtype: rectangular
    # xbase: 0.      ## (xbase,ybase,zbase) is the position, in
    # ybase: 0.      ## 'meshunit', of the first point in the data
    # zbase: 0.      ## section (below).
    #
    # xstepsize: 20. ## Distance between adjacent grid pts.: on the x-axis,
    # ystepsize: 10. ## 20 nm, etc.  The sign on this value determines the
    # zstepsize: 10. ## grid orientation relative to (xbase,ybase,zbase).
    #
    # xnodes: 200    ## Number of nodes along the x-axis, etc. (integers)
    # ynodes: 400
    # znodes:   1
    #
    # xmin:    0.    ## Corner points defining mesh bounding box in
    # ymin:    0.    ## 'meshunit'.  Floating point values.
    # zmin:  -10.
    # xmax: 4000.
    # ymax: 4000.
    # zmax:   10.
    #
    ## Fundamental field value unit, treated as a label:
    # valueunit: kA/m
    # valuemultiplier: 0.79577472  ## Multiply data block values by this
    #                              ## to get true value in 'valueunits'.
    #
    # ValueRangeMaxMag:  1005.3096  ## These are in data block value units,
    # ValueRangeMinMag:  1e-8       ## and are used as hints (or defaults)
    #     ## by postprocessing programs.  The mmDisp program ignores any
    #     ## points with magnitude smaller than ValueRangeMinMag, and uses
    #     ## ValueRangeMaxMag to scale inputs for display.
    #
    # End: Header
    #
    ## Anything between '# End: Header' and '# Begin: data text',
    ## '# Begin: data binary 4' or '# Begin: data binary 8' is ignored.
    ##
    ## Data input is in 'x-component y-component z-component' triples,
    ## ordered with x incremented first, then y, and finally z.
    #
    # Begin: data text
    1000 0 0 724.1 0. 700.023
    578.5 500.4 -652.36
    <...data omitted for brevity...>
    252.34 -696.42 -671.81
    # End: data text
    # End: segment

Figure 12: Commented OVF sample file. (Description.)

OOMMF Documentation Team
September 29, 2018