10.1 The 2D Micromagnetic Interactive Solver: mmSolve2D

Since mmSolve2D does not present any user interface window of its own, it depends on mmLaunch to provide an interface on its behalf. The entry for an instance of mmSolve2D in the Threads column of any running copy of mmLaunch has a checkbutton next to it. This button toggles the presence of a user interface window through which the user may control that instance of mmSolve2D. The user interface window is divided into panels, providing user interfaces to the Inputs, Outputs, and Controls of mmSolve2D.

Upon selecting one of the output types from the Outputs subpanel, a list of applications appears in the Destination Threads subpanel which provide a display and/or storage service for the type of output selected. The user may select from this list those applications to which the selected type of output should be sent.

For each application selected, a final interface is displayed in the Schedule subpanel. Through this interface the user may set the schedule according to which the selected type of data is sent to the selected application for display or storage. The schedule is described relative to events in mmSolve2D. An Iteration event occurs at every step in the solution of the ODE. A ControlPoint event occurs whenever the solver determines that a control point specification is met. (Control point specs are discussed in the Experiment parameters paragraph in the MIF 1.1 documentation, and are triggered by solver equilibrium, simulation time, and iteration count conditions.) An Interactive event occurs for a particular output type whenever the corresponding “Interactive Outputs” button is clicked in the Runtime Control panel. The Interactive schedule gives the user the ability to interactively force data to be delivered to selected display and storage applications. For the Iteration and ControlPoint events, the granularity of the output delivery schedule is under user control. For example, the user may elect to send vector field data describing the current magnetization state to an mmDisp instance for display every 25 iterations of the ODE, rather than every iteration.

The quantities included in DataTable output produced by mmSolve2D include:

• •

  Iteration: The iteration count of the ODE solver.

• •

  Field Updates: The number of times the ODE solver has calculated the effective field.

• •

  Sim Time (ns): The elapsed simulated time.

• •

  Time Step (ns): The interval of simulated time spanned by the last step taken in the ODE solver.

• •

  Step Size: The magnitude of the last step taken by the ODE solver as a normalized value. (This is currently the time step in seconds, multiplied by the gyromagnetic ratio times the damping coefficient times $M_s$.)

• •

  Bx, By, Bz (mT): The $x$, $y$, and $z$ components of the nominal applied field.

• •

  B (mT): The magnitude of the nominal applied field (always non-negative).

• •

  |m x h|: The maximum of the point-wise quantity $\parallel \text{𝐌}\times {\text{𝐇}}_{\mathrm{eff}}\parallel /M_s^2$ over all the spins. This “torque” value is used to test convergence to an equilibrium state (and raise control point –torque events).

• •

  Mx/Ms, My/Ms, Mz/Ms: The $x$, $y$, and $z$ components of the average magnetization of the magnetically active elements of the simulated part.

• •

  Total Energy (J/m${}^{\mathrm{3}}$): The total average energy density for the magnetically active elements of the simulated part.

• •

  Exchange Energy (J/m${}^{\mathrm{3}}$): The component of the average energy density for the magnetically active elements of the simulated part due to exchange interactions.

• •

  Anisotropy Energy (J/m${}^{\mathrm{3}}$): The component of the average energy density for the magnetically active elements of the simulated part due to crystalline and surface anisotropies.

• •

  Demag Energy (J/m${}^{\mathrm{3}}$): The component of the average energy density for the magnetically active elements of the simulated part due to self-demagnetizing fields.

• •

  Zeeman Energy (J/m${}^{\mathrm{3}}$): The component of average energy density for the magnetically active elements of the simulated part due to interaction with the applied field.

• •

  Max Angle: The maximum angle (in degrees) between the magnetization orientation of any pair of neighboring spins in the grid. (The neighborhood of a spin is the same as that defined by the exchange energy calculation.)

In addition, the solver automatically keeps a log file that records the input problem specification and miscellaneous runtime information. The name of this log file is basename.log, where basename is the “Base Output Filename” specified in the input problem specification. If this file already exists, then new entries are appended to the end of the file.

Once a problem is loaded, the solver can be put into any of three states: run, relax and pause. Selecting Relax puts the solver into the “relax” state, where it runs until a control point is reached, after which the solver pauses. If the Relax button is reselected after reaching a control point, then the solver will simply re-pause immediately. The Field+ or Field– button must be invoked to change the applied field state. (Field state schedules are discussed below.) The Run selection differs in that when a control point is reached, the solver automatically steps the nominal applied field to the next value, and continues. In “run” mode the solver will continue to process until there are no more applied field states in the problem description. At any time the Pause button may be selected to pause the solver. The solver will stay in this state until the user reselects either Run or Relax. The current state of the solver is indicated in the Status line in the center panel of the user interface window.

The problem description (MIF 1.x format) specifies a fixed applied field schedule. This schedule defines an ordered list of applied fields, which the solver in “run” mode steps through in sequence. The Field– and Field+ buttons allow the user to interactively adjust the applied field sequence. Each click on the Field+ button advances forward one step through the specified schedule, while Field– reverses that process. In general, the step direction is not related to the magnitude of the applied field. Also note that hitting these buttons does not generate a “ControlPoint” event. In particular, if you are manually accelerating the progress of the solver through a hysteresis loop, and want to send non-ControlPoint data to a display or archive widget before advancing the field, then you must use the appropriate “Interactive Output” button.

The second row of buttons in the interaction control panel, TotalField, Magnetization and DataTable, allow the user to view the current state of the solver at any time. These buttons cause the solver to send out data of the corresponding type to all applications for which the “Interactive” schedule button for that data type has been selected, as discussed in the Outputs section above.

At the far right of the solver controls is the Exit button, which terminates mmSolve2D. Simply closing the user interface window does not terminate mmSolve2D, but only closes the user interface window. To kill the solver the Exit button must be pressed.

The effective field is defined as

The average energy density $E$ is a function of M specified by Brown’s equations [5], including anisotropy, exchange, self-magnetostatic (demagnetization) and applied field (Zeeman) terms.

The micromagnetic problem is impressed upon a regular 2D grid of squares, with 3D magnetization spins positioned at the centers of the cells. Note that the constraint that the grid be composed of square elements takes priority over the requested size of the grid. The actual size of the grid used in the computation will be the nearest integral multiple of the grid’s cell size to the requested size. It is important when comparing the results from grids with different cell sizes to account for the possible change in size of the overall grid.

The anisotropy and applied field energy terms are calculated assuming constant magnetization in each cell. The exchange energy is calculated using the eight-neighbor bilinear interpolation described in [6], with Neumann boundary conditions. The more common four-neighbor scheme is available as a compile-time option. Details can be found in the source-code file oommf/app/mmsolve/magelt.cc.

The self-magnetostatic field is calculated as the convolution of the magnetization against a kernel that describes the cell to cell magnetostatic interaction. The convolution is evaluated using fast Fourier transform (FFT) techniques. Several kernels are supported; these are selected as part of the problem description in MIF 1.x format. Each kernel represents a different interpretation of the discrete magnetization. The recommended model is ConstMag, which assumes the magnetization is constant in each cell, and computes the average demagnetization field through the cell using formulae from [23] and [2].

The Landau-Lifshitz ODE (10.1) is integrated using a second order predictor-corrector technique of the Adams type. The right side of (10.1) at the current and previous step is extrapolated forward in a linear fashion, and is integrated across the new time interval to obtain a quadratic prediction for M at the next time step. At each stage the spins are renormalized to $M_s$ before evaluating the energy and effective fields. The right side of (10.1) is evaluated at the predicted M, which is then combined with the value at the current step to produce a linear interpolation of $d\text{𝐌}/dt$ across the new interval. This is then integrated to obtain the final estimate of M at the new step. The local (one step) error of this procedure should be $𝒪(\mathrm{\Delta }{t}^3)$.

The step is accepted if the total energy of the system decreases, and the maximum error between the predicted and final M is smaller than a nominal value. If the step is rejected, then the step size is reduced and the integration procedure is repeated. If the step is accepted, then the error between the predicted and final M is used to adjust the size of the next step. No fixed ratio between the previous and current time step is assumed.

A fourth order Runge-Kutta solver is used to prime the predictor-corrector solver, and is used as a backup in case the predictor-corrector fails to find a valid step. The Runge-Kutta solver is not selectable as the primary solver at runtime, but may be so selected at compile time by defining the RUNGE_KUTTA_ODE macro. See the file oommf/app/mmsolve/grid.cc for all details of the integration procedure.

For a given applied field, the integration continues until a control point (cf. Experiment parameters, Sec. 17.1.5) is reached. A control point event may be raised by the ODE iteration count, elapsed simulation time, or by the maximum value of $\parallel \text{𝐌}\times {\text{𝐇}}_{\text{eff}}\parallel /M_s^2$ dropping below a specified control point –torque value (implying an equilibrium state has been reached).

Depending on the problem size, mmSolve2D can require a good deal of working memory. The exact amount depends on a number of factors, but a reasonable estimate is 5 MB + 1500 bytes per cell. For example, a 1 $\mu$m $\times$ 1 $\mu$m part discretized with 5 nm cells will require approximately 62 MB.

When multiple copies of mmLaunch are used, each can have its own interface to a running copy of mmSolve2D. When the interface presented by one copy of mmLaunch is used to set the output schedule in mmSolve2D, those settings are not reflected in the interfaces presented by other copies of mmLaunch. For example, although the first interface sets a schedule that DataTable data is to be sent to an instance of mmGraph every third Iteration, there is no indication of that schedule presented to the user in the second interface window. It is unusual to have more than one copy of mmLaunch running simultaneously. However, this bug also appears when one copy of mmLaunch is used to load a problem and start a solver, and later a second copy of mmLaunch is used to monitor the status of that running solver.