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.