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:
- The first line reads:
# OOMMF OVF 2.0
for both
regular and irregular meshes.
- In the Segment Header block, the new record valuedim is
required. This must specify an integer value, , bigger or equal to
one.
- 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
(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.
- In the Segment Header block, the new valuelabels record is
required. This should be an -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, would be 1,
valueunits could be J/m, and valuelabels might be
“Exchange energy density”.
- In the Segment Header block, the valuemultiplier,
boundary, ValueRangeMaxMag and ValueRangeMinMag
records of the OVF 1.0 format are not supported.
- In the Data block, for regular meshes each record consists of
values, where 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 values, where the first three values are the
, and components of the node position. For data blocks
using text representation with , the Data block in
OVF 1.0 and OVF 2.0 files are exactly the same.
- 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 follows.
# OOMMF OVF 2.0
#
# Segment count: 1
#
# Begin: Segment
# Begin: Header
#
# Title: Long filename 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
OOMMF Documentation Team
September 27, 2024