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

Subsections


Vector field formats (OVF and SVF)

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 the micromagnetic solver program when ``Total Field'' or ``Magnetization'' output is selected. It is also the input data type read by the vector field display program, mmDisp. OOMMF currently supports two vector field formats: the OOMMF Vector Field (OVF) format and the Simple Vector Field (SVF) format. The OVF format is the preferred format used by all OOMMF code. It supports both rectangular and irregular meshes, in binary and ASCII. The SVF format is provided to supply a simple interface to outside programs. (A third format, the Vector Input/Output (VIO) format, is used by some precursors to the OOMMF code. Its use is deprecated, and should not be used for new code.)

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. SVF files should be given a .svf extension.


The OVF format

A commented sample OVF file is provided below. These files have 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 a OVF file should be a file type identification line, having the form

# OOMMF: rectangular mesh v1.00
where the value ``rectangular mesh v1.00'' identifies subformat type and revision. Only the field tag ``OOMMF'' is used at present.

After this 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 images 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.



# OOMMF: rectangular mesh v1.00
#
## 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. 
#
# meshunit: nm   ## Fundamental mesh measurement unit.  Treated as a label
#
# 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.
#
# valueunit: kA/m  ## Fundamental field value unit, treated as a label
# 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 5: Commented OVF sample file. (Description.)



The SVF format

The Simple Vector Field (SVF) format is a simple ASCII 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 problem140 http://www.ctcms.nist.gov/~rdm/stdprob_1.html.

A sample SVF 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 SVF file be

# SVF-02
This will aid automatic file type detection. Also, three special (extended) comments are recognized by the mmDisp display program:
## 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.



# SVF-02
## File: sample.svf
## 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 6: Example SVF file. (Description.)



OOMMF Home next up previous Contents

OOMMF Documentation Team
October 2, 1998