学习自旋电子学的笔记01：微磁模拟软件OOMMF的教程（中文版）1-6章
雄关漫道真如铁，而今迈步从头越。----《忆秦娥·娄山关》
# 前言
这是oommf软件教程《OOMMF User’s Guide》的中文翻译文章，由于本人水平有限，有些翻译可能有错误，望见谅。后续章节的翻译正在进行，以大约2万字为节点上传一次。
免责声明
1 OOMMF概述
2 安装
2.1要求。
2.2基本安装。
2.2.1下载。
2.2.2安装的Tcl/Tk的影响。
2.2.3检查平台配置。
2.2.4编译和链接。
2.2.5安装。
2.2.6使用OOMMF软件。
2.2.7报告问题。
2.3高级安装。
2.3.1减少磁盘空间使用。
2.3.2本地化。
2.3.3优化。
2.3.4并行化。
2.3.5管理OOMMF平台名称。
2.4平台特定安装问题。
2.4.1 Unix配置。
2.4.2 Mac OS X配置。
2.4.3 Microsoft Windows选项。
3 快速入门： OOMMF示例
4 OOMMF架构概述
5 命令行启动
6 OOMMF启动/控制器界面：mmLaunch
OOMMF
User’s Guide
September 30, 2019
This manual documents release 2.0a2.
WARNING: In this alpha release, the documentation may not be
up to date.
Abstract
本手册描述了OOMMF（面向对象的微磁框架），这是美国国家标准与技术研究所开发的微磁学开源程序。该程序具有可移植、灵活、可扩展，具有用户友好的图形界面。代码是用C++和Tcl/Tk编写的。目标系统包括Unix、Windows和Mac OS X平台。
目录
免责声明
1 OOMMF概述
2安装
2.1要求。
2.2基本安装。
2.2.1下载。
2.2.2安装的Tcl/Tk的影响。
2.2.3检查平台配置。
2.2.4编译和链接。
2.2.5安装。
2.2.6使用OOMMF软件。
2.2.7报告问题。
2.3高级安装。
2.3.1减少磁盘空间使用。
2.3.2本地化。
2.3.3优化。
2.3.4并行化。
2.3.5管理OOMMF平台名称。
2.4平台特定安装问题。
2.4.1 Unix配置。
2.4.2 Mac OS X配置。
2.4.3 Microsoft Windows选项。
3快速入门： OOMMF示例
4 OOMMF架构概述
5命令行启动
6 OOMMF启动/控制器界面：mmLaunch
7 OOMMF可扩展求解器
7.1 OOMMF可扩展求解器交互界面：Oxsii。
7.2 OOMMF可扩展批处理求解器界面：boxsi。
7.3标准的Oxs_Ext子类。
7.3.1容器。
7.3.2网格。
7.3.3能量。
7.3.4演化器。
7.3.5驱动器。
7.3.6场对象。
7.3.7 MIF支持类。
8微磁问题编辑器：mmProbEd
9微磁问题文件源：FileSource
10 2D微磁求解器
10.1 2D微磁交互求解器：mmSolve2D。
10.2 OOMMF 2D微磁求解器批处理系统。
10.2.1 2D微磁求解器批处理界面：batchsolve。
10.2.2 2D微磁求解器批处理系统。
11数据表显示：mmDataTable
12数据图显示：mmGraph
13矢量场显示：mmDisp
14数据存储：mmArchive
15文档查看器：mmHelp
16命令行实用程序
16.1位图文件格式转换：any2ppm。
16.2从矢量场生成数据表：avf2odt。
16.3矢量场文件格式转换：avf2ovf。
16.4从矢量场生成位图：avf2ppm。
16.5从矢量场生成PostScript:avf2ps。
16.6矢量场文件差异：avfdiff。
16.7循环冗余校验：crc32。
16.8终止OOMMF进程：killoommf。
16.9最后一次Oxsii/Boxsi运行：lastjob。
16.10启动OOMMF主机服务：launchhost。
16.11从磁化计算H场：mag2hfield。
16.12 MIF格式转换：mifconvert。
16.13进程昵称：nickname。
16.14 ODT衍生数据计算器：odtcalc。
16.15 ODT表连接：odtcat。
16.16 ODT列数据获取：odtcols。
16.17 Oxs包管理：oxspkg。
16.18 Oxs回归测试：oxsregression。
16.19 OOMMF和进程ID信息：pidinfo。
16.20跨平台相关：pimake。
17微磁问题文件格式（MIF）
17.1 MIF 1.1。
17.1.1材料参数。
17.1.2退磁描述。
17.1.3零件几何形状。
17.1.4初始磁化。
17.1.5实验参数。
17.1.6输出描述。
17.1.7杂项。
17.2 MIF 1.2。
17.3 MIF 2.1。
17.3.1 MIF 2.1文件概述。
17.3.2 MIF 2.1扩展命令。
17.3.3Specify的使用惯例。
17.3.4变量替换。
17.3.5 MIF 2.1文件示例。
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 编写2.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开发人员
免责声明
该软件由美国国家标准与技术研究所的工作人员开发。根据《美国法典》第105节第17篇，本软件不受版权保护，属于开源软件。
OOMMF是一个实验系统。NIST对其被其他方使用不承担任何责任，也不对其质量、可靠性或任何其他特性做出任何明示或暗示的保证。
如果使用该软件，我们将不胜感激。当引用OOMMF软件时，我们建议引用NIST的M. J. Donahue 和D. G. Porter的报告“OOMMF User’s Guide, Version 1.0,” NISTIR 6376, National Institute of Standards and Technology, Gaithersburg, MD (Sept 1999)。
这些页面中提到的商业设备和软件仅用于信息目的，并不意味着国家标准与技术研究所推荐或认可，也不意味着该产品一定是用于此目的的最佳产品。
1 OOMMF概述
国家标准与技术研究所（NIST）信息技术实验室（ITL）的OOMMF（面向对象的微磁框架）项目的目标是开发一个可移植、可扩展的开源微磁程序和相关工具。这些代码构成了一个功能完整的微磁学包，其他程序员可以扩展它的额外功能，这样开发新代码的人就可以在OOMMF基础上进行开发。OOMMF的主要贡献者是Mike Donahue 和Don Porter。
OOMMF是用C++编写的，C++是一种广泛使用的、面向对象的语言，可以生成具有良好性能和可扩展性的程序。对于可移植的用户界面，我们使用Tcl/Tk，这样OOMMF就可以在各种Unix、Windows和Mac OS X平台上运行。
代码可以在三个不同的级别进行修改。在顶层，各个程序通过定义的协议使用网络套接字进行交互。可以通过用户界面以各种方式将这些模块连接在一起，并且可以透明地添加使用相同协议的新模块。第二个修改级别是Tcl/Tk脚本级别。一些模块允许在运行时导入和执行Tcl/Tk脚本，Tcl/Tk脚本相对容易修改或替换。在最底层，提供了C++源代码，并且可以对其进行修改，但目前相关文档还不完整（请参阅“OOMMF Programming Manual”）。
当前的版本OOMMF 2.0包括Oxs，即OOMMF可扩展求解器。Oxs为OOMMF用户提供了扩展Oxs的能力。Oxs求解器的可扩展性意味着它的能力可以根据需要进行变化以解决问题。作为OOMMF的一部分而分发的Oxs模块支持完整的适合于分层建模的材料的3D模拟。
如果您希望收到有关此项目更新的电子邮件通知，请在“µMAG”邮件列表中注册您的电子邮件地址：http://www.ctcms.nist.gov/˜rdm/email-list.html.
OOMMF开发者对用户关于OOMMF的评论感兴趣。见（22开发人员）了解如何联系他们，以及参考OOMMF的信息。
2 安装
2.1要求。
OOMMF软件是用C++和Tcl编写的。它使用基于Tcl的Tk 窗口工具包来创建的可移植到Unix、Windows和Mac OS X的图形用户界面。
在安装OOMMF之前，必须先安装Tcl和Tk。Tcl和Tk可从Tcl开发者Xchange获得。推荐使用与本次发布的OOMMF同步的最新稳定版本的Tcl和Tk。OOMMF至少需要Tcl和Tk的8.5版本。OOMMF软件不支持Tcl/Tk的任何alpha或beta版本，并且OOMMF的每个版本可能无法与Tcl/Tk的后续版本一起使用。需要检查OOMMF和Tcl/Tk的发布日期以确保兼容性。
Tcl/Tk的安装包括两个shell程序。这些程序的名称可能因Tcl/Tk版本和平台类型而异。第一个shell程序包含一个基于Tcl的解释器。在OOMMF文档中，我们将该程序称为tclsh。第二个shell程序包含由Tk工具包提供的额外Tcl命令扩展。在OOMMF文档中，我们将该程序称为wish。需要查阅Tcl/Tk文档，以确定平台上这些程序的实际名称（例如，tclsh86.exe或wish8.6）。
OOMMF的各个程序通过TCP/IP网络套接字进行通信。这意味着即使是在离线模式下，OOMMF也需要对网络的支持，即OOMMF必须能够访问本机的回环接口，以便主程序可以使用TCP/IP与其他程序通信。
使用Tk的OOMMF子程序需要一个窗口系统和有效的显示器。在Unix系统上，这意味着必须运行X服务器。如果需要在没有显示硬件或软件的Unix系统上运行OOMMF程序，则需要使用命令行选项-tk 0或者使用Xvfb虚拟帧缓冲区启动程序。
要从源代码层次构建OOMMF软件，不仅需要一个实现C++11标准功能的C++编译器，也还需要其他软件来开发。已经在以下平台上进行了开发和测试构建：
上面的每个平台都支持32位和64位版本，不过为了避免对模拟大小的限制，大多数都倾向于使用64位版本。
2.2基本安装。
按照以下说明，在计算机上安装好OOMMF软件。
2.2.1下载。
OOMMF软件的最新版本可从OOMMF官方下载页面获取。每个版本有两种格式。第一类是包含所有OOMMF源代码的.tar.gz后缀格式的压缩文件。第二类是包含基于Windows平台的源代码和预编译的可执行文件的.zip后缀格式压缩文件。每个基于Windows平台的发行版仅与特定发行序列的Tcl/Tk的兼容。例如，Tcl/Tk 8.6.x的Windows版本与Tcl/Tk 8.6.0、8.6.1等兼容。
对于第一种格式，使用gunzip和tar软件的命令来解压缩:gunzip -c oommf20a0.tar.gz | tar xvf –
对于其他格式，需要相应程序来解压缩该.zip文件。这里选择UnZip软件，解压命令：unzip oommf20a0_86.zip。解压.zip文件后，对于任何一种发行格式，解压后都会有一个oommf目录，其中包含oommf发行版的所有文件和目录。如果名为oommf的子目录已经存在（比如，早期的oommf版本），那么新发行版中的文件将覆盖磁盘上已有的同名文件。在这种情况下，需要小心的将旧的和新的OOMMF发行版生成的文件组合兼容。
另一个限制是Tcl/Tk和OOMMF中内存地址的宽度必须匹配。如今，大多数通用操作系统主要使用64位内存地址，但为了向后兼容，也可以使用32位内存地址运行程序。但是，64位可执行文件不能链接到32位库，反之亦然。因此，如果安装了64位Tcl/Tk，则需要64位OOMMF，同样，32位Tcl/Tk也需要32位OOMMF。另一个限制是，虽然OOMMF可以构建为使用线程在共享内存机器上的多个cpu核上并行运行，但要做到这一点，需要启用已安装的Tcl/Tk线程。Windows和Mac OS X上典型的Tcl/Tk安装都是支持线程的。最新版本的Unix上的Tcl/Tk安装也倾向于支持线程，但一些较旧版本有非线程的Tcl/Tk安装。如果您的系统Tcl/Tk安装是非线程的，那么您可以构建一个非线程版本的OOMMF，或者可以在主目录或/usr/local下进行额外的线程化Tcl/Tk安装。请注意，如果系统上安装了多个Tcl/Tk，那么无论何时构建或启动OOMMF，都需要小心使用正确的tclsh。如果使用预构建的二进制文件下载OOMMF，则必须选择与要运行OOMMF的Tcl/Tk的主要+次要版本号和内存地址宽度相匹配的下载。另一方面，如果从源代码构建OOMMF，那么将检查用于运行构建过程的tclsh，以确定有关本地Tcl/Tk环境的相关信息。如下一节所述，可能需要对平台配置文件进行一些调整。此外，在许多情况下，用于构建32位和64位可执行文件的编译器是不同的。如果遇到构建问题，请仔细检查是否使用了正确的编译器。所有包含预构建二进制文件的OOMMF下载都是为使用线程化Tcl/Tk而构建的。如果你想要一个非线程OOMMF，你需要从源代码构建。构建脚本将检测运行构建过程的tclsh是否是非线程的，并将适当地构建OOMMF。在所有情况下，使用下一节中描述的平台配置检查来验证Tcl/Tk和OOMMF安装的兼容性。
2.2.2安装的Tcl/Tk的影响。
OOMMF以多种方式与Tcl/Tk交互。其中一个限制是，安装的Tcl/Tk的主要+次要版本号必须与构建OOMMF所依赖的Tcl/Tk的主要+次要版本号相匹配。例如，如果OOMMF是使用Tcl/Tk 8.5.18构建的，那么生成的可执行文件可以与8.5.*系列中任何过去或未来版本的Tcl/Tk一起运行，但不会与8.4.*或8.6.*系列版本的Tcl/Tk一起运行。
另一个限制是Tcl/Tk和OOMMF中内存地址的宽度必须匹配。如今，大多数通用操作系统主要使用64位内存地址，但为了向后兼容，也可使用32位内存地址运行程序。但是，64位的可执行文件不能链接到32位的库，反之亦然。因此，如果安装了64位Tcl/Tk，则需要64位OOMMF，同样，32位Tcl/Tk也需要32位OOMMF。
另一个限制是，虽然OOMMF可以构建为在具有多个cpu核上共享内存的机器上使用多线程来并行运行，但要做到这一点，已安装的Tcl/Tk需要启用多线程功能。Windows和Mac OS X上安装的Tcl/Tk都是支持多线程的。最新版本的Unix上的Tcl/Tk安装也支持多线程，但一些安装较旧版本的Tcl/Tk不支持多线程。如果系统安装的Tcl/Tk是非多线程的，那么可构建一个非多线程版本的OOMMF，或者可以在主目录或/usr/local下额外安装支持多线程的Tcl/Tk。注意，如果系统上安装了多个Tcl/Tk，那么无论何时构建或启动OOMMF，都需要小心使用相应的tclsh。
如果下载带预构建二进制文件的OOMMF，则必须选择下载与要运行OOMMF的主要+次要版本号和内存地址宽度相匹配的Tcl/Tk。如果从源代码构建OOMMF，那么需要检查使用的tclsh，以确定有关本地Tcl/Tk环境的相关信息。如下一节所述，可能需要对平台配置文件进行一些调整。此外，在许多情况下，用于构建32位和64位可执行文件的编译器是不同的。如果遇到构建问题，请仔细检查是否使用了正确的编译器。
所有下载的包含预构建二进制文件的OOMMF都支持多线程的Tcl/Tk。如果想要一个非多线程的OOMMF，需要从源代码构建。构建脚本将检测tclsh是否是非多线程的，并适当地构建OOMMF。
综上，需要使用下一节中描述的内容来验证Tcl/Tk和OOMMF安装的兼容性。
2.2.3检查平台配置。
下载并解包OOMMF后，所有相关文件都在名为oommf的目录中。启动命令行界面（Unix上的shell或Windows上的控制台），并将工作目录更改为该目录。接着查找Tcl壳程序。在本手册中，将Tcl壳程序称为tclsh，查阅Tcl/Tk文档，tclsh的实际名称取决Tcl/Tk的版本和平台类型。在OOMMF根目录中，有一个名为oommf.tcl，它是引导程序，用于启动所有OOMMF子程序。使用命令行参数：+platform,，它将检查tclsh平台配置时打印配置的概述。这个概述描述了平台类型，C++编译器，以及安装的Tcl/Tk信息。例如，以下是Mac OS X 10.9系统上的典型输出：
$ tclsh oommf.tcl +platform
<5426> oommf.tcl 1.2.0.6 info:
OOMMF release 1.2.0.6, snapshot 2015.03.25
Platform Name: darwin
Tcl name for OS: Darwin 13.4.0
C++ compiler: /usr/bin/g++
Version string: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) / Target: x86_64-apple-darwin13.4.0 / Thread model: posix
Shell details ---
tclsh (running): /usr/bin/tclsh
(links to /usr/bin/tclsh8.5)
(links to /System/Library/Frameworks/Tcl.framework/Versions/8.5/tclsh8.5)
--> Version 8.5.9, 64 bit, threaded
tclsh (OOMMF): /usr/bin/tclsh8.5
--> Version 8.5.9, 64 bit, threaded
filtersh: /Users/dgp/oommf/app/omfsh/darwin/filtersh
--> Version 8.5.9, 64 bit, threaded
tclConfig.sh: /System/Library/Frameworks/Tcl.framework/Versions/8.5/tclConfig.sh
--> Version 8.5.9
wish (OOMMF): /usr/bin/wish8.5
--> Version 8.5.9, Tk 8.5.9, 64 bit, threaded
tkConfig.sh: /System/Library/Frameworks/Tk.framework/Versions/8.5/tkConfig.sh
--> Tk Version 8.5.9
OOMMF threads: Yes: Default thread count = 2
OOMMF API index: 20150129
Temp file directory: /var/folders/dy/srfj33512f51kc5knp_lph_r0000gp/T/
如果oommf.tcl +platform命令没有打印类似于上述内容的概述，那么会打印一条说明失败的原因。按照失败原因提供的说明进行操作，并重复使用oommf.tcl +platform命令直到成功打印平台配置信息。
示例概述的第一行里，darwin表示OOMMF识别的平台名称。OOMMF可识别许多流行的计算平台，并为每个平台指定一个平台名称。OOMMF在索引和配置文件中使用平台名称命名目录，安装一个OOMMF就可以支持多种平台类型。如果概述里的平台名称为“unknown”，则需要添加一些配置文件，以帮助OOMMF为平台类型指定名称，并将计算机的一些关键功能与该名称关联。请参阅“管理OOMMF平台名称”一节以获取进一步说明。
第二行报告了操作系统版本，这对OOMMF 开发人员在处理bug时非常有用。第三行报告了将使用哪个C++编译器从其C++源代码构建成OOMMF软件。如果平台下载了带有预编译二进制文件的OOMMF版本，可以忽略这一行。否则，如果此行是“none selected”，或报告的编译器不是希望使用的编译器，那需要配置OOMMF要使用的编译器。为此，必须为该平台编辑适当的配置文件。例如，config/platforms/darwin.tcl文件包含了相关的注释，用户可以编辑它。在其他平台上，在config/platforms/darwin.tcl里的darwin应替换为OOMMF检查得到的平台名称。例如，在使用x86处理器的32位Windows上，相应的配置文件是config/platforms/wintel.tcl。
下一组描述了OOMMF检查得到的平台上的Tcl配置。“tclsh（running）”描述了tclsh正在运行oommf.tcl脚本。“tclsh（OOMMF）”描述了OOMMF运行Tcl脚本时将使用tclsh来解释。如果已经构建了OOMMF二进制文件，那么还会有一行filtersh，它描述了用于运行OOMMF所支持的Tcl增强语言的壳程序。所有这些壳程序都应该报告相同的版本、位数和线程信息。如果OOMMF无法找到tclsh，或者找到了错误的tclsh，那么可将环境变量OOMMF_TCLSH设置为tclsh的绝对位置来解决这一问题。（有关设置环境变量的信息，请参阅操作系统文档。）
tclConfig.sh行描述了该配置文件的全路径名称（如果有）。Unix系统和Windows上Cygwin环境中安装的Tcl有这样一个文件，通常命名为tclConfig.sh。该配置文件记录了有关Tcl的构建方式和安装位置的详细信息。在Windows平台上，这些信息记录在Windows注册表中，因此oommf.tcl +platform命令得到“none found”，如果用户知道系统上存在的Tcl配置文件，则可通过将环境变量OOMMF_TCL_CONFIG设置为其全路径名称来告诉OOMMF从何处查找文件。在异常情况下，OOMMF可能会发现一个不能正确描述本机安装的Tcl的配置文件。在这种情况下，请使用环境变量OOMMF_TCL_CONFIG来指示OOMMF使用指定的文件，并在必要时编辑该文件，以包含对安装的TCL正确描述。
oommf.tcl +platform命令接下来报告了关于wish和Tk配置的信息。环境变量OOMMF_TK_CONFIG和OOMMF_WISH可分别用于告诉OOMMF在哪里可以找到Tk配置文件和wish程序。
之后的信息是一些 “线程”构建和运行状态的行。OOMMF使用多线程在多处理器/多核共享内存机器上的Oxs（oxsii和boxsi）3D求解器中实现并行性。为了构建或运行OOMMF的并行版本，必须有一个支持多线程的Tcl。Tcl线程状态在第一个线程状态行上显示。如果Tcl是支持多线程的，那么在默认的OOMMF构建过程中将创建OOMMF的多线程版本。通过编辑config/platforms/平台名称 中的oommf_threads值来构建非并行版本的OOMMF来改变此默认行为。
如果本机的Tcl和OOMMF都支持多线程，则还将显示Oxs求解器运行时的默认线程数。（此值可能因计算机中的处理器数量而异）可以修改config/options文件中oommf_thread_count和config/platforms/平台名称中thread_count值（按优先级增加的顺序），或者通过oxsii/boxsi命令行选项-threads来更改此值。
默认情况下，OOMMF对可以在oxsii或boxsi中运行的线程数没有设置上限。但是，如果运行的线程数超过可用的cpu内核数，则性能会降低。为了防止这种情况发生，或限制共享机器上的资源使用，可能希望对每个oxsii或boxsi实例的最大线程数设置一个限制。这可通过修改环境变量OOMMF_THREADLIMIT、config/platforms/平台名称中的thread_limit值或config/options的oommf_thread_limit值（按优先级增加的顺序）来实现。（注意，优先级顺序与默认线程数的顺序相反。）如果设置了线程数量限制，则该值将在oommf.tcl +platform命令后输出显示。
如果平台支持NUMA（请参阅“并行化”，2.3.4），oommf.tcl +platform命令将输出构建过程是否将创建支持NUMA的Oxs求解器。
在线程和NUMA信息之后oommf.tcl +platform命令将输出OOMMF软件用于写入临时文件所在的目录。例如，该目录用于将磁化数据从微磁求解器传输到显示模块mmDisp。因此必须具有此目录的写入权限，有足够的空间来管理模拟产生的数据流，该目录是执行计算的处理器的本地目录。如果不喜欢OOMMF的默认值，可以通过config/platforms/平台名称 中的path_directory_temporary值进行更改。或者可以设置环境变量OOMMF_TEMP，它将覆盖其他设置。
如果设置了与OOMMF相关的任何环境变量，则oommf.tcl +platform命令将在下一步显示这些信息，最后是关于安装Tcl/Tk可能出现的问题的一些警告，例如，如果您缺少重要的头文件。
如果oommf.tcl +platform命令输出显示Tcl/Tk安装存在问题，则为了简便建议重新安装Tcl/Tk。OOMMF最适合普通的Tcl/Tk安装选项。如果没有能力重新安装已损坏的现有Tcl/Tk（不是机器的系统管理员），则仍在自己的用户空间中安装自己的Tcl/Tk副本。在这种情况下，如果私有Tcl/Tk使用共享库，请注意在平台上执行有关的操作，以确保使用私有tclsh和wishfind和使用私有共享库，而不是来自系统的共享库。这可能涉及设置环境变量（例如Unix上的LD_LIBRARY_PATH或Windows上的PATH）。如果安装私有的Tcl/Tk，还需要确保没有像TCL_LIBRARY 或 TK_LIBRARY这样的环境变量仍然引用系统共有的Tcl/Tk。
Windows上的其他配置问题
应在Windows平台上检查一些额外配置。首先，注意Windows上的绝对文件名使用反斜杠（\）分隔目录名。在Unix和Tcl中，使用正斜杠（/）分隔目录名。在本手册中，通常使用Tcl约定的正斜杠的作为分隔符。在本手册中仅与MS Windows相关的部分中，使用反斜杠作为分隔符。本手册中的说明可能与Windows平台上的说明不完全相同。在Windows上工作时，可能需要将路径名中的正向斜杠替换为反斜杠。
OOMMF软件需要识别主机名localhost来得到网络支持。这可能需要编辑一个记录localhost环回接口（127.0.0.1）的文件。如果系统中存在文件名为hosts的主机（例如，C:\Windows\hosts），请确保它包含一个映射127.0.0.1到localhost的条目。如果不存在该文件，但hosts.sam文件存在，则可复制主机名称到hosts.sam的条目中。
存放tclsh和wish程序的目录还包含需要OOMMF软件查找才能正常运行的几个*.dll文件。通常OOMMF引导程序或mmLaunch负责确保找到必要的*.dll运行OOMMF软件。此外，将保存tclsh和wish程序的目录添加到PATH环境变量中，启动可执行文件时，会在该路径中的所有目录中搜索所需的*.dll文件。
2.2.4编译和链接。
如果下载了带有预编译可执行文件的发行版，可跳过本节。
当从源代码构建OOMMF软件时，请确保oommf.tcl +platform命令得到的C++编译器配置正确。特别是，如果在Windows系统上运行，请仔细阅读2.4.3高级安装章节中的说明。
OOMMF软件C++部分的编译和链接由程序pimake（16.20“跨平台相关”）完成。要开始使用pimake构建OOMMF软件，首先将工作目录更改为OOMMF的根目录：
cd…/path/to/oommf
如果将新的OOMMF解包到包含早期OOMMF版本的目录中时，使用pimake构建命令upgrade，以清除以前发行版中不属于最新版tclsh的任何源代码文件：
tclsh oommf.tcl pimake upgrade
接下来，构建命令distclean清除编译上一个发行版时遗留的旧可执行文件和对象文件：
tclsh oommf.tcl pimake distclean
接下来，要构建整个OOMMF软件，在不指定目标的情况下运行命令pimake：
tclsh oommf.tcl pimake
在某些平台上，如果正在运行OOMMF程序，则无法成功编译OOMMF。在尝试编译和链接OOMMF之前，请检查已有的OOMMF程序是否已终止（包括后台程序）。
当pimake命令引导编译器或其他软件生成程序时，会打印命令行，以便监视构建过程。若平台配置正确，pimake应能够编译和链接整个OOMMF软件而不会出错。如果pimake报告错误，首先查看手册里的故障排除是否已经记录了该问题。如果没有，请向OOMMF开发人员发送pimake和oommf.tcl +platform命令的完整输出邮件以寻求帮助。
2.2.5安装。
当前的OOMMF版本不需要安装。只需将解包/构建目录中的可执行文件运行即可。
2.2.6使用OOMMF软件。
使用OOMMF软件，需先运行OOMMF引导程序，这可从命令行界面启动：
tclsh oommf.tcl
也可以使用操作系统的图形化界面点击启动OOMMF引导程序oommf.tcl。默认情况下，OOMMF引导程序将在一个新窗口中启动OOMMF主程序mmLaunch。
如果发布借助OOMMF创建的文章，请参考开发人员获取引文信息。
2.2.7报告问题。
如果在安装或使用OOMMF时遇到问题，请向OOMMF开发人员报告。oommf.tcl+platform命令在很大程度上是为了帮助OOMMF开发人员调试问题而设计的，因此请确保在报告中包含oommf.tcl+platform命令的输出。另请参见故障排除部分获取更多说明。
2.3高级安装。
以下部分提供了一些安装时附加选项的说明。
2.3.1减少磁盘空间使用。
要从源代码中删除在构建OOMMF软件时创建的中间文件，使用pimake在OOMMF发行版的根目录中构建目标时使用objclean命令：
tclsh oommf.tcl pimake objclean
运行平台里的清理工具也在一定程度上减少OOMMF的大小。
2.3.2本地化。
OOMMF软件支持部分功能的本地自定义化。所有OOMMF程序都会加载config/local/options.tcl文件，它包含自定义命令和有关注释。config/options.tcl引导程序加载config/local/options.tcl。未来的OOMMF版本可能会覆盖config /options.tcl，故应通过复制config/options.tcl有关条目到config/local/options.tcl并修改。在config/local/options.tcl中建议只更改所需的自定义命令，其余项保持不变。删除其他额外选项，以便后续OOMMF版本的覆盖更改默认行为。
可用的本地自定义化包括选择主机服务目录程序的网络端口以及选择用于显示帮助文档的程序。OOMMF软件默认使用自带的mmHelp子程序，但帮助文档文件是标准的HTML，因此可以使用其他web浏览器。完整的说明见config/options.tcl文件。
2.3.3优化。
为了成功编译“无需安装，直接打开”的程序，OOMMF的默认配置很少有优化的方面。但在每个平台的配置文件中（例如，config/platforms/wintel.tcl)，可更改优化配置项。如果熟悉编译器的命令行选项，还可以尝试使用其他选项。可以编辑平台配置文件，用另一个提供更好计算性能的选项替换默认选项。例如，config/platforms/wintel.tcl中，可以通过编辑变量opts来调用MSVC++编译器的可选的方式，方法如下注释中的说明。
可扩展求解器Oxs可以通过支持大量运行时代码检查的调试进行编译，这将大大的降低计算性能。在标准OOMMF发行版中，应禁用这些检查，可以通过查找文件config /options.tcl中是否存在以下行来确认：
Oc_Option Add * Platform cflags {-def NDEBUG}
要启用检查，则需注释/删除此行，或者在config/local/options.tcl添加一个不带“-def NDEBUG”的“cflags”选项行，例如：
Oc_Option Add * Platform cflags {-warn 1}
若config/local/options.tcl文件不存在，则可以自己创建。
2.3.4并行化。
OOMMF 的Oxs 3D求解器（oxsii和boxsi）可以构建为支持多线程的，以实现在多处理器/多核机器上并行处理。为了构建和运行OOMMF的并行版本，Tcl的版本必须支持多线程。如今大多数的Tcl标准二进制版本都是支持多线程的，因此包含预构建可执行文件的OOMMF都是支持多线程的。如果从源代码构建OOMMF，那么默认情况下，如果Tcl是支持多线程的，OOMMF将被构建为支持多线程的。如前所述，可以使用oommf.tcl +platform命令输出tclsh线程状态。如果要强制构建非多线程的OOMMF，则需编辑config/platforms/平台名称 文件中标有LOCAL CONFIGURATION的部分，发现一行：
# $config SetValue oommf_threads 0
取消这行的注释（即删除“#”），以强制执行非多线程的构建。然后从OOMMF根目录运行以下命令来进行全新的构建：
tclsh oommf.tcl pimake distclean
tclsh oommf.tcl pimake
可以使用tclsh oommf.tcl +platform命令查看Oxs 3D求解器oxsii和boxsi将运行的默认线程数。可以按照2.2.3节平台配置修改默认值，或者在运行oxsii和boxsi时通过命令行选项-threads覆盖默认值。
一些有多个处理器的机器具有非统一内存结构（NUMA），这意味着尽管每个处理器都可以访问所有的系统内存，但比其他部分可以更快地访问内存的某些部分。通常，这是通过将系统内存和处理器划分为“节点”来实现的。节点内的内存访问比节点间的访问更快，并且根据架构，不同节点之间的访问延迟和带宽可能不同。使用NUMA的机器例如有AMD Opteron和Intel Xeon boxes。
OOMMF程序可以在支持NUMA的机器上运行，而无需特别考虑内存结构。然而，为了利用更快的本地（节点内）内存访问而编写的程序有时可以运行得更快。OOMMF包含了支持NUMA的代码，但此代码高度特定于操作系统。目前，OOMMF只能在Linux（32位和64位）系统上使用NUMA。而且必须安装操作系统NUMA支持包“numactl”和“numactl-devel”。支持包的名称可能有所不同，但第一个包通常包括可执行文件numactl，第二个包括头文件numa.h。安装numactl包后，可以运行命令：
numactl --hardware
获取机器上的内存结构。如果显示只有一个节点，那么构建一个支持NUMA的OOMMF是没有用的。
下一步是编辑config/platforms/平台名称 文件。例如，在64位Linux设备上，这个文件是config/platforms/Linux-x86 64.tcl。标有LOCAL CONFIGURATION的部分中，找到该行：
# $config SetValue use_numa 1
删除“#”字符或最好是创建一个具有相同平台名称的本地配置文件，如，在64位linux设备上创建config/platforms/local/linux-x86 64.tcl文件，在其中添加一行
$config SetValue use_numa 1
（使用config/platforms/localfile的优点是，可以在不修改原始OOMMF源代码的情况下进行更改，从而更容易将本地更改移植到OOMMF的未来版本中。）如果操作正确，那么tclsh oommf.tcl +platform命令将显示已启用NUMA支持。然后简单地运行tclsh oommf.tcl pimake distclean和Tclsh oommf.tcl pimake从OOMMF根目录构建一个支持NUMA的OOMMF。
OOMMF要打开NUMA，必须在oxsii/boxsi命令行上指定-numanodes，或设置OOMMF_NUMANODES环境变量。详细信息需查看Oxs文档。
2.3.5管理OOMMF平台名称。
OOMMF将为计算平台分配一个唯一的名称，该名称用作目录名以及索引和配置文件，因此安装的OOMMF可能包含许多平台相关的部分。
要了解OOMMF软件为计算平台指定的名称，请在OOMMF根目录运行命令：
tclsh oommf.tcl +platform
更改OOMMF分配给平台的名称
首先，使用pimake构建命令distclean以清除使用旧平台名称构建的任何已编译可执行文件：
tclshoommf.tclpimake distclean
然后，例如要将描述平台的名称从foo改为bar，只需重命名以下文件即可：
config/names/foo.tcl到config/names/bar.tcl
config/platforms/foo.tcl到config/platforms/bar.tcl.
重命名后，应使用新的平台名称重新编译可执行文件。
添加新的平台类型
如果oommf.tcl +platform命令报告显示的平台为unknown，那表示config/names/中的脚本无法识别该平台类型。若要将平台名称foo添加到OOMMF的平台名称库中，则需创建文件config/names/foo.tcl. 最简单的方法是复制config/names目录中的现有文件，并对其进行编辑以识别该平台。config/names中的文件包括如下Tcl代码：
Oc_Config New _ \
[string tolower [file rootname [file tail [info script]]]] {
# In this block place the body of a Tcl proc which returns 1
# if the machine on which the proc is executed is of the
# platform type identified by this file, and which returns 0
# otherwise.
#
# The usual Tcl language mechanism for discovering details
# about the machine on which the proc is running is to
# consult the global Tcl variable 'tcl_platform'. See the
# existing files for examples, or contact the OOMMF
# developers for further assistance.
}
创建新平台名称文件config/names/foo.tcl之后，还需要创建一个新的平台文件config/platforms/foo.tcl。最简单的方法是复制文件config/platforms/unknown.tcl用于编辑。
若有需要，考虑将自定义的新平台识别和配置文件提供给OOMMF开发人员，以便将其包含在OOMMF软件的未来版本中。
解决平台名称冲突
如果oommf.tcl +platform命令输出显示“Multiple platform names are compatible with your computer”，而且对于config/names/目录中有多个文件在都是返回1。对于输出显示的每个兼容平台名称，需要在config/names/中编辑相应的文件，保证使其中只有一个返回1。使用tclsh来检测tcl_platform，若失败，可通过匹配计算平台的主机名，显式地分配与计算平台对应的平台类型。例如，如果计算机的主机名为foo.bar.net:
Oc_Config New _ \
[string tolower [file rootname [file tail [info script]]]] {
if {[string match foo.bar.net [info hostname]]} {
return 1
}
# Continue with other tests...
}
如需进一步帮助，请联系OOMMF开发人员。
2.4平台特定安装问题。
前几节讨论的安装过程适用于所有平台（Unix、Windows、Mac OS X）。然而，下面将讨论这些只适用于特定的平台的问题。
2.4.1 Unix配置。
缺少Tcl/TK文件
前面讲的基本安装过程应足以在大多数Unix系统上安装OOMMF。但有时，由于缺少Tcl头文件（tcl.h、tk.h）或库（libtcl.so, libtk.so)，这个问题可通过安装Tcl/Tk的“开发”版本来解决，该版本可以在操作系统安装盘上找到，也可以从系统供应商处获得。ActiveState还为许多系统提供了二进制版本的Tcl/Tk，名为ActiveTcl。或者，可以从Tcl Developer Xchange下载Tcl和Tk的源代码，并从源代码构建和安装Tcl/Tk。Tcl/Tk构建遵循Unix通常的configure, make, make install构建。
编译器优化选项
在大多数系统上，OOMMF的构建默认很少使用编译器的优化选项。如前所述（2.3.3 “优化”），可以编辑相应的oommf/config/platforms/的文件来更改默认编译选项。然而，在一些常见系统（例如Linux、一些BSD变体）上，OOMMF将尝试推断硬件体系结构（即CPU子类型，如Pentium3和Pentium4），并将特定于体系结构的选项应用于编译命令，这适用于OOMMF只在构建它的系统上运行，或者在同构架上运行的情况。相反，如果在异构架上运行OOMMF，则需要将编译器选项限制为目标计算机上支持的选项。在这种情况下，在oommf/config/platforms/目录中打开相应的配置文件，并查找以下行：
# You can override the GuessCPU results by directly setting or
# unsetting the cpuopts variable, e.g.,
#
# set cpuopts [list -march=athlon]
# or
# unset cpuopts
#
取消对“unset cpuopts”行的注释以生成通用的构建流程，或者将“set cpuopts”行修改为公共构架，并取消对该行的注释。
一些编译器支持“-fast”选项，它通常创建特定构架的可执行文件，这种情况也是类似地。
有一个高级的方案是为公共构架中的每个CPU子类型定义单独的OOMMF“平台”，这需要在oommf/config/names/目录中为每个子类型创建单独的平台名称文件，然后为每个新平台复制相应的oommf/config/platforms文件。注意，必须要有平台名称文件，才能可靠地检测每台机器上的CPU子类型。请参阅“管理OOMMF平台名称”（2.3.5）获取有关创建平台名称文件的帮助。
Linux的编译器Portland Group pgCC
在Linux平台上构建时，oommf/config/platforms/lintel.tcl (32-bit) 和oommf/config/platforms/linux-x86 64.tcl包含支持Portland Group pgCC编译器的部分。使用此编译器构建的非多线程OOMMF运行良好，但构建的多线程版本在运行Oxsii/Boxsi时有故障，目前尚不清楚这个问题的根源。
2.4.2 Mac OS X配置。
Mac OS X的构建过程与Unix相同，但它的平台名称为darwin。如果检查平台配置时找不到C++编译器，则必须安装一个，如苹果提供的Xcode命令行开发工具。可以通过命令：
xcode select—install
从终端窗口安装该工具，即使已经安装了完整的Xcode IDE，也应该运行此命令。有关详细信息，请参阅系统文档。
2.4.3 Microsoft Windows选项。
本节列出Windows的安装事项。
使用Microsoft Visual C++
如果使用Microsoft Visual C++的cl.exe工具从源代码构建OOMMF软件，在运行编译器之前，需要设置路径和一些环境变量，可运行Visual C++的批处理工具来实现这一点。该工具的名称在不同的Visual C++版本中有所不同，例如vcvarsall.bat或者setenv.cmd. 对于64位版本，需要在批处理工具命令行中包含“amd64”选项。配置系统以便在打开命令窗口时自动运行批处理工具。有关详细信息，请参阅编译器和系统文档。
使用MinGW g++
g++的MinGW支持32位和64位版本。（32位和64位版本的g++是单独下载的。）使用标准的Windows Tcl/Tk工具，例如ActiveState的ActiveTcl软件，编辑相关的平台文件，以选择g++作为编译器，若使用的是32位Tcl/Tk和g++，那么平台文件是oommf\config\platforms\wintel.tcl. 对于64位Tcl/Tk和g++来说，平台文件是oommf\config\platforms\windows-x86 64.Tcl。
使用Cygwin工具包
Cygwin 是Windows免费的开发环境，其中包括GNU C++编译器g++和X11。要在Cygwin中构建OOMMF，需启动Cygwin或Cygwin64 shell程序，并按照普通的Unix构建流程即可。根据运行的是32位还是64位Cygwin tclsh，选择的分别为cygtel或cygwin-x86 64，由此构建的OOMMF需要Cygwin环境才能运行，因此需要从Cygwin shell启动OOMMF。此外，Cygwin上的OOMMF使用X11作为窗口接口，因此需要安装X11；通常，OOMMF将从X11 xterm或同等版本启动。当然，还需要安装Tcl和Tk软件包（在Cygwin包管理器中分别为tcl和tcl_tk）。要从源代码构建OOMMF，需要gcc-g++、tcl-devel和tcl-tk-devel包和依赖项。
如果收到错误消息，显示无法复制子进程（通常带有“资源暂时不可用”或“加载到其他地址”错误消息），请执行以下过程：
1。退出所有Cygwin进程
2。使用Windows资源管理器或Windows命令行程序启动c:\cygwin\bin\ash.exe
3。在ash.exe内运行/bin/rebaseall。
关于这个问题的更多信息见Cygwin文档。
Cygwin的Tcl/Tk8.6之前的版本不支持多线程，因此用Tcl/Tk 8.5和更早版本构建的OOMMF同样不支持多线程。Cygwin的Tcl/Tk 8.6版本解决了这一限制。
使用Borland C++
开发人员已经使用过Borland C++编译器5.5版本成功构建和测试OOMMF，在用这个编译器构建OOMMF之前，有几个准备步骤：
1完成bcc55编译器的正确安装。
阅读Borland安装目录下BCC55子目录中的readme.txt文件，特别检查BIN子目录中是否存在bcc32.cfg和ilink32.cfg配置文件，并检查其内容是否适当。如果省略这一步，在OOMMF构建过程中会收到与Borland编译器无法找到系统头文件和库有关的错误消息。可能还需要将Borland BIN目录添加到PATH环境变量中。一些Borland的工具在其路径名中的空格很敏感，于是其Borland安装目录路径名中应没有空格（例如，使用C:\Borland\而不是“C:\Program Files\Borland\”），或者至少在设置路径时，使用每个组件的“8dot3”样式的短名称，例如：
PATH=C:\Progra~1\Borland\BCC55\Bin；%PATH%
使用“dir/x”显示短和长的文件名。安装Borland Developer Studio 2006时会自动设置包含Borland BIN目录的长名称的路径；可以通过控制面板上的系统对话框手动更改此路径。选择“高级”选项卡，然后打开“环境变量”子对话框。如上所述编辑路径变量；检查“用户变量”和“系统变量”设置。
2创建与Borland兼容的Tcl和Tk库。
与Tcl/Tk8.0.3版及更高版本一起分发的导入库与Borland C++链接器不兼容。但与Borland编译器一起分发命令行程序coff2omf，可用于创建合适的Tcl/Tk库。在Tcl/Tk库目录中（通常为C:\Tcl\lib或“C:\Program Files\Tcl\lib”）指定以下命令：
coff2omf tcl84.lib tcl84bc.lib
coff2omf tk84.lib tk84bc.lib
这里的tcl84.lib和tk84.lib是输入库（COFF格式）和tcl84bc.lib和tk84bc.lib是新的合适的库（OMF格式）。如果coff2omf不起作用，可以尝试直接从Tcl/Tk 动态链接库创建必要的导入库。在Tcl/Tk库目录中指定以下命令：
impdef-a tcl84bc.def..\bin\tcl84.dll
implib tcl84bc.libtcl84bc.def
这将创建与Borland兼容的导入库tcl84bc.lib，用“tk”代替“tcl”创建tk84bc.lib，“-a”参数要求impdef在函数名前添加下划线。这对于Tcl/Tk 8.4附带的DLL来说已经足够了，但其他版本可能需要进行额外的调整。Impdef命令输出的模块定义文件，如tcl84bc.def是一个普通的文本文件。需要编辑此文件以添加或修改条目。
3编辑oommf\config\platforms\wintel.tcl
必须更改program_compiler_c++值以指向Borland c++编译器。wintel.tcl文件里默认tlib和链接器ilink32位于执行路径中，并且Borland兼容的导入库（名称如上所述）位于Tcl/Tk库目录中。如果情况并非如此，则必须进行适当的修改。此外，可能需要在linker命令中添加“-o”参数，以强制使用在上一步中生成的与Borland兼容的Tcl/Tk库。之后，继续执行第2.2.4编译和链接中的说明。
使用Digital Mars C++
要使用Digital Mars C++（dmc）进行编译，请按照以下说明进行操作：
1安装Digital Mars C++编译器、工具和STL。
将下载的dmc文件解压缩到一个合适的位置。dmc安装根目录的默认名称为“dm”。将STLport（C++标准库）解压缩到dmc安装路径。STLport文件中的顶级目录是“dm”，如果将此文件解压到dmc安装根目录，它的各个文件将放在其适当位置。然后修改dmc配置以包含STL头文件。编辑dm\bin\sc.ini文件，以便包含路径的第一个元素为“%@P%\..\stlport\stlport”；接下来，从DOS命令提示符使用“set-INCLUDE”和“set-LIBRARY”命令检查这些环境变量是否设置（其他程序可能会使用这些变量名称，这将与dmc预期的值冲突），使用命令“set INCLUDE=”和“set LIBRARY=”取消设置这些变量，为方便起见，可将dm\bin目录放入环境PATH变量中。
2创建兼容的Tcl/Tk导入库。
Digital Mars链接器与Borland链接器使用相同的库格式，在这种情况下，必须为Tcl/Tk库构建兼容的导入库。Digital Mars提供的“基本程序”工具包括可用于此的implib。或者，可以使用Borland工具。有关详细信息，请参阅上面关于使用Borland C++的部分。
3编辑oommf\config\platforms\wintel.tcl.
需要取消dmc编译器条目的注释，并注释掉其他编译器选项。（注释字符为“#”）。配置文件假定dmc编译器和相关工具位于环境变量PATH包含的目录中。之后，参考2.2.4编译和链接中的说明。
设置TCL_LIBRARY环境变量
如果在OOMMF启动过程中遇到问题，可能需要设置环境变量TCL_LIBRARY。（注意：这几乎很少用到！）打开控制面板（例如，从“开始”菜单中选择设置|控制面板），然后选择系统。转到环境变量选项卡，输入TCL_LIBRARY作为变量，其值为包含init.tcl的目录，例如：
%SystemDrive%\Program Files\Tcl\lib\Tc8.0
单击设置并确定完成。
3 快速入门： OOMMF示例
第1步：启动mmLaunch。
•在OOMMF根目录下使用命令：
tclsh oommf.tcl
（此处tclsh的名称可能因系统而异，这在2.1中说过。）或者，可以使用操作系统提供的图形化操作界面启动oommf.tcl。
•这将弹出一个以后台模式存在，名为mmLaunch的程序，在mmLaunch的程序窗口出现之前，将在原始窗口中额外显示一些提示信息。
第2步：打开其他的程序窗口。
•在mmLaunch程序窗口中，选中主机的复选框（可能是唯一可用的选项），会出现一个用户帐户选项框，勾选与本机帐户对应的复选框（也很可能只有一个选项可用），接着会出现一个列出其他程序的选项菜单，程序名称及作用如下：
–mmArchive:自动保存标量和矢量场数据
–mmDataTable:显示标量输出的当前值
–mmDisp:显示矢量场
–mmGraph:形成x-y图
–mmProbEd:查看或修改mmSolve2D或Oxsii所用到的微磁问题描述文件
–mmSolve2D: 2D求解器
–Oxsii: 3D求解器
•根据想要查看的输出数据的显示形式,可以选择mmDisp、mmGraph、mmDataTable， mmArchive可以将数据保存到磁盘。
第3a步：运行mmSolve2D程序计算微磁问题。
加载微磁问题文件：
•在mmLaunch程序窗口中，单击mmProbEd按钮。
•在mmProbEd程序窗口中，单击菜单栏中的 File|Open ，将出现打开文件对话框窗口。在此窗口中：
–双击 Path 选项框以更改目录。在目录oommf/app/mmpe/examples中可以找到几个微磁问题示例程序。
–双击Filter选项框上方列表中的*.mif文件（如prob1.mif）加载微磁问题文件。
•用户可以这样定义一个全新的微磁问题文件：点击mmProbEd窗口中的按钮（如，材料参数），根据需要修改微磁问题文件，并填写弹出的表单。
•如果需要，可以通过 File|Save as 将自定义的问题文件存储到磁盘。
初始化求解器：
•在mmLaunch程序窗口中，单击mmSolve2D按钮以启动mmSolve2D的实例程序。
•等待新的求解器实例出现在mmLaunch窗口的 Threads 列中。
•选中 Threads 列中mmSolve2D旁边的复选框，将出现一个包含mmSolve2D程序界面的窗口。
•在mmSolve2D窗口中：
–检查 Inputs 下的 Problem Description （问题描述文件）。
–检查 Source Threads （问题源的线程）下的 mmProbEd 。
–点击 LoadProblem （加载问题）。
–状态行会显示正在加载问题文件。
–当问题完全加载时，会出现更多的按钮。
–检查 Scheduled Outputs （输出项）。
–对于每个所需的输出（TotalField（总磁场）、Magnetization（磁化过程）和DataTable（数据表），可以指定输出数据的更新频率：
1检查所需的输出。这将在目标线程列表显示输出目标，输出目标程序（如mmDisp、mmGraph和mmDataTable）必须正在运行才能显示在此列表中。
2选中所需目标线程旁边的复选框将展示计划输出表。
3设置计划输出表：
*Iteration（迭代）：填写数字并勾选该框。
*ControlPoint（控制点）：填写数字并勾选该框。
* Interactive（交互）：点击相应的交互按钮可以控制输出过程。
开始计算：
•在mmSolve2D程序窗口中，使用Run（运行到问题完成）或Relax（运行到下一个控制点）来开始计算微磁问题。
•选择mmDataTable输出的数据，点击mmDataTable上菜单栏中 Data，会显示所需的输出数据列表。
•同样，点击菜单栏中X、Y1和Y2，可以设置mmGraph上显示的坐标图的X、Y1和Y2。
保存和显示结果：
•可以使用mmDisp查看矢量场数据（磁化过程和有效场）。使用mmDisp窗口的File|Save as保存结果。可以将计划输出的数据发送到mmArchive程序用于自动存储。例如，要在每个控制点后面保存磁化状态，可以在开始计算之前，启动一个mmArchive程序实例，并在求解器的输出计划Magnetization磁化输出中为mmArchive选项选择ControlPoint输出。（控制点是模拟过程中磁场步进的节点，通常是磁化过程到达了平衡状态，但也取决于输入*.mif文件规定的经过的模拟时间或迭代次数）
•可以通过设置计划输出表，将表格数据从求解器发送到mmArchive来保存，mmArchive会自动保存所有接收到的数据。或者，可使用mmGraph保存部分数据：根据需要在计划输出表中选择mmGraph，并使用mmGraph的手动或自动保存功能。在开始计算之前设置求解器输出数据的处理，配置mmGraph之后必须等待得到第一个数据，然后才能保存以后的数据。可以通过手动地向mmGraph发送求解器初始输出数据来配置mmGraph，然后使用mmGraph菜单项中的Options|clear Data（选项|清除数据）删除该初始化数据。如果要得到正确的数值，则使用以表格格式显示单个输出数据的mmDataTable，但mmDataTable没有数据保存功能。
过程控制：
•在mmSolve2D程序窗口中，有以下按钮：
–Reset：返回到微磁问题文件的开始位置。
–LoadProblem：重新加载微磁问题文件。
–Run：施加一系列场并开始计算，直到问题求解全部完成。
–Relax：在当前施加的场上开始计算，直到到达下一个控制点为止。
–Pause：随时单击以停止求解器。使用Run或Relax从暂停点继续模拟。
–Field -：再次使用上一个场来计算。
–Field +：使用列表中的下一个场来计算。
•可以更改计划输出选项并打开新的输出窗口。
•当达到最后一个控制点的停止标准时，mmSolve2D将暂停，并允许用户以手动方式输出最终结果。
步骤3b：计算3D微磁问题。
启动求解器：
•在mmLaunch程序窗口中，单击Oxsii按钮以启动Oxsii的程序实例。
•等待新的求解器实例出现在mmLaunch窗口的Threads列中。
•选中Threads列中Oxsii条目旁边的复选框，并出现一个Oxsii的程序窗口。
加载微磁问题文件：
•在Oxsii程序窗口中，选择File|Load，将出现加载微磁问题文件的窗口。在此窗口：
–双击Path框以更改目录。在oommf/app/oxs/examples目录中可以找到几个示例。
–若要加载微磁问题文件，双击Filter框上方列表中的*.mif文件（如stdprob1.mif）。
3D求解器的输入文件格式是MIF 2.1，必须使用纯文本编辑器编写。但是，Oxsii可以读取MIF 1.1格式的文件，也可以使用命令行工具mifconvert将文件从MIF 1.1格式转换为MIF 2.1。mmProbEd还支持MIF 1.1扩展格式MIF 1.2，该格式提供有限的3D功能。Oxsii也可以直接读取MIF 1.2文件，要在Oxsii中运行由mmProbEd程序创建的微磁问题文件，mmProbEd必须首先通过File|Save as.将问题文件保存到磁盘。
•Oxsii界面窗口中的状态行将显示微磁问题文件正在加载。
•当微磁问题文件加载完成时，状态行将显示“暂停”，并将激活最上面一行按钮（Reload, Reset等）。此外，输出列表将显示可用的输出。
•设置计划输出。对于每个所需的输出
1从输出列表中选择输出数据源。
2从输出目的地列表中选择接收者。
3指定数据获取频率：
–Step（步进）：填写数字并勾选该框。
–Stage（阶段）：填写数字并勾选该框。
根据加载的微磁问题文件，输出列表中的可用的输出项会有所不同。输出目的地列表中的项目显示当前正在运行的数据显示和存储程序。
开始计算：
•在Oxsii窗口中，点击Run、Relax或Step开始计算。
•如果输出目的地选择mmDataTable，在mmDataTable菜单下的Data选中所需数据的复选框，以便显示接收的数据并开始更新。
•同样，也可以设置在mmGraph菜单上的X、Y1和Y2。
保存和显示结果：
•可以使用mmDisp查看矢量场数据（磁化过程和有效场）。使用mmDisp窗口的File|Save as保存结果。可以将计划输出的数据发送到mmArchive程序用于自动存储。例如，要在每个阶段后面保存磁化状态，可以在开始计算之前，启动一个mmArchive程序实例，并在求解器的输出计划Magnetization磁化输出中为mmArchive选项选择Stage输出。（Stage是求解问题的模拟过程中重要的节点，通常是磁化过程到达了平衡状态或到达预设模拟时间，取决于MIF文件）
•可以通过设置计划输出表，将表格数据从求解器发送到mmArchive来保存，mmArchive会自动保存所有接收到的数据。或者，可使用mmGraph保存部分数据：根据需要在计划输出表中选择mmGraph，并使用mmGraph的手动或自动保存功能。在开始计算之前设置求解器输出数据的处理，配置mmGraph之后必须等待得到第一个数据，然后才能保存以后的数据。可以通过手动地向mmGraph发送求解器初始输出数据来配置mmGraph，然后使用mmGraph菜单项中的Options|clear Data（选项|清除数据）删除该初始化数据。如果要得到正确的数值，则使用以表格格式显示单个输出数据的mmDataTable，但mmDataTable没有数据保存功能。
过程控制：
•在Oxsii窗口中，有以下停止和重新启动计算的按钮：
–Reload：从磁盘重新加载微磁问题文件。
–Reset：返回到微磁问题文件开始位置。
–Run：开始计算，逐步完成所有阶段，直到全部阶段完成。
–Relax：开始计算直到满足当前阶段的终止标准。
–Step：求解器迭代一次，然后暂停。
–Pause：随时单击以停止求解器。使用Run、Relax或Step从暂停点继续模拟。
–Stage：通过在Stage输入框中键入所需的阶段数字（从0开始）或移动相关滑块，以手动方式更改当前阶段数。
•可以更改计划输出选项并打开新的输出窗口。可以通过Oxsii的计划输出窗口中的Send按钮以手动方式将输出数据发送到指定目的地。
•当满足最后一个阶段的终止（停止）标准时，Oxsii将暂停，以允许用户通过手动方式点击Send按钮输出最终结果。
在满足最后一个阶段的终止标准时，批处理接口Boxsi会自动终止。
第4步：退出OOMMF。
•通过从窗口界面选择File|Exit（文件|退出），可以关闭OOMMF所有程序的窗口界面。
•选择mmLaunch窗口的File|Exit（文件|退出），将关闭mmLaunch窗口界面，以及运行中的mmArchive、mmSolve2D和Oxsii程序的窗口界面。但是，这些程序将继续在后台运行，但可通过启动新的mmLaunch程序实例来重新显示它们的窗口界面。
•若要彻底终止OOMMF所有的程序，需从mmLaunch的菜单栏中选择File|Exit all OOMMF选项。
4 OOMMF架构概述
在介绍构成OOMMF软件的每个程序之前，需了解这些程序是如何协同工作的。OOMMF不是一个单独的程序，相反，它是一个程序集合，每个程序都专门处理微磁模拟系统所需的某些任务。这种模块化体系结构的一个优点是，每个程序都可以改进甚至替换，而无需重新设计整个系统。
OOMMF的子程序通过相互提供服务而协同工作。这些程序即使在同一台主机上运行，但也通过Internet（TCP/IP）连接进行通信。该设计的一个优点是，在基本设计中支持在联网的主机上对OOMMF子程序进行分布式操作，但在目前版本中没有完全实现。
当两个OOMMF子程序处于一个向另一个请求服务时，这里引入一些明确的术语。将提供服务的子程序称为“服务器程序”，将请求服务的子程序称为“客户端程序”。请注意，单个子程序既可以是一个服务关系中的服务器程序，也可以是另一个服务关系中的客户端程序。
每个服务器程序都在特定的Internet端口上提供服务，并且需要通知潜在的客户端程序如何获得其服务。每个客户端程序都需要能够查找其所需服务的可能提供者。将服务器程序和客户端程序结合在一起的中间层是另一个名为“帐户服务目录”的程序。主机上每个用户帐户的ID下最多只能运行一个帐户服务目录程序，每个帐户服务目录都会跟踪在其主机上以其用户帐户运行的OOMMF服务器程序提供的所有服务，以及可以获取这些服务的相应Internet端口。OOMMF服务器程序向相应的帐户服务目录程序注册其服务，OOMMF客户端程序在相应的帐户服务目录程序中查找在特定用户ID下运行的服务提供者。
帐户服务目录程序简化了匹配服务器和客户端的问题，但并不能完全解决该问题，OOMMF的子程序仍然需要一种机制来确定如何获得帐户服务目录的服务！另一个名为“主机服务目录”的程序提供此功能，每个主机上只运行主机服务目录程序的一个副本，它的唯一目的是告诉OOMMF的子程序在何处获得该主机上帐户服务目录的服务。因为每个主机只运行一个副本，所以它可以在配置到OOMMF软件中的已知端口上提供服务，默认情况下，这是端口是15136。OOMMF软件可以自定义使用不同的端口号。
帐户服务目录程序也执行另一项任务，能根据用户ID启动其他程序，为其管理服务的注册。用户通过子程序mmLaunch提供的界面控制其他程序的启动，但实际上是帐户服务目录程序为新程序生成了一个子进程。由于这种架构，大多数OOMMF子程序都是作为帐户服务目录程序的子进程启动的，这些子进程从其父帐户服务目录程序继承其环境，包括其工作目录和其他关键环境变量，如DISPLAY。每个帐户服务目录程序将其工作目录设置为OOMMF的安装根目录。
这些服务目录程序对整个OOMMF微磁模拟系统的运行至关重要，然而用户很容易忽视它们，它们完全是“后台”操作，没有用户窗口界面，此外，它们不是由用户启动的。当任何服务器程序需要注册其服务时，如果发现这些服务目录程序没有运行，则会启动它们新的副本。通过这种方式，用户可以确保如果有任何OOMMF服务器程序正在运行，那么服务目录程序会引导客户端程序到找到其所需的服务。所有服务器程序终止后，服务目录程序不再注册任何服务，它也会终止。类似地，当所有服务目录程序终止时，主机服务目录程序也会终止。
在接下来的章节中，将从OOMMF子程序提供的服务和所需的服务两个方面对其进行描述。
5 命令行启动
OOMMF一些子程序是独立于平台的Tcl脚本程序，需要依赖于平台的特殊的解释器，其他的则是依赖平台的C++编译程序，这种情况可能会在OOMMF的后续版本中改变。每种类型的程序都需要不同的命令行来启动，但OOMMF用户的启动操作无需这么复杂，OOMMF提供了一组启动程序，为启动OOMMF程序提供简化的界面。
用于从命令行启动OOMMF的第一个程序，它的功能只是启动其他程序，所以把这个程序称为“引导程序”。引导程序就是Tcl脚本oommf.tcl. 在最简单的用法里，它需要在命令行上使用一个参数，即要启动的程序的名称，例如，启动mmGraph，命令行是：
tclsh oommf.tcl mmGraph
这里命令中的程序名称不区分大小写。（与本文档中的其他地方一样，这里假定当前工作目录为OOMMF根目录。对于其他情况，请将路径名调整为oommf.tcl所在的目录。）如第2.1节所述，Tcl shell程序的名称（此处为tclsh）可能因系统而异。
如果没有向引导程序传递任何参数，默认情况下，它将启动mmLaunch程序。引导程序的任何以“+”开头的命令行参数都会改变此行为。有关引导程序识别的所有命令行参数选项的摘要，运行：
tclsh oommf.tcl+help
命令行参数+bg和+fg控制启动请求的程序后引导程序的行为，它可以在后台模式（+bg）下启动请求的程序后立即退出，也可以直到启动的程序退出（+fg）才退出。无论程序在前台还是后台模式下启动，都会在OOMMF系统中注册。如果命令行上没有参数，引导程序将以其首选模式启动请求的程序。
命令第一个参数不以+开头，表示启动哪个程序。如上所述，这通常是程序的简单名称，但当需要启动特定版本的程序时，引导程序允许用户将特定版本作为命令参数的一部分。例如：
tclsh oommf.tcl“mmGraph 1.1”
这将保证其启动mmGraph的程序实例至少为1.1版本，若找不到满足版本要求的mmGraph，则会报错。
引导程序无法识别的其余命令参数将作为参数传递给启动的程序，由于引导程序识别以+开头的命令行参数，而大多数其他程序识别以-开头的命令行参数，因此，可以避免混淆对于哪些选项可以提供给哪些程序。例如：
tclsh oommf.tcl +help mmGraph
打印有关引导程序的帮助信息，而不启动mmGraph。然而：
tclsh oommf.tcl mmGraph -help
将使用命令参数-help启动mmGraph，然后，mmGraph会显示自己的帮助信息。大多数OOMMF子程序都接受下面列出的标准命令参数。一些OOMMF子程序在从命令行启动时接受附加命令参数，如本手册相应章节所述。-help命令行参数可用于查看完整的可用命令参数列表。当参数指定为<0 | 1>时，0通常表示关闭、否或禁用，1表示打开、是或启用。
-console显示一个控制台，可以在程序的控制台中以手动方式键入Tcl命令，用于调试。
-cwd directory设置程序的当前工作目录。
-help显示帮助信息。
-nickname
-tk<0 | 1>禁用或启用Tk。必须启用Tk，程序才能显示界面窗口。但是，当在Unix平台上启用Tk时，程序运行依赖X Windows服务，如果X Windows服务停止运行，它将结束运行的程序。不需要界面窗口的程序支持使用-tk 0禁用Tk，其他必须使用界面窗口的程序不能用-tk 0，要在没有显示界面的Unix系统上运行需要界面窗口的程序，则可以利用Xvfb。
-version显示程序的版本信息。
此外，那些启用Tk的程序接受额外的Tk命令参数，例如-display。有关详细信息，请参阅Tk文档。
大多数用户应该很少使用引导程序。mmLaunch为启动其他子程序提供了更方便的图形界面，引导程序的主要用途是启动mmLaunch、启动pimake、启动组成OOMMF批处理系统的程序和其他需要命令行驱动的程序，以及在用户要精确控制传递给OOMMF子程序或OOMMF运行环境的命令参数的情况下。
平台问题
Unix平台上，如果oommf.tcl显示为可执行，则可以不指定tclsh直接运行。这是因为oommf.tcl的有几行Tcl脚本是：
#！/bin/sh
#\
exec tclsh“$0”${1+“$@”}
运行时，调用执行路径上的第一个tclsh来解释oommf.tcl脚本，如果计算机上的Tcl shell程序无法通过tclsh调用，则需编辑oommf.tcl文件以使用正确的名称。更好的方法是使用符号链接或其他方式，将Tcl shell程序设置为tclsh。后一种解决方案不会因OOMMF升级中的文件覆盖而失效。
此外，如果目录…/path/to/oommf位于执行路径中，在任何目录中都可以使用的如下所示的命令启动程序：
oommf.tcl appName
在Windows平台上，oommf.tcl具有.tcl文件扩展名，所以它通常由Windows的wish解释器关联。这个oommf.tcl脚本是特别编写的，因此tclsh或wish都是合适的解释器。这意味着（例如，在Windows资源管理器中）只需双击与该文件关联的oommf.tcl的图标将无参数启动引导程序，这将用默认方式启动程序mmLaunch，适用于启动其他OOMMF子程序。（如果失效，请参阅安装说明第2.4.3节)
6 OOMMF启动/控制器界面：mmLaunch
概述
mmLaunch启动、监视和控制其他OOMMF子程序，OOMMF子程序与后台运行的帐户服务目录和主机服务目录程序的连接最为紧密，它还为其他子程序提供控制界面，尤其是Oxsii和mmSolve2D。
启动
mmLaunch应使用引导程序启动，使用命令：
tclsh oommf.tcl mmLaunch [standard options]
控制
打开mmLaunch程序后，会显示一个按钮面板，对应于它所连接的主机服务目录。在当前OOMMF版本中，只有一个以运行mmLaunch的主机命名的复选框。如果启动mmLaunch时本地主机上没有运行主机服务目录，mmLaunch将启动一个，在这种情况下，选中主机命名的复选框可能会有一些延迟。
切换主机复选框可显示对应的主机服务目录界面。主机服务目录界面由一行复选框组成，在主机服务目录中注册的每个帐户服务目录对应一个复选框，每个复选框都标有相应的用户ID。对于大多数用户，只有一个复选框，标有用户自己的帐户ID。如果启动mmLaunch的帐户没有运行帐户服务目录，mmLaunch将启动一个。在这种情况下，帐户检查按钮出现之前可能会有一些延迟。
切换帐户复选框将切换到相应的帐户服务目录显示界面。帐户服务目录界面由两列组成，Programs（程序）列包含标有OOMMF子程序名称的按钮，这些子程序可能会在该帐户服务目录管理下启动，单击其中一个按钮将启动相应的程序。尽管在启动的程序向用户显示窗口之前会有一些延迟，只需单击一次即可，多次单击将启动该程序的多个副本。注意：实际上是由帐户服务目录程序启动的，并初始工作目录设置为OOMMF根目录。
Threads（线程）列是当前在帐户服务目录下运行的所有OOMMF子程序的列表。该列表包括程序名称和一个ID号，通过该ID号可以区分同一程序的多个副本，该ID号也显示在相应程序界面窗口的标题栏中，当程序退出时，该程序副本将自动从线程列表中删除。
任何正在运行的，不提供界面窗口的程序都将显示在线程列表中，并带有一个复选框。选中复选框可以打开代表该程序提供的界面显示，使用此服务的OOMMF子程序有3D求解器Oxsii和Boxsi，2D求解器mmSolve2D和batchsolve，以及存储程序mmArchive。
菜单栏的File|Exit将停止mmLaunch程序，File| Exit All OOMMF将终止Threads列表中的所有程序，然后退出mmLaunch，Help提供了常用的帮助信息。