OOMMF Home next up previous contents index
Next: Troubleshooting Up: File Formats Previous: Data table format (ODT)

Subsections


Vector field format (OVF)

Vector field files specify vector quantities (e.g., magnetization or magnetic flux density) as a function of spatial position. This type of file is produced by mmSolve2D when ``Total Field'' or ``Magnetization'' output is selected. It is also the input data type read by mmDisp. OOMMF stores vector field files in the OOMMF Vector Field (OVF) format. There are two versions of the OVF format supported by OOMMF. The OVF 1.0 format is the preferred format and the only one written by OOMMF software. It supports both rectangular and irregular meshes, in binary and ASCII text. The OVF 0.0 format (formerly SVF) is an older, simpler format that can be useful for importing vector field data into OOMMF from other programs. (A third format, the VecFil or Vector Input/Output (VIO) format, was used by some precursors to the OOMMF code. Although OOMMF is able to read the VIO format, its use is deprecated. New programs should not make use of it.)

The recommended file extensions for OVF files are .omf for magnetization files, .ohf for magnetic field (H) files, .obf for magnetic flux density (B) files, or .ovf for generic files.


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; the double `##' marks 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 field+value pairs. The field 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
where the value ``rectangular mesh v1.0'' identifies the meshtype 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. Every block begins with ``# 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.

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 file with ASCII data using irregular mesh output is also a valid SVF file, although one must pay close attention to possible value scaling as specified by ``# valueunit'' and ``# valuemultiplier'' header lines.



# 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 file values by this to get
#                              ## true value in 'valueunits'.
#
# ValueRangeMaxMag:  1005.3096  ## These are in file value units, and
# ValueRangeMinMag:  1e-8       ## 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 6: Commented OVF sample file. (Description.)



The OVF 0.0 format

The OVF 0.0 format is a simple ASCII text format supporting irregularly sampled data. It is intended as an aid for importing data from non-OOMMF programs, and is backwards compatible with the format used for problem submissions for the first muMAG standard problem.

Users of previous releases of OOMMF may recognize the OVF 0.0 format by its previous name, the Simple Vector Field (SVF) format. It came to the attention of the OOMMF developers that the file extension .svf was already registered in several MIME systems to indicate the Simple Vector Format, a vector graphics format. To avoid conflict, we have stopped using the name Simple Vector Field format, although OOMMF software still recognizes and reads SVF files, and you may still find example files and other references to the SVF format.

A sample OVF 0.0 file is shown below. Any line beginning with a `#' character is a comment, all others are data lines. Each data line is a whitespace separated list of 6 elements: the x, y and z components of a node position, followed by the x, y and z components of the field at that position. Input continues until the end of the file is reached.

It is recommended (but not required) that the first line of an OVF file be

# OOMMF: irregular mesh v0.0
This will aid automatic file type detection. Also, three special (extended) comments in OVF 0.0 files are recognized by mmDisp:
## File: <filename or extended filename>
## Boundary-XY: <boundary vertex pairs>
## Grid step: <cell dimension triple>
All these lines are optional. The ``File'' provides a preferred (possibly extended) filename to use for display identification. The ``Boundary-XY'' line specifies the ordered vertices of a bounding polygon in the xy-plane. If given, mmDisp will draw a frame using those points to ostensibly indicate the edges of the simulation body. Lastly, the ``Grid step'' line provides three values representing the average x, y and z dimensions of the volume corresponding to an individual node (field sample). It is used by mmDisp to help scale the display.

Note that the data section of an OVF 0.0 file takes the simple form of columns of ASCII formatted numbers. Columns of whitespace separated numbers expressed in ASCII are easy to import into other programs that process numerical datasets, and are easy to generate, so the OVF 0.0 file format is useful for exchanging vector field data between OOMMF and non-OOMMF programs. Furthermore, the data section of an OVF 0.0 file is consistent with the data section of an OVF 1.0 file that has been saved as an irregular mesh using text data representation. This means that even though OOMMF software now writes only the OVF 1.0 format for vector field data, simple interchange of vector field data with other programs is still supported.



# OOMMF irregular mesh v0.0
## File: sample.ovf
## Boundary-XY: 0.0 0.0 1.0 0.0 1.0 2.0 0.0 2.0 0.0 0.0
## Grid step: .25 .5 0
#  x      y      z        m_x      m_y      m_z
  0.01   0.01   0.01   -0.35537  0.93472 -0.00000
  0.01   1.00   0.01   -0.18936  0.98191 -0.00000
  0.01   1.99   0.01   -0.08112  0.99670 -0.00000
  0.50   0.50   0.01   -0.03302  0.99945 -0.00001
  0.99   0.05   0.01   -0.08141  0.99668 -0.00001
  0.75   1.50   0.01   -0.18981  0.98182 -0.00000
  0.99   1.99   0.01   -0.35652  0.93429 -0.00000
Figure 7: Example OVF 0.0 file. (Description.)



OOMMF Home next up previous Contents index

OOMMF Documentation Team
January 15, 2004