如果您的系统 Tcl / Tk 安装是非线程的，那么您可以创建一个非线程版本的 OOMMF， 否则您可以在您的主目录或/ usr / local 下创建一个额外的，线程化的 Tcl / Tk 安装。 请 注意，如果您的系统上安装了多个 Tcl / Tk 安装，则无论何时您构建或启动 OOMMF， 都需要小心使用正确的 tclsh Parallelization OOMMF Oxs 3D 解算器（oxsii amd boxsi）可以构建线程，以允许在多处理器/ 多核机器上并行处理。 为了构建和运行一个并行版本的 OOMMF，你必须有一 个启用线程的 Tcl 版本。目前 Tcl 的大多数标准二进制发行版都是启用了线程的， 所以包含预先构建的可执行文件的 OOMMF 版本都是构建了线程启用的。 如果 您从源代码构建 OOMMF，那么默认情况下，如果您的 Tcl 是启用线程的，则将 构建线程启用的 OOMMF。 如前所述，您可以使用 tclsh oommf.tcl + platform 命 令检查线程构建状态。 如果你想强制非线程构建 OOMMF，那么编辑你的平台的 config / platforms /文件。 在标签为 LOCAL CONFIGURATION 的部分，您会看到一条如下所示的行： # $config SetValue oommf_threads 0 一些多处理器机器具有不统一的内存架构（NUMA），这意味着虽然每个处理器 都可以访问所有的系统内存，但某些内存部分可以比其他部分更快地访问。 通 常情况下，这是通过将系统内存和处理器划分为\节点来完成的。“节点内的内存 访问比节点间的访问更快，并且取决于体系结构，不同节点对之间的访问延迟和 带宽可能不同。 包括一些多处理器 AMD Opteron 和 Intel Xeon 处理器。 以下示例产生频率为 1 GHz，幅度为 800 A / m 的正弦变化场： proc SineField { total_time } { set PI [expr {4*atan(1.)}] set Amp 800.0 set Freq [expr {1e9*(2*$PI)}] set Hx [expr {$Amp*sin($Freq*$total_time)}] set dHx [expr {$Amp*$Freq*cos($Freq*$total_time)}] return [list $Hx 0 0 $dHx 0 0] } Specify Oxs_ScriptUZeeman { script_args total_time script SineField } Drivers 当 evolvers（第 7.3.4 节）负责将仿真向前移动时，drivers 通过将仿真步骤分为 任务，阶段和运行来协调整个仿真过程的行为。Oxs 中有两个驱动程序，Oxs TimeDriver 用于控制时间演化程序，如 RunxKuttaEvolve，Oxs MinDriver 用于控制 OxsCGEvolve 等最小化演化程序。 The stopping dm/dt：指定当所有自旋上的最大值|dm/dt|降至此值以下时，应认 为该阶段已完成。对于准静态模拟，dm/dt 在 0.01-1 比较合理，为了计算精确的 

能量，要使精度低于 0.001 stopping time:每一步最大的模拟时间 Oxs TimeDriver 提供 12 个标量输出和两个向量场输出，标量场输出如下： Stage: 目前的阶段数（从 0 开始） Stage iteration:当前阶段成功运行的进动数 Iteration:在这个模拟中成功运行的进动步数 Simulation time:总的模拟时间 Last time step:之前一步的模拟时间长度 Mx/mx:磁矩在 X 方向的归一化分量 My/my: Mz/mz: Max Spin Ang: 相邻自旋之间的最大角度， Stage Max Spin Ang:当前阶段的最大自旋角 Run Max Spin Ang:当前运行中的最大自旋角 Wall time:经过的时间（用于比较表现和 debug） Oxs MinDriver:控制最小进动演化 stopping mxHxm：A/m，一般在 0.1-10，如果要计算精确能量，要使得其低于 0.01 OOMMF eXtensible Solver Batch Interface: boxsi 应用程序 Boxsi 为 Oxs 微磁计算引擎提供批处理模式界面。提供了一个受限 制的图形界面，但是 Boxsi 主要是由命令行参数来控制的，并且由用户直接从 shell 提示符或批处理文件 在 OOMMF 体系结构中（参见第 4 节），Boxsi 既是服务器又是客户端应用程 序。 它是数据表显示和存储应用程序以及矢量场显示和存储应用程序的客户端。 Boxsi 是解决者控制服务的服务器，其唯一的客户端是 mmLaunch（第 6 节）。 mmLaunch 通过此服务代表 Boxsi 提供了一个用户界面窗口（如上所示）。 Boxsi 和 Oxsii 在输出方面的唯一区别在于，实际上 Boxsi 倾向于主要依赖输 入 MIF 文件（第 17.3.2 节）中的 Destination 和 Schedule 命令来设置输出配置。 mmArchive 作用：将数据发送到 mmArchive 的客户端应用程序控制数据流。 mmArchive 将收到的数据复制到客户端指定的文件中。 对于数据表输出，如果输出文件已经存在，那么新的数据被追加到文件的末 尾。 每个会话的数据记录夹在\ Table Start“和\ Table End”记录之间。 请参阅 ODT 格式文档（第 18 节）了解数据表文件结构。 对于矢量场输出，如果输出文件已经存在，则删除旧数据并用当前数据替换。 有关矢量场输出格式的信息，请参阅 OVF 文档（第 19 节）。 odtcat 实用程序读取包含一个或多个表的 stdin 上的 ODT（第 18 章）文件， 并将它们连接在一起形成一个表，从而创建一个由单个表组成的新 ODT 文件。当 连续的表连接时，第一个的尾部被截断，以便指定的控制列在接缝处是单调的。 

此工具对于修复从一个或多个检查点数据中断并重新启动的模拟 ODT 输出非常 有用。 oxspkg 命令用于管理可选的 Oxs 扩展包。每个包都存储在 oommf / app / oxs / contrib /下的单独目录中。这些软件包可以通过 oxspkg 命令安装到/从 oommf / app / oxs / local /目录下进行安装。 pidinfo 命令打印将 OOMMF ID（OID）映射到系统进程 ID（PID）和应用程序 名称的表。 OOMMFRootDir：这与 ReadFile 命令一起用于在 OOMMF 层次结构中定位文 件是有用的，并且也可以用于将输出文件 由零个或多个 Destination 和 Schedule 命令表示的预先指定的输出通常放置 在 Specify 块之后。 输出选择也可以在运行时使用 Oxsii（Sec 7.1，第 33 页）或 Boxsi（Sec.7.2，第 39 页）交互式界面进行修改。 Destination 的命令格式为：Destination [new] 该命令将一个符号 desttag 与一个应用程序相关联。 Schedule 命令使用这些 标签（见下文）来引用特定的应用程序实例。 appname 可以是 OOMMF 应用程序名称，例如 mmDisp，也可以是应用程序 中的特定应用程序实例：昵称，例如 mmDisp：Spock。在第一种情况下，标签与 所请求应用程序的运行实例（此处为 mmDisp）关联，其中最低的 OOMMF ID（OID） 尚未与另一个标签关联。 如果找不到符合这些标准的正在运行的应用程序，则 启动该应用程序的新实例 如果 appname 引用了特定的应用程序实例，那么该标记将与正在分配指定 昵称的应用程序的运行实例（如 mmDisp）相关联。 名称匹配不区分大小写。 如 果没有满足此条件的应用程序的正在运行的副本，则将启动应用程序的新实例并 为其分配指定的昵称。 OOMMF 账户服务目录保证一个给定昵称的应用程序不 会有多个实例。 但是，与“指定”命令中的对象名称一样，允许两个不同应用 程序（例如 mmDisp 和 mmGraph）的实例共享昵称，因为它们的完整实例名称 （例如 mmDisp：Spock 和 mmGraph：Spock）是唯一的。 目标命令按 MIF 文件中出现的顺序进行处理。 多个目标命令中不会出现 desttag，也不会有两个目标标记可能引用同一个应用程序实例。 为了保证后者， 建议用户在使用通用应用程序引用（例如，mmDisp）的任何目的地命令之前放 置涉及具体实例的所有目的地命令（例如，mmDisp：Spock）。 否则，泛型引用 可能会与正在运行的应用程序相关联，该应用程序持有由稍后的目标命令引用的 昵称。 只有解读器读取 MIF 文件才知道目标命令的标记关联。 相比之下，分配的 实例昵称在应用程序中被识别。 特别是，多个求解器可能通过昵称引用相同的 正在运行的应用程序。 例如，几个连续的解算器运行可以将舞台输出发送到相 同的 mmGraph 小部件，以建立重叠的滞后回路。 Destination 命令的最后一个参 数是可选的 new 关键字。 如果存在，则始终启动所请求应用程序的新副本以与 给定标签关联。 新选项可以安全地与任何通用应用程序引用一起使用，但是对 

特定实例引用使用此选项时必须小心，因为如果请求的昵称已被使用，则会引发 错误。 RGlob 该命令在 Tcl glob 命令（q.v.）上建模，但是被限制在当前的工作目录 下，即保存 MIF 文件的目录。 Schedule：Schedule 命令用于设置来自 MIF 文件的输出。 此功能对于在批 处理模式下运行的求解器非常重要，但对于在交互模式下设置默认连接也很有用。 Schedule Schedule 命令镜像 Oxsii 和 Boxsi 图形界面提供的交互式输出调度（Sec.7）。计 划命令的第一个参数是正在计划的输出的名称。 这些名称与出现在 Oxs 图形界 面的\ Outputs“列表中的名称相同，例如\ DataTable”或\ Oxs CubicAnisotropy： Nickel：Field“。名称必须作为单个参数呈现给 Schedule 命令;如果该名称包含一 个或多个空格，然后使用双引号来保护空格。除了总是存在的 DataTable 输出外， 外名是依赖于 MIF 文件的 计划命令的第二个参数是目标标记。 这是一个由前一个目的地命令与正在 运行的应用程序相关的标记（见上）。 符号目标标签取代了应用程序：图形界面 中使用的 OID 命名法，因为通常在组成 MIF 文件时不可能知道应用程序实例的 OOMMF ID。 实际上，有些应用程序可能由 Destination 命令启动，所以在处理 Destination 命令时甚至没有 OID 事件参数应该是关键字 Step，Stage 或 Done 中的一个。 对于 Step 和 Stage 事件，频率参数应该是一个正整数，表示应该输出指定事件的频率。 例如，如 果给出了步骤 5，那么指定类型的解算器输出的每第五步将被发送到选定的目的 地。 每次发生事件时将频率设置为 1 发送输出。 完成事件发生在成功完成模拟; 因此，每个模拟至多有一个“完成”事件，因此，完成事件的频率参数是可选的; 如果存在，则应该是值 1。 在图 8 所示的示例 MIF 2.1 文件（第 17.3.5 节，第 216 页（219））中，有一 些使用目的地和时间表命令进行时间安排的例子。在那里，三个目的地被标记。 第一个是指可能已经运行的 mmGraph 实例，具有昵称 Hysteresis。相关的调度命 令在每个阶段结束时向此应用程序发送 DataTable 输出，因此可以生成滞后图。 第二个目标标签引用了一个用于监控运行的 mmGraph 的不同副本。为了确保这 个输出被渲染到一个空白的平板上，使用 new 关键字来启动 mmGraph 的新副本。 监视器目标的“计划”命令每 5 次迭代求解器将输出传递给监视 mmGraph。最 后一个 Destination 命令标记一个任意的 mmArchive 应用程序，用于每个阶段结 束时 DataTable 结果的文件存储，以及每个阶段结束时磁化和总场的快照。请注 意，双引号包含\ Oxs EulerEvolve :: Total 字段的输出名称，如果没有引号，Schedule 命令会看到五个参数，\ Oxs EulerEvolve :: Total，\ field“，\ archive”，\ Stage“和 \ 3" 。 16.10 Launching the OOMMF host server: launchhost 在正常情况下，OOMMF 主机服务器（也称为主机服务目录）将根据客户机 应用程序的需要在后台自动启动。 但是，主要在批处理计算环境中，明确启动 主机服务器以控制主机服务器端口地址会很有用. 

The launchhost command line is: tclsh oommf.tcl launchhost [standard options] port 要求主机服务器侦听的端口号。对于非特权用户，这通常必须大于 1024， 或者是指示主机服务器在随机，未使用的端口上打开的特殊值 0。成功时， launchhost 将实际使用的主机端口号写入 stdout。 如 OOMMF 体系结构文档（第 4 节）中所述，主机服务器（主机服务目录） 在允许各种 OOMMF 应用程序相互通信方面起着至关重要的作用。 要工作，所 有 OOMMF 应用程序必须知道主机服务器端口号。 通常这个端口号由文件 oommf / config / options.tcl 中的网络主机端口设置决定，尽管这个设置可能被环 境变量 OOMMF HOSTPORT 覆盖。 但是，在批处理模式设置中，可能会发生这样的情况，即想要在单台计算机 上运行多个并发但独立的 OOMMF 会话。 一种方法是在每个会话中将环境变量 OOMMF HOSTPORT 设置为不同的值。 这里的难点在于必须确保每一次会议确实 具有独特的价值。 使用端口设置为零的 launchhost 可以为此问题提供一个直接 的解决方案。 例如，考虑 Bourne shell 脚本 #!/bin/sh OOMMF_HOSTPORT=`tclsh oommf.tcl launchhost 0` export OOMMF_HOSTPORT tclsh oommf.tcl mmArchive tclsh oommf.tcl boxsi sample.mif tclsh oommf.tcl killoommf all 第二行（OOMMF HOSTPORT = ...）在随机端口上启动主机服务器; 所选的端 口被 launchhost 打印到 stdout 并设置环境变量 OOMMF HOSTPORT。 （特别注意 launchhost 命令周围的反引号，它调用命令执行。）随后的命令在后台启动 mmArchive 的实例，并在 sample.mif 描述的问题上运行 boxsi。 （默认情况下， boxsi 在前台运行。）当 boxsi 返回时，killoommf 命令用于终止此会话中的所有 OOMMF 进程。 （或者，boxsi 命令选项-kill 可以用于与 killoommf 相同的效果。） 对于 csh 和派生类，使用 setenv OOMMF_HOSTPORT `tclsh oommf.tcl launchhost 0` 在上面的例子中代替了两个 OOMMF HOSTPORT 命令。