OOMMF Vector Field File Format


The OOMMF vector field (ovf) format is the native file format for mmDisp. The suggested filename extensions for such files are .omf for magnetization files, .obf for B field files, and .ohf for H field files. However, the mmDisp program determines file type by reading the file header, so you can in fact use any extension you like.

At present we are only defining a format for text (ASCII) data sampled on a rectangular grid. In the near future we will define extensions supporting binary data, and allowing for data sampled at arbitrary points.

Below is a portion of a (heavily commented) OOMMF vector field file:


# OOMMF: rectangular mesh v0.0a0
#
## This is a comment.
## Comments are initiated with 2 '#' characters.
## No comments are allowed in the first line.
##
## The first line identifies data sampled on a rectangular grid.
## Later versions of mmDisp will also support a related file format
## for irregularly sampled data.
##
## All non-data lines should have a '#' character in the first column.
## All non-comment non-data lines follow a "NAME" : "VALUE" format.
## Notes: Name tags end at the first colon, are not case sensitive,
## and all non-alphanumeric characters are ignored.  Also, there is at
## present no line continuation character.  
#
# Segment count: 1  ## Number of segments (display frames).  Should be
#                   ## 1 for mmDisp v0.0a0
#
# Begin: Segment
#
## Each 'Segment' consists of a 'Header' block and a 'Data' block,
## in that order.
#
# Begin: Header
#
# Title: Long file name or title goes here
#
# Desc: 'Description' tag, which *may* be used by postprocessing programs.
# Desc: 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. 
#
## Note: It is currently not possible to put '##' as part of a
##       'meshunit' or 'valueunit' string (it would get interpreted
##       as starting a comment).
#
# meshunit: nm   ## Fundamental mesh measurement unit.  Treated as a label
#
# 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    ## For mmDisp v0.0a0 znodes should probably be 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.079577472  ## 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.  The use of these
#     ## values is postprocessor dependent, and may be interactively
#     ## overrideable, but typically ValueRangeMaxMag should be the maximum
#     ## vector magnitude in the file data, and ValueRangeMinMag should be
#     ## a lower bound on non-zero file vector magnitudes.
#
# 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.  This is
## nominally fortran order, and is adapted here because commonly x
## will be the longest dimension, and z the shortest, so this order
## is more memory-access efficient than z, y, x.
## 
## Any amount and type of whitespace (spaces, tabs and newlines) is
## allowed between each item.
##
## We support ascii (text) and *will* support network-byte-order (MSB)
## IEEE floating point binary data blocks.  Text data blocks should
## not contain any '#' characters.  Binary 4 (8) data blocks will begin
## with a predefined, fixed 4 (8) byte value---to insure that the byte
## order is correct, and also as a partial check that the file hasn't
## been passed along a non 8-bit clean channel.  Binary data blocks
## are not supported by mmDisp v0.0a0, but will be defined and supported
## in the next patch release.
#
# Begin: data text
1000 0 0 724.1 0. 700.023
578.5 500.4 -652.36
...
# End: data text
# End: segment


Go to the top.