The first line of a MIF file must be of the form ``# MIF x.y'',
where x.y represents the format revision number, here 2.1. Unlike
MIF 1.1 files, the structure of MIF 2.1 files are governed by the
requirement that they be valid Tcl scripts, albeit with a handful of
extensions. These files are evaluated inside a Tcl interpreter, which
may be a ``safe'' interpreter, i.e., one in which disk and other system
access is disabled. (Refer to the documentation of the Tcl interp command for details on safe interpreters.) The security
level is controlled by the MIFinterp option in the options.tcl
customization file.
The default setting is
which enables all the Tcl interpreter extensions described in the MIF 2.1 Extension Commands section below, but otherwise provides a standard Tcl safe interpreter. The keyword custom above may be replaced with either safe or unsafe. The safe selection is similar to custom, except that the DateSort, ReadFile and RGlob extensions are not provided, thereby eliminating all disk access at the MIF script level. At the other extreme, choosing unsafe provides an unrestricted Tcl interpreter. This option should be used with caution, especially if you are working with MIF files from an unknown or untrusted source.Oc_Option Add Oxs* MIFinterp safety custom
After the first line, there is considerable flexibility in the layout of the file. Generally near the top of the file one places any OOMMFRootDir, Parameter, and RandomSeed statements, as desired.
This is followed by the major content of the file, the various Specify blocks, which initialize Oxs_Ext objects:
The mesh object details the spatial discretization of the simulation volume. Conventionally its Specify block follows the Specify block for the main atlas object; the mesh is referenced by the driver, so in any event the mesh Specify block needs to precede the driver Specify block.
The energy terms describe the typical micromagnetic energies and fields that determine the evolution of the simulation, such as exchange energy, magnetostatic fields, and anisotropy energies. Material parameters, such as the anisotropy constant K1 and the exchange constant A, are generally specified inside the Specify block for the relevant energy, e.g., Oxs_UniaxialAnisotropy or Oxs_Exchange6Ngbr. The exception to this is saturation magnetization, Ms, which is declared in the driver Specify block. The initial magnetization, m0, is also specified in the driver Specify block. In many cases these material parameters may be varied spatially by defining them using scalar or vector field objects. As discussed in the section on Specify Conventions, auxiliary objects such as scalar and vector fields can be defined either inline (i.e., inside the body of the referencing Specify block) or in their own, standalone top-level Specify blocks. In the latter case, the auxiliary Specify blocks must precede the referencing Specify blocks in the MIF 2.1 file.
Given the energies and fields, the evolver and driver form a matched pair that advance the magnetic state from an initial configuration, obeying either Landau-Lifshitz-Gilbert (LLG) dynamics or direct energy minimization. For energy minimization studies, the driver must be an Oxs_MinDriver object, and the evolver must be a minimization evolver. At the time of this writing, the only minimization evolver packaged with OOMMF is the Oxs_CGEvolve conjugate-gradient evolver. For time-evolution (LLG) simulations, the driver must be an Oxs_TimeDriver object, and the evolver must be a time evolver, such as Oxs_RungeKuttaEvolve. The evolver to be used is cited inside the driver Specify block, so the evolver must precede the driver in the MIF 2.1 file. As noted above, the pointwise saturation magnetization Ms and initial magnetization configuration m0 are declared inside the driver Specify block as well.
The pre-specified outputs, indicated by zero or more Destination and Schedule commands, are conventionally placed after the Specify blocks. Output selection can also be modified at runtime using the Oxsii or Boxsi interactive interfaces.
Auxiliary Tcl procs may be placed anywhere in the file, but commonly either near their point of use or else at the bottom of the MIF file. If a proc is only referenced from inside Specify blocks, then it can be placed anywhere in the file. On the other hand, if a proc is used at the top level of the MIF file, for example to dynamically create part of the problem specification ``on-the-fly,'' then it must be defined before it is used, in the normal Tcl manner.
A sample MIF 2.1 file is included below. More details on the individual Oxs_Ext objects can be found in the Standard Oxs_Ext Child Classes section of the Oxs documentation.