学习自旋电子学的笔记01：微磁模拟软件OOMMF的教程（中文版）17.4-22章
操千曲而后晓声，观千剑而后识器。——刘勰《文心雕龙》
目录
17.4 MIF 2.2。
17.4.1 MIF 2.2和MIF 2.1格式之间的差异。
17.4.2 MIF 2.2新的扩展命令。
17.4.3 MIF 2.2文件示例。
17.5 编写MIF2.x文件的技巧。
18 数据表文件格式（ODT）
19 矢量场文件格式（OVF）
19.1 OVF 0.0格式。
19.2 OVF 1.0格式。
19.2.1段落标题块。
19.2.2数据块。
19.3 OVF 2.0格式。
20 故障排除
21 参考文献
22 开发人员
# 前言
这是oommf软件教程《OOMMF User’s Guide》的中文翻译文章，由于本人水平有限，有些翻译可能有错误，望见谅。
将Word复制到CSDN时发现一个问题：CSDN几乎都不能正确显示字母的角标（右上方和右下方的角标），不过聪明的读者肯定很容易发现这些地方。
17.4 MIF 2.2。
OOMMF 1.2a4引入MIF 2.2格式，它在MIF 2.1格式的基础上进行了小修改，MIF 2.2扩展了一些额外的命令，并且基本上与MIF 2.1兼容，除了以下说明的除外。
17.4.1 MIF 2.2和MIF 2.1格式之间的差异。
1.MIF 2.2文件的第一行必须是“#MIF 2.2”。
2. MIF 2.2不再支持Oxs_TimeDriver和Oxs_MinDriver对象的basename、scalar_output_format和vector_field_output_format选项，取而代之的是一个新的顶级扩展命令SetOptions，其中包含这些选项。SetOptions块还添加了控制输出矢量场的网格类型（矩形rectangular或不规则irregular）和标量场输出格式的新增选项。
3.在MIF 2.1格式中，MIF文件是进行了两次解析的。在第一次解析过程中，Specify命令只保存Specify指定块的内容，而不创建任何Oxs_Ext对象。每个Specify指定块定义的Oxs_Ext对象是在第二次解析时根据第一次解析过程中存储的数据创建的。在MIF 2.2格式中，MIF文件只解析一次，在解析Specify命令时，就创建了Oxs_Ext对象。这种处理方式对MIF文件的作者来说更直观，但同时会产生两个主要影响。首先，在MIF 2.1文件中，若是Tcl函数仅在Specify命令中使用，那么可将Tcl函数放在文件中的任何位置（例如，通常放在文件末尾），这是由于在第一次解析时不会调用它们，因此它们可以在第一个解析过程中的任何时候定义，而在第二个解析过程中被调用。相比之下，在MIF 2.2格中，Tcl函数必须在被引用的位置之前定义。其次，产生的第二个影响是，在MIF文件中可以使用由Specify命令定义的Oxs_Ext对象，用法体现在下面讨论的新命令中。
17.4.2 MIF 2.2新的扩展命令。
除了MIF 2.1中的可用命令外，MIF 2.2还引入了以下新增命令：GetMifFilename、GetMifParameters、GetOptions、SetOptions、EvalScalarField、EvalVectorField、GetAtlasRegions和GetAtlasRegionByPosition。
GetMifFilename
GetMifFilename命令会返回正在读取的MIF文件的完整（绝对）名称。此命令不接受任何参数。
GetMifParameters
此命令不接受任何参数，并返回在命令行或“Load Problem”对话框中为“Parameter”设置的“标签+值”对的列表（即列表长度为偶数）。如果未指定任何参数，则返回的将是空列表。
GetOptions
GetOptions命令不接受任何参数。它以“标签+值”对的列表（即列表长度为偶数）的形式返回该命令前面的SetOptions块里面的所有内容。
SetOptions
在MIF 2.1文件中，输出基本的名称和输出文件的格式是在驱动器的Specify指定块中设置的。在MIF 2.2中，这些选项被移到了单独的SetOptions块内。SetOptions块可以放在MIF文件中的任何位置，但通常放在文件开头附近，以便作用于所有输出的初始化。SetOptions命令接受一个参数，即由“标签+值”对组成的列表。默认标签有：
• basename
• scalar_output_format
• scalar_field_output_format
• scalar_field_output_meshtype
• vector_field_output_format
• vector_field_output_meshtype
标签basename的值是数据输出例程构建的输出文件名称的前缀，若没有设置该选项，则默认的名称（不含后缀名）就是输入文件的文件名称。标签scalar_output_format的值是一个C语言printf的格式化字符串，表示数据表输出的输出格式。该选项是可选的，默认值为“%.17g”。标签scalar_field_output_format和vector_field_output_format的值都是只有两个元素的列表，列表中的两个元素分别表示发送到mmDisp和mmArchive的标量和矢量场输出的样式和精度。列表中的第一个元素应该是binary或text，用于指定输出样式。如果选择了二进制输出，那么用于指定精度的第二个元素应该是4或8，以字节表示分量的二进制输出长度。对于文本输出，第二个元素应该是C语言printf的格式化字符串，类似于scalar_output_format。标签scalar_field_output_format和vector_field_output_format的默认值均为“binary 8”。scalar_field_output_meshtype和vector_field_output_meshtype的值为“rectangular”（默认）或“irregular”，表示对应的场输出文件的网格类型。
在MIF 2.2中，允许用户使用多个SetOptions块。在一个SetOptions块中指定的标签值可能会被后面的SetOptions块覆盖。给定输出的输出格式是在处理Oxs_Ext对象的Specify指定块时设置的，因此，通过策略性地放置SetOptions块，可以为不同Oxs_Ex对象中的输出指定不同的格式。
将来可能会在SetOptions块内添加新的标签，并且可能会依赖于Oxs_Ext类。目前没有检查SetOptions块内的未知标签的功能，但将来可能会有。
SetOptions块的示例：
SetOptions {
basename fubar
scalar_output_format %.12g
scalar_field_output_format {text %.4g}
scalar_field_output_meshtype irregular
vector_field_output_format {binary 4}
}
EvalScalarField
此命令允许在MIF文件中访问前面通过Specify指定块定义的标量场中的值。例如:
Specify Oxs_AtlasScalarField:Ms {（译者注：原文没有“Specify”，应该是手册作者的失误）
atlas :atlas
default_value 0
values {
Adisks 520e3
Bdisks 520e3
}
}}
set Ms_a [EvalScalarField :Ms 50e-9 20e-9 2e-9]
EvalScalarField的四个参数是对标量场的引用（这里是Ms），以及要计算场值的位置点的三个坐标分量。坐标分量是参考微磁问题坐标系的，即以米为单位。
EvalVectorField
此命令与EvalScalarField相同，不过它的参数是矢量场，它的返回值是一个有三个元素的列表，表示矢量场在指定位置点的矢量值。
GetAtlasRegions
此命令接受一个参数，该参数引用一个atlas容器，并返回该容器中的所有区域的有序列表。返回列表中的第一项始终是“universe”，universe中包含不在任何其它区域内的所有位置点，尤其是容器标称边界之外的任何位置点。示例用法：
set regions_list [GetAtlasRegions :atlas]
GetAtlasRegionByPosition
此命令接受四个参数：对atlas的引用，和使用微磁问题坐标系（即以米为单位）的位置点的x、y和z坐标。返回值是包含指定位置点的区域的名称。此名称和GetAtlasRegions命令返回列表中的一个容器名称是匹配的。注意，GetAtlasRegionByPosition返回值可能是“universe”区域。示例用法：
set rogue_region [GetAtlasRegionByPosition :atlas 350e-9 120e-9 7.5e-9]
17.4.3 MIF 2.2文件示例。
# MIF 2.2
###############
# Constants
set pi [expr 4*atan(1.0)]
set mu0 [expr 4*$pi*1e-7]
###############
# Command-line controls
Parameter seed 1
Parameter thickness 6e-9
Parameter stop 1e-2
# Texturing angle, phideg, in degrees, from 0 to 90; 0 is all z.
Parameter phideg 10;
###############
# Output options
SetOptions [subst {
basename "polyuniaxial_phi_$phideg"
scalar_output_format %.12g
scalar_field_output_format {text %.4g}
scalar_field_output_meshtype irregular
vector_field_output_format {binary 4}
}]
###############
# Rogue grain:
# If RoguePt is an empty string, then no rogue grain is selected. OTOH,
# If RoguePt is set to a three item list consisting of x, y, and z coords
# in the problem coordinate system (i.e., in meters), then the grain
# containing that point is individually set as specified below.
Parameter RoguePt {263.5e-9 174.5e-9 3e-9}
###############
# Support procs:
proc Ellipse { Ms x y z} {
set x [expr {2*$x-1.}]
set y [expr {2*$y-1.}]
if {$x*$x+$y*$y<=1.0} {
return $Ms
}
return 0.0
}
###############
# Material constants
set Ms 1.40e6
set Ku 530e3
set A 8.1e-12
###############
# Atlas and mesh
set xsize 400e-9
set ysize 400e-9
set xycellsize 1.0e-9
set zcellsize 3.0e-9
set grain_count 260
set grain_map polycrystal-map-mif.ppm
set colormap {}
for {set i 0} {$i<$grain_count} {incr i} {
lappend colormap [format "#%06x" $i]
lappend colormap $i
}
Specify Oxs_ImageAtlas:world [subst {
xrange {0 $xsize}
yrange {0 $ysize}
zrange {0 $thickness}
viewplane xy
image $grain_map
colormap {
$colormap
}
matcherror 0.0
}]
Specify Oxs_RectangularMesh:mesh [subst {
cellsize {$xycellsize $xycellsize $zcellsize}
atlas :world
}]
#################################
# Uniaxial Anisotropy
# Generate TEXTURED random unit vector
set phirange [expr {1-cos($phideg*$pi/180.)}]
proc Texture {} {
global pi phirange
set theta [expr {(2.*rand()-1.)*$pi}]
set costheta [expr {cos($theta)}]
set sintheta [expr {sin($theta)}]
set cosphi [expr {1.-$phirange*rand()}]
set sinphi [expr {1.0-$cosphi*$cosphi}]
if {$sinphi>0.0} { set sinphi [expr {sqrt($sinphi)}] }
set x [expr {$sinphi*$costheta}]
set y [expr {$sinphi*$sintheta}]
set z [expr {$cosphi}]
return [list $x $y $z]
}
# Set a random unit vector for each grain region
set axes {}
for {set i 0} {$i<$grain_count} {incr i} {
lappend axes $i
lappend axes [Texture]
}
# Sets the rogue grain ($Rogue < $grain_count)
if {[llength $RoguePt] == 3} {
# The :Regions field maps region name (which is a number)
# to the corresponding number.
set regionmap {}
for {set i 0} {$i<$grain_count} {incr i} {lappend regionmap $i $i }
Specify Oxs_AtlasScalarField:Regions [subst {
atlas :world
values [list $regionmap]
}]
foreach {x y z} $RoguePt { break }
set Rogue [EvalScalarField :Regions $x $y $z]
set item_number [expr 2*$Rogue+1]
set axes [lreplace $axes $item_number $item_number {1 0 0}]
}
Specify Oxs_AtlasVectorField:axes [subst {
atlas :world
norm 1.0
values [list $axes]
}]
Specify Oxs_UniaxialAnisotropy [subst {
K1 $Ku
axis :axes
}]
#################################
# Exchange
set A_list {}
for {set i 0} {$i<$grain_count} {incr i} {
lappend A_list $i $i $A
}
Specify Oxs_Exchange6Ngbr [subst {
default_A $A
atlas world
A [list $A_list]
}]
#################################
# Zeeman (applied) field
set field 10000 ;# Maximum field (in Oe)
Specify Oxs_UZeeman [subst {
multiplier [expr (1./($mu0*1e4))*$field]
Hrange {
{ 0 0 0 0 0 1 10}
}
}]
#################################
# Driver and Evolver
Specify Oxs_CGEvolve:evolve {}
Specify Oxs_MinDriver [subst {
evolver evolve
stopping_mxHxm $stop
mesh :mesh
Ms { Oxs_ScriptScalarField {
atlas :world
script_args {relpt}
script {Ellipse $Ms}
} }
m0 { 0 0 -1 }
}]
Figure 9: Example MIF 2.2file.
17.5 编写MIF2.x文件的技巧。
MIF 2.x文件也是Tcl脚本的一种，因此编写MIF文件也是一种Tcl脚本编程，编写过程中需要一些技巧，那么在本节中，将详细介绍一些编写MIF文件的技巧。
一般来说，在编写的准备阶段需要获取一个与用户想要编写的文件有一些相似之处的现有MIF文件，例如是用户之前编写的文件或是来自目录oommf/app/oxs/examples/中的示例文件，复制一份现有的MIF文件并开始编辑。如果用户需要用到复杂的功能，那么必须要基本了解Tcl脚本的语法。特别是，用户应该熟悉Tcl列表、数组和一些基本的Tcl命令，如set、expr、for、foreach、if/else、lrange和subst。用户可以在 https://wiki.tcl-lang.org/page/Online+Tcl+and+Tk+TutorialsTcl 网站上找到一系列的Tcl教程，用户在该网站上可以点击Chris verBurg的“Tcl Tutorial”教程和“Learn Tcl in Y Minutes”进行学习。Tcl Dodekalogue（https://wiki.tcl-lang.org/page/Dodekalogue）也是一个很好的Tcl参考资料，里面有许多关于Tcl错误消息的处理方式。有关Tcl的更多资源，包括在线手册，可以在Tcl Developer Xchange（https://www.tcl-lang.org/）上找到。
虽然MIF文件是Tcl脚本，但MIF额外支持许多扩展命令。其中最常用的是Specify命令，它用于定义和初始化Oxs_Ext对象，例如区域的定义（容器）、网格的离散化、能量项（交换、各向异性、偶极-偶极（相互作用）、外加磁场）和求解方法（能量最小化或LLG积分）。如何编写每个Oxs_Ext对象的Specify指定块，请参见第7.3节标准Oxs_Ext子类的文档。
其它常用的MIF扩展命令有Parameter、Destination和Schedule。Parameter与Tcl的set命令类似，但Parameter允许用户在运行时通过Oxsii“Load Problem”对话框中的Params输入框或通过Boxsi的命令行选项-parameters来更改变量值。Destination和Schedule命令主要用于非手动式的设置Boxsi的模拟输出。
与其它语言的编程一样，编写MIF文件时也可能出现bugs。以下是一些有助于调试MIF代码的技巧：
0.看一下自己常用的编程编辑器（FPE）是否支持Tcl语法的高亮显示和缩进，这些功能有助于用户在编写MIF文件过程中发现很多错误，尤其是大括号的嵌套问题。
1.在开发阶段，用户可以调整微磁问题的空间维度和单元格的大小，使单元格总数相对较小，这会使微磁问题加载和运行的速度更快，更容易检测和纠正错误。使用菜单Oxsii|Help|About可以查看模拟中的单元格数量。对于较大型的模拟，用户可能需要暂时禁用Oxs_Demag模块，因为该模块的初始化需要大量的时间，并且通常是运行最慢的模块。如果单元格的磁化设置是正确的，那么通常Oxs_Demag也是正确的。然而，在处理周期性边界条件（periodic boundary conditions，PBC）时，用户需要格外小心，因为PBC的退磁效应可能是非直观的。
2.MIF文件编写好后，启动Oxsii并打开File|Load的对话框。选中“Browse”复选框，若没有选中的话，当点击“OK”加载文件时，加载对话框将会自动关闭。“Browse”选项允许用户更正MIF文件中的语法错误，而无需重复打开File|Load的对话框来重新选择MIF文件和参数。
3.如果MIF文件加载失败，请在FPE（常用的编程编辑器）中打开MIF文件，并利用错误消息定位文件中的bugs。改正MIF文件之后，需要将它保存到磁盘，然后再次尝试加载它。
4.如果没有显示错误消息，或者用户只是想检查是否按预期解析文件，则可以使用MIF的Report命令将变量的内容或其它状态信息打印到Oxsii控制台。（Oxsii控制台是通过Oxsii窗口中的菜单File|Show Console启动的。如果用户正在运行Boxsi，Report命令的输出会放在Boxsi的日志文件oommf/Boxsi.errors中。）
5.一旦MIF文件加载无误，可以将Oxsii的Magnetization输出发送给mmDisp，以便查看模拟结构。在mmDisp中的不同位置点上使用Ctrl-或Shift-Ctrl-<单击鼠标左键>，可以查看该位置点的磁化强度的分量值。打开菜单Options|Configure的对话框来调整颜色、像素和箭头等，尤其是调节# of Colors和Data Scale选项可以更容易地看到所选颜色量中的微小差异。Arrow span选项可用于控制在切片视图中显示的箭头数量。例如，如果在观察的平面图方向上的单元格尺寸为4nm，将Arrow span设置为4e-9，在mmDisp窗口中滑动切片控制滑块时，则会显示磁化强度的单个切片视图。如果将Arrow span设置为8e-9，则会看到两层重叠的箭头，这有助于检查界面条件。
6.默认情况下，mmDisp的视图是沿z轴自上而下的。对于多层结构，沿不同方向轴查看横截面图是非常有必要的，可以从mmDisp窗口的菜单View|Viewpoint中选择查看的方向轴。此外，mmDisp渲染高纵横比单元格的效果可能非常差，在这种情况下，用户可以在配置对话框中启用像素显示，并将像素大小设置为小于1，然后调整背景色以使单个单元格清晰可见。
7.在mmDisp中查看Magnetization输出可以检查在驱动器的Specify指定块中是否正确设置了Ms和m0。用户可以将其它的场（如各向异性和交换）发送到mmDisp，来检查这些能量项的参数设置。在这种情况下，调整m0使其位于测试的特定方向上可能会有所帮助。用户可能需要打开两个mmDisp程序实例，其中一个用于显示磁化，另一个用于显示能量，以便将能量值与磁化结构联系起来。
8.如果在实现某些功能时遇到问题，请在oommf/app/oxs/examples中的MIF文件中搜索类似的内容。例如，搜索“pulse”会匹配到pillar.mif, pingpillar.mif, 和pulse.mif，其中每个MIF文件都演示了如何实现各种形状的外加磁场脉冲。
18 数据表文件格式（ODT）
求解器程序的非矢量场类型的文本输出是OOMMF Data Table（ODT）格式的。它是一种ASCII文本格式，标题中有列信息，每条记录有一行数据。在处理之前，任何以“\”字符结尾的行都会连接到下一行，并且删除下一行开头的“#”字符。
与OVF格式一样，所有非数据行都以“#”字符开头，注释以两个“#”字符开头。（这样的设计更有利于把数据导出到外部程序，例如一些绘图程序。）图10是一个示例：
# ODT 1.0
# Table Start
# Title: This is a small sample ODT file.
#
## This is a sample comment. You can put anything you want
## on comment lines.
#
# Columns: Iteration "Applied Field" {Total Energy} Mx
# Units: {} "mT" "J/m^3" "A/m"
103 50 0.00636 787840
1000 32 0.00603 781120
10300 -5000 0.00640 -800e3
# Table End
Figure 10: Sample ODTfile.
ODT文件的第一行是文件类型描述符：# ODT 1.0。建议把ODT文件的文件扩展名设为 .odt，以便识别ODT文件。
ODT文件的其余行由注释、数据或以下5个可识别的标签行组成：
• # Table Start：可选的标签，用于分割文件中的多个数据表。该标签冒号之后的所有内容都将被忽略。
• # Title：可选的标签，冒号后面的内容表示为表格的标题。
• # Columns：必选的标签。每一列接受一个参数，该参数就是该列的标题。可以使用普通的Tcl分组机制（即双引号和大括号）将空格嵌入到列标签中。
• # Units：可选的标签。如果使用了该标签，则每一列接受一个参数，该参数表示列的单位。单位标签中可以嵌入空格，方式与列标题相同。
• # Table End：可选的标签，无参数。但它要与相应的# Table Start配对。
数据可以出现在列标签行之后，表格结束标签行之前的任何位置，一条数据就占据一行，数据是用空格分隔的数值。用大括号对“{}”表示缺失值。
# Title、# Columns和# Units中不允许嵌入换行符和回车符。
命令行程序odtcols可用于检查和分割ODT文件。
19 矢量场文件格式（OVF）
矢量场文件包含矢量场（例如磁化强度或磁通密度），矢量场是关于空间位置的函数。OOMMF Vector Field（OVF）格式是2D和3D微磁求解器的输出矢量场的文件格式，它也是mmDisp读取的输入数据的格式。OOMMF支持的OVF格式有三个版本：OVF 1.0和2.0格式是OOMMF软件首选的格式，两种格式都支持矩形和不规则网格，都支持二进制和ASCII文本类型的数据。
OVF 0.0格式（以前称为SVF）是一种更老的、更简单的格式，可用于从其它程序将三维矢量场数据导入到OOMMF。（第四种格式，即VecFil或Vector Input/Output（VIO）格式，只有一些老式的OOMMF代码使用。虽然OOMMF能够读取VIO格式，但它早已被弃用了。）
在所有格式中，矢量场的空间范围是在三维空间中的，通常以米或纳米表示单位。在除了OVF 2.0格式之外的其它格式中，场值（译者注：即矢量场在某位置点的矢量值）也是三维的，场值单位有很多，但通常为特斯拉或A/m。OVF 2.0格式更加灵活，因为OVF 2.0格式的场值可以是任意维度（N>0）。（但是，维度在文件中是固定了的。）如果N=3，则OVF 2.0格式支持与OVF 1.0格式相同的数据类型，若N=1，则表示标量场，例如能量密度（即J/m3）。
建议把用于表示磁化强度（M）的OVF文件的扩展名设置为.omf，表示磁场强度（H）的扩展名设置为.ohf，表示磁通密度（B）的扩展名设置为.obf，表示能量密度的扩展名设置为.oef，通用OVF文件的扩展名则设置为.ovf。
19.1 OVF 0.0格式。
OVF 0.0格式是一种简单的ASCII文本格式，它支持不规则采样的数据。该格式旨在帮助从非OOMMF程序导入数据，并与第一个µMAG标准问题使用的格式兼容。
OOMMF早期版本的用户可以通过OVF 0.0格式的曾用名（Simple Vector Field（，SVF）格式来识别它。OOMMF开发人员注意到文件扩展名“.svf”已经在MIME系统中被注册了，它表示的是简单的矢量格式，即一种矢量图形格式。为了避免冲突，已经停止使用Simple Vector Field格式，但OOMMF软件仍然能识别出“.svf”扩展名的格式，用户仍然可以找到一些使用SVF格式的示例文件。
# 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 11: Example OVF 0.0file.
OVF 0.0文件示例如图11所示。任何以“#”字符开头的行都是注释行，其它所有行都是数据行。每个数据行是一个由6个使用空格分隔的元素组成的列表：前三个元素分别表示位置点的x、y和z坐标分量，后三个元素表示该位置点的场值的x、y和z分量。数据行一直延伸到文件末尾。建议（但不是必需的）OVF文件的第一行设置为：
# OOMMF: irregular mesh v0.0
这有助于OOMMF自动检测文件类型。此外，mmDisp还可以识别OVF 0.0文件中的三条特殊（扩展）注释：
## File:
## Boundary-XY:
## Grid step:
这三个注释行都是可选的，在“File”行可以设置首选的（扩展）文件名。“Boundary-XY”行可以设置在XY平面中的多边形边界的有序顶点，如果设置了该行，则mmDisp将使用这些点绘制一个边界，以表示模拟区域的边缘。“Grid step”行可以设置三个值，表示与单个位置点（场样本）对应空间的平均x、y和z尺寸，mmDisp利用该行来帮助缩放显示。
注意，OVF 0.0文件的数据部分是ASCII格式的数值列。用ASCII表示的以空格分隔的数值列很容易导入到其它处理数值集合的程序中，并且ASCII格式的数值列是很容易生成的，因此OVF 0.0格式对于OOMMF和非OOMMF程序之间交换矢量场数据很有用。此外，OVF 0.0文件的数据部分与OVF 1.0文件的数据部分是一致的（OVF 1.0文件已使用文本数据表示保存为不规则网格）。这意味着，尽管OOMMF软件现在的矢量场数据使用的是OVF 1.0格式，但仍然支持与其它程序简单交换矢量场数据。
19.2 OVF 1.0格式。
# 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 data block values by this
# ## to get true value in 'valueunits'.
#
# ValueRangeMaxMag: 1005.3096 ## These are in data block value units,
# ValueRangeMinMag: 1e-8 ## and 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 12: Commented OVF samplefile.
图12是一个包含解释说明的OVF 1.0示例文件。OVF文件有ASCII文本格式的段落标题开始行和对应的结束行，以及一个ASCII文本格式或者二进制格式的数据块。所有非数据行都以“#”开头，用“##”开头的行是注释行，注释将一直持续到行尾。OVF文件中没有续行符，以“#”开头但仅包含空格的行将被忽略。
段落标题块中的所有非空非注释行的构造形式都是“标签+值”对的形式。行首的“#”之后，一直到第一个冒号（“：”）之前的所有字符组成标签，并且忽略大小写，删除所有空格和制表符。标签的值由第一个冒号后，一直到“##”注释符或行尾的所有字符组成。
OVF文件的第一行应该是文件类型标识行，即：
# OOMMF: rectangular mesh v1.0
或
# OOMMF: irregular mesh v1.0
其中标签的值“rectangular mesh v1.0”或“irregular mesh v1.0”表示网格类型和OVF的版本。在早期的OOMMF版本中，OVF 1.0格式是逐渐推广的，因此在文件类型标识行中有时也会出现版本号0.99和0.0a0。现版本的OOMMF在读取OVF文件时，会把这些版本号当做1.0来处理。
OVF文件的其余部分在概念上被分为段落块，每个段落块由段落标题块和数据块组成。每一种块都是以“# Begin:
# Segment count: 1
目前只允许1个段落！在将来可能会更改此规则，以允许每个文件保存多个矢量场。下一行是：
# Begin: Segment
表示一个段落的开始。
19.2.1段落标题块。
段落标题块的开始行是“# Begin: Header”，结束行是“# End: Header”。开始和结束行之间的所有内容要么是注释，要么是以下用于描述OVF文件的标签行。描述文件的标签行是顺序无关的。除非明确说明是可选的标签，否则这些描述文件的标签行均为必选的。标签的值（数值）除非明确说明为“整数”，否则便为浮点值。
• title：长文件名或标题名称。
• desc：用于解释说明的行。可选的标签行，用户应该尽可能多地使用此标签行。此标签行可以通过后续处理程序来获取，而不像注释行一样被忽略。
• meshunit：网格的基本空间单位，作为标签处理。此标签行中不允许使用注释“##”。示例值：“nm”。
• valueunit：场值的基本单位，作为标签处理。此标签行中不允许使用注释“##”。示例：“kA/m”。
• valuemultiplier：将数据块中的数值乘以该值，并以“valueunit”为单位作为实际值。这简化了把数值进行标准化的过程。
• xmin, ymin, zmin, xmax, ymax, zmax：分别是六个单独的行，以“meshunit”为单位指定网格的边界盒子。显示程序可利用它们来限制显示区域，如果未设置“boundary”标签行，显示程序则会根据它们来绘制边界。
• boundary：指定边界各顶点的(x,y,z)三元组列表。此标签行是可选的。
• ValueRangeMaxMag, ValueRangeMinMag：数据块中场值的最大和最小幅值，单位和比例与数据块中的相同。这两个标签行都是可选的，可以为后续处理程序提供参考，例如，mmDisp不会显示幅值小于ValueRangeMinMag的任何矢量。如果ValueRangeMinMag和ValueRangeMaxMag均为零，则会忽略这两个标签行。
• meshtype：网格的结构类型，取值“rectangular”或“irregular”。不规则网格文件应在段落标题块中设置“pointcount”标签行，而矩形网格文件应设置“xbase、ybase、zbase”、“xstepsize、ystepsize、zstepsize”和“xnodes、ynodes、znodes”标签行。
• pointcount：数据采样点的数量，即节点数量（整数）。仅用于不规则网格。
• xbase, ybase, zbase：三个单独的行，以“meshunit”为单位表示数据段中第一个点的位置，仅用于矩形网格。
• xstepsize, ystepsize, zstepsize：三个单独的行，以“meshunit”为单位指定相邻网格之间的距离，若meshtype为矩形网格则必须设置这三个标签行，但也可以作为不规则网格的提示。
• xnodes, ynodes, znodes：三个单独的行，指定每个方向轴上的节点数量（整数）。仅用于矩形网格。
19.2.2数据块。
数据块的开始行是：
# Begin: data
使用二进制方式表示的是按网络字节顺序（MSB）的IEEE浮点数。为了确保字节顺序的正确，并校验文件是否使用非8位的通道，第一个数据值是预定义的校验值：“binary 4”为1234567.0（Hex：49 96 B4 38），“binary 8”为123456789012345.0（Hex：42 DC 12 21 83 77 DE 40）。在校验值之后便是数据值。
数据的组成结构取决于“meshtype”是“irregular”还是“rectangular”。对于不规则网格，每一项数据（即通常就是一行数据）包含一个6元组（即6个数值），分别是位置点的x、y和z坐标分量，和该位置点的场值的x、y和z分量。每项数据之间是顺序无关的。有多少项数据由“pointcount”行决定。
对于矩形网格，数据的组成结构是场值的x、y、z分量的三元组构成的。与场值对应的位置点的坐标递增顺序是先递增x坐标，然后递增y坐标，最后递增z坐标。即这里使用的是Fortran语言数组的索引顺序，因为通常x的尺寸最长，z的尺寸最短，所以这种顺序比C语言数组索引顺序（z，y，x）更有效地访问内存。位置点之间的坐标跨度区间是根据“xnodes,ynodes,znodes”行计算得到的。
在任何情况下，最后一个数据值的后面都应该是一个换行符，接着是：
# End: data
# End: segment
表示段落的结束行，即文件结束。
注意：若一个OVF 1.0文件的数据格式是ASCII，网格类型是不规则的话，那么该文件也是一个有效的OVF 0.0（SVF）文件，但它的“# valueunit”和“# valuemultiplier”行设置的缩放是不可用的。
19.3 OVF 2.0格式。
OVF 2.0是OVF 1.0格式的升级版，该格式不仅可以保存跨三个空间维度的场，也可以保存任意（但固定）空间维度的值。在OVF2.0格式中：
1.无论是规则网格还是不规则网格，文件第一行都是：# OOMMF OVF 2.0。
2.在段落标题块中，新增的valuedim标签行是必选的，它的值必须是一个大于或等于1的整数值（N，即值的空间维度）。
3.在段落标题块中，新增的valueunits代替了OVF 1.0的valueunit标签行。valueunits的值是单位构成的（Tcl）列表，而不再是OVF 1.0中的一个单位，列表的长度应为N（由valuedim指定），在这种情况下，列表中每个元素表示该索引对应的维度的单位。若列表的长度为1，在这种情况下，列表中的唯一单位就表示所有维度的单位。OVF 2.0文件中不能使用旧的valueunit标签。
4.在段落标题块中，新增的valuelabels标签行是必选的。它的值是一个N个便签构成的（Tcl）列表，每个维度只使用一个便签，便签用于解释每个维度代表的物理量。例如，在能量密度文件中，N应该为1，valueunits应该为J/m3，valuelabels应该为“Exchange energy density”。
5.在段落标题块中，不再支持OVF 1.0中的valuemultiplier, boundary, ValueRangeMaxMag和ValueRangeMinMag标签行。
6.在数据块中，对于规则网格，每一项数据由N个值组成，其中N是由valuedim决定的值的空间维度，位置点的顺序与OVF 1.0格式相同。对于不规则网格，每一项数据由N+3个值组成，其中前三个值是位置点的x、y和z坐标分量。对于使用文本模式且N=3的数据块，OVF 2.0文件中的数据块则和OVF 1.0完全相同。
7.使用二进制方式表示数据块的OVF 2.0的数据结构与OVF 1.0相同，但与OVF 1.0使用的MSB顺序不同，OVF 2.0的所有二进制值都是以小端（LSB）顺序写入的，包括初始校验值以及后面的数据值。（初始校验值，4字节格式的IEEE浮点数1234567.0，对应的LSB十六进制字节序列为：38 B4 96 49，8字节格式的IEEE浮点数123456789012345.0，对应的LSB十六进制字节序列为：40 DE 77 83 21 12 DC 42）。
OVF 2.0的其它地方和OVF 1.0是相同的，以下是（N=2，不规则网格类型）OVF 2.0文件示例（图13）。
# OOMMF OVF 2.0
#
# Segment count: 1
#
# Begin: Segment
# Begin: Header
#
# Title: Long file name 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
Figure 13: Commented OVF 2.0 samplefile.
20 故障排除
OOMMF开发人员依赖用户的报告来改正软件及文档存在的问题，并引导新功能的选择和实现。有关如何联系OOMMF开发人员，请参见第22节开发人员。
用户的报告越完整，后续关于确定问题的原因所需的信息就越少。通常，当出现问题时，OOMMF软件会产生错误消息，会出现一个堆栈跟踪，以显示有关错误的更多细节。用户在报告错误时，最好把错误消息和堆栈跟踪剪切并粘贴到问题报告中，这将帮助开发人员诊断问题。此外，请附上使用命令tclsh oommf +platform生成的输出，这非常重要，因为它会帮助OOMMF开发人员识别与安装或平台相关的问题。
在向OOMMF开发人员报告之前，请查看以下已知问题列表。在软件发布后发现的其它问题，都发布在OOMMF网站上特定版本的“patch”页面。
1.编译时，出现无法打开系统头文件（如stdlib.h, time.h, math.h）或系统库或相关程序启动代码的错误。这通常表示编译器的安装不正确。如果您在Windows上运行并使用Microsoft Visual C++的命令行编译器来构建，您是否记得运行vcvars32.bat设置必要的环境变量？如果您使用的是Borland C++编译器，则bcc32.cfg 和ilink32.cfg文件是否正确配置？请用户再仔细查看第2.3节高级安装中有关编译器的所有内容。
2.编译时，出现如下错误：
<30654> pimake 1.x.x.x MakeRule panic:
Don't know how to make '/usr/include/tcl.h'
这个错误表示安装的Tcl缺少头文件tcl.h。其它缺少的头文件可能是安装的Tk中的tk.h，或在Unix上安装的X Window System中的Xlib.h。为了编译OOMMF，您需要安装Tcl、Tk和（如果需要）X的开发版本。安转因平台而异：在Windows上，您不需要安装X，但当您安装Tcl/Tk时，请确保是“完整”安装，或带有“header and library files”的安装。在Linux上，一定要安装开发者软件包和用户软件包。在其它平台上不太可能出现这个错误。若缺少Xlib.h，则可能是tkConfig.sh文件中的TK_XINCLUDES不正确，解决方法是在文件oommf/config/platforms/平台名称 中添加以下行：（根据您的系统调整include的目录。）
$config SetValue TK_XINCLUDES "-I/usr/X11R6/include"
3.编译时，出现一个表示不支持异常的错误。
OOMMF的部分内容是用C++编写的，而异常又是C++语言的一部分。如果您的编译器不支持异常，那么是时候升级它们了。OOMMF 1.2要求编译器能够编译使用C++异常的源代码。
4.使用gcc编译时，产生了涉及auto_ptr模板的语法错误。
这在RedHat 5.2系统上是已知的错误。auto_ptr定义在系统的STL头文件memory中（在RedHat 5.2系统上，位于/usr/include/g++目录中），auto_ptr被两个#if语句禁用。一种解决方法是编辑此文件以关闭#if，若这样做，还需要在成员函数release()的定义中修改相关设置。
5.编译时，若在include的搜索路径中没有所需的include目录，则会出现一条错误消息。您可以尝试把所需的目录添加到平台文件的program_compiler_c++_system_include_path中，例如：
$config SetValue program_compiler_c++_system_include_path \
[list /usr/include /usr/local/include]
6.在Solaris系统上，gcc报告的错误如：
ANSI C++ forbids declaration‘XSetTransientForHint’ with no type
在许多Solaris系统上，X Window System的头文件并不符合ANSI标准，于是gcc就报错。要解决此问题，请编辑oommf/config/platforms/solaris.tcl文件，为gcc命令行添加-fpermissive选项。
7.在Windows上，当首次启动oommf.tcl时，有一个错误：
Error launching mmLaunch version 1.x.x.x:
couldn't execute "...\omfsh.exe": invalid argument
这很可能意味着您下载的OOMMF二进制文件与系统上安装的Tcl/Tk版本不匹配。请重新下载OOMMF，并注意下载与您安装的Tcl/Tk版本相匹配的二进制文件。
8.当首次启动oommf.tcl时，有一个错误：
Error in startup script: Neither Omf export nor
Omf_export_list set in
表示您安装的OOMMF中可能缺少oommf/pkg/net/omfExport.tcl文件。如有必要，请重新下载并安装OOMMF。
9.当在Unix系统上启动oommf.tcl时，出现以下形式的错误：
error while loading shared library: libtk8.4.so: cannot open
shared object file: No such file or directory
这通常是由于libtk#.#.so（或libtcl#.#.so）文件的安装目录没有在ld.so的运行时链接器/加载器的搜索路径中。一种解决方法是将该目录（比如/usr/local/lib）添加到环境变量LD_LIBRARY_PATH中。例如，在您的~/.bashrc文件（bash shell user）中添加：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
或者在您的~/.cshrc文件（csh or tcsh shell users）中添加：
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/usr/local/lib
另一种方法是修改ld.so的缓存，有关详细信息，请参阅ld.so和ldconfig手册。
10.在Windows的Cygwin环境中启动OOMMF时，mmLaunch的窗口短暂出现，然后消失，但没有出现任何错误消息。
Cygwin环境中包含的一些旧版本的Tcl/Tk（即/usr/bin/tclsh）的套接字代码中存在漏洞，导致OOMMF以这种方式崩溃。这个问题在当前的Cygwin版本中已经修复。
11.内存耗尽了！
您是否使用mmGraph监视长时间运行的模拟？默认情况下，发送到mmGraph的所有数据都保存在内存中。有关如何处理此问题，请参阅mmGraph文档。
12.当您运行多个OOMMF子程序时，其中一些子程序可能会没有响应。
操作系统对一个进程一次可以打开的文件数量设置了上限，数量各不相同，但默认数量通常是几百到几千。OOMMF的子程序通过本地主机套接字相互通信，每个套接字连接都算作一个打开的文件，因此，如果您在一个帐户下运行数百个OOMMF子程序，那么可能会达到这个数量限制。您可以增加打开的文件数量的限制（例如，在Linux和macOS上，设置ulimit的-n选项），但更好的解决方法是把它们划分为几个较小的独立组，并使用launchhost程序在单独的主机+帐户服务器下运行每个组。
21 参考文献
[1] A. Aharoni, Introduction to the Theory of Ferromagnetism (Oxford, New York, 1996).
[2] A. Aharoni,“Demagnetizing factors for rectangular ferromagnetic prisms,” J. App.
Phys., 83, 3432–3434 (1998).
[3] D. V. Berkov, K. Ramstöck, and A. Hubert,“Solving micromagnetic problems: Towards
an optimal numerical method,” Phys. Stat. Sol. (a), 137, 207–222 (1993).
[4] W. F. Brown, Jr., Micromagnetics (Krieger, New York, 1978).
[5] M. J. Donahue and R. D. McMichael,“Exchange energy representations in computa-
tional micromagnetics,” Physica B, 233, 272–278 (1997).
[6] M. J. Donahue and D. G. Porter, OOMMF User’s Guide, Version 1.0, Tech. Rep. NIS-
TIR 6376, National Institute of Standards and Technology, Gaithersburg, MD (1999).
[7] J. R. Dormand and P. J. Prince,“A family of embedded Runge-Kutta formulae,” J.
Comp. Appl. Math., 6, 19–26 (1980).
[8] J. R. Dormand and P. J. Prince,“A reconsideration of some embedded Runge-Kutta
formulae,” J. Comp. Appl. Math., 15, 203–211 (1986).
[9] J. Fidler and T. Schrefl,“Micromagnetic modelling— the current state of the art,” J.
Phys. D: Appl. Phys., 33, R135–R156 (2000).
[10] T. L. Gilbert,“A Lagrangian formulation of the gyromagnetic equation of the magne-
tizationfield,” Phys. Rev., 100, 1243 (1955).
[11] P. R. Gillette and K. Oshima,“Magnetization reversal by rotation,” J. Appl. Phys., 29,
529–531 (1958).
[12] L. Landau and E. Lifshitz,“On the theory of the dispersion of magnetic permeability
in ferromagnetic bodies,” Physik. Z. Sowjetunion, 8, 153–169 (1935).
[13] R. D. McMichael and M. J. Donahue,“Head to head domain wall structures in thin
magnetic strips,” IEEE Trans. Mag., 33, 4167–4169 (1997).
[14] L. Néel,“Some theoretical aspects of rock magnetism,” Adv. Phys., 4, 191–242 (1955).
[15] A. J. Newell, W. Williams, and D. J. Dunlop,“A generalization of the demagnetizing
tensor for nonuniform magnetization,” J. Geophysical Research - Solid Earth, 98, 9551–
9555 (1993).
[16] D. G. Porter and M. J. Donahue,“Generalization of a two-dimensional micromagnetic
model to non-uniform thickness,” Journal of Applied Physics, 89, 7257–7259 (2001).
[17] M. R. Scheinfein, J. Unguris, J. L. Blue, K. J. Coakley, D. T. Pierce, and R. J. Celotta,
“Micromagnetics of domain walls at surfaces,” Phys. Rev. B, 43, 3395–3422 (1991).
[18] J. Stoer and R. Bulirsch, Introduction to Numerical Analysis (Springer, New York,
1993), 2nd edn.
[19] E. C. Stoner and E. P. Wohlfarth,“A mechanism of magnetic hysteresis in heterogeneous
alloys,” Phil. Trans. Royal Soc. London, A240, 599–642 (1948).
[20] B. B. Welch, Practical Programming in Tcl and Tk (Prentice Hall, Upper Saddle River,
New Jersey USA, 2000), 3rd edn.
[21] J. Xiao, A. Zangwill, and M. D. Stiles,“Boltzmann test of Slonczewski’s theory of
spin-transfer torque,” Phys. Rev. B, 70, 172405 (pages 4) (2004).
22 开发人员
本手册的主要作者是Michael J. Donahue ([email protected])，Donald G. Porter ([email protected])，ITL/NIST。本手册的第3章是基于Dianne P. O’Leary的笔记编写的。
OOMMF软件的代码主要由Michael Donahue和Donald Porter开发。Robert D. McMichael ([email protected])为2D微磁求解器的早期开发做出了贡献。Jason Eicke开发了问题编辑器的第一个版本，并开发2D微磁求解器的自静磁模块。
许多用户通过提交错误报告、小部分代码或改进建议，为OOMMF的发展做出了贡献。感谢所有这些人，包括Atif Aziz, Loris Bennett, Richard Boardman, Greg Brown, Dieter Buntinx, NgocNga Dao, Hans Fangohr, Colm Faulkner, Olivier Gérardin, Ping He, Michael Ho, Mansoor B.A. Jalil, Jörg Jorzick, Pierre-Olivier Jubert, Pavel Kabos, Michael Kleiber, Kristof Lebecki,Oliver Lemcke, H. T. Leung, David Lewis, Sang Ho Lim, Yi Liu, Van Luu, Andy P. Manners,Damien McGrouther, Johan Moulin, Wong Lai Mun, Edward Myers, Andrew Newell, Valentine Novosad, Andrew Perrella, Angeline Phoa, Anil Prabhakar, Robert Ravlic, Stephen E.Russek, Renat Sabirianov, Zhupei Shi, Xiaobo Tan, Alexei Temiryazev, Alexander Thieme,Stephen Thompson, Vassilios Tsiantos, Pieter Visscher, Ruifang Wang, Scott L. Whittenburg, Kong Xiangyang, Ming Yan, Tan Swee Yong, Chengtao Yu, Steven A. Zielke, and Pei Zou。
如果您有关于OOMMF的错误报告、代码、功能请求或其它评论，请通过电子邮件发送到<[email protected]>。如使用本软件，我们建议引用以下NIST技术报告：
M. J. Donahue and D. G. Porter
OOMMF User’s Guide, Version 1.0
Interagency Report NISTIR 6376
National Institute of Standards and Technology, Gaithersburg, MD (Sept 1999).
也可以是OOMMF主页的URL：https://math.nist.gov/oommf/ 。为了帮助我们保持参考书目的最新状态，请将相关出版信息发送到[email protected]。