The OVF 2.0 format

The OVF 2.0 format is a modification to the OVF 1.0 format that also supports fields across three spatial dimensions but having values of arbitrary (but fixed) dimension. In the OVF 2.0 format:

1. The first line reads: # OOMMF OVF 2.0 for both regular and irregular meshes.
2. In the Segment Header block, the new record valuedim is required. This must specify an integer value, N , bigger or equal to one.
3. In the Segment Header block, the new valueunits record replaces the valueunit record of OVF 1.0. Instead of a single unit value, valueunits should be a (Tcl) list of value units, each treated as an unparsed label. The list should either have length N (as specified by valuedim), in which case each element denotes the units for the corresponding dimension index, or else the list should have length one, in which case the single element is applied to all dimension indexes. The old valueunit record is not allowed in OVF 2.0 files.
4. In the Segment Header block, the new valuelabels record is required. This should be an N -item (Tcl) list of value labels, one for each value dimension. The labels identify the quantity in each dimension. For example, in an energy density file, N would be 1, valueunits could be J/m³ , and valuelabels might be ``Exchange energy density''.
5. In the Segment Header block, the records valuemultiplier, boundary, ValueRangeMaxMag and ValueRangeMinMag of the OVF 1.0 format are not supported.
6. In the Data block, for regular meshes each record consists of N values, where N is the value dimension as specified by the valuedim record in the Segment Header. The node ordering is the same as for the OVF 1.0 format. For irregular meshes, each record consists of N + 3 values, where the first three values are the x , y and z components of the node position. For data blocks using text representation with N = 3 , the Data block in OVF 1.0 and OVF 2.0 files are exactly the same.
7. The data layout for data blocks using binary representation is also the same as in OVF 1.0 files, except that all binary values are written in a little endian (LSB) order, as compared to the MSB order used in the OVF 1.0 format. This includes the initial check value (IEEE floating point value 1234567.0 for 4-byte format, corresponding to the LSB hex byte sequence 38 B4 96 49, and 123456789012345.0 for 8-byte format, corresponding to the LSB hex byte sequence 40 DE 77 83 21 12 DC 42) as well as the subsequent data records.

In all other respects, the OVF 1.0 and OVF 2.0 are the same. An example OVF 2.0 file for an irregular mesh with N = 2 follows.

# OOMMF OVF 2.0
#
# Segment count: 1
#
# Begin: Segment
# Begin: Header
#
# Title: Long file name or title goes here
#
# Desc: Optional description line 1.
# Desc: Optional description line 2.
# Desc: ...
#
## Fundamental mesh measurement unit.  Treated as a label:
# meshunit: nm
#
# meshtype: irregular
# pointcount: 5      ## Number of nodes in mesh
#
# xmin:    0.    ## Corner points defining mesh bounding box in
# ymin:    0.    ## 'meshunit'.  Floating point values.
# zmin:    0.
# xmax:   10.
# ymax:    5.
# zmax:    1.
#
# valuedim: 2    ## Value dimension
#
## Fundamental field value units, treated as labels (i.e., unparsed).
## In general, there should be one label for each value dimension.
# valueunits:  J/m^3  A/m
# valuelabels: "Zeeman energy density"  "Anisotropy field"
#
# End: Header
#
## Each data records consists of N+3 values: the (x,y,z) node
## location, followed by the N value components.  In this example,
## N+3 = 5, the two value components are in units of J/m^3 and A/m,
## corresponding to Zeeman energy density and a magneto-crystalline
## anisotropy field, respectively.
#
# Begin: data text
0.5 0.5 0.5  500.  4e4
9.5 0.5 0.5  300.  5e3
0.5 4.5 0.5  400.  4e4
9.5 4.5 0.5  200.  5e3
5.0 2.5 0.5  350.  2.1e4
# End: data text
# End: segment

Figure 13: Commented OVF 2.0 sample file. (Description.)

OOMMF Documentation Team
September 29, 2017