The 2D Micromagnetic Interactive Solver: mmSolve2D

Overview
The application mmSolve2D is a micromagnetic computation engine
capable of solving problems defined on two-dimensional square grids of
three-dimensional spins. Within the OOMMF architecture,
mmSolve2D is both a server and a client application.
mmSolve2D is a client of
problem description server applications, data table display and storage
applications, and vector field display and storage applications.
mmSolve2D is the server of a solver control service for which the
only client is mmLaunch. It is through
this service that mmLaunch provides a user interface window (shown
above) on behalf of mmSolve2D.

LaunchingmmSolve2D may be started either by selecting the
mmSolve2D button on mmLaunch, or from the
command line via

tclsh oommf.tcl mmSolve2D [standard options] [-restart <0|1>]

-restart <0|1>

Affects the behavior of the solver
when a new problem is loaded. Default value is 0. When launched with
-restart 1, the solver will look for basename.log
and basename*.omf files to restart a previous run from
the last saved state (where basename is the ``Base
Output Filename'' specified in the input MIF 1.1
problem specification file). If these files cannot be found, then a
warning is issued and the solver falls back to the default behavior
(-restart 0) of starting the problem from scratch. The specified
-restart setting holds for all problems fed to the
solver, not just the first. (There is currently no interactive way to
change the value of this switch.)

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.

Inputs
The top panel of the user interface window may be opened and closed
by toggling the Inputs checkbutton. When open, the
Inputs panel reveals two subpanels. The left subpanel
contains a list of the inputs required by mmSolve2D. There is
only one item in the list: ProblemDescription. When
ProblemDescription is selected, the right subpanel (labeled
Source Threads) displays a list of applications
that can supply a problem description. The user selects from among the
listed applications the one from which mmSolve2D should request a
problem description.

Outputs
When mmSolve2D has outputs available to be controlled, a
Scheduled Outputs checkbutton appears in the user interface
window. Toggling the Scheduled Outputs checkbutton causes a
bottom panel to open and close in the user interface window. When open,
the Scheduled Outputs panel contains three subpanels. The
Outputs subpanel is filled with a list of the types of output
mmSolve2D can generate while solving the loaded problem. The
three elements in this list are TotalField, for the output of a
vector field representing the total effective
field, Magnetization, for the output of a vector field
representing the current magnetization state of the grid of spins, and
DataTable, for the output of a table of data
values describing other quantities of interest
calculated by 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 Ms
.)

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

|m x h|: The maximum of the
point-wise quantity
|MxHeff|/Ms2
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/m3
): The total
average energy density for the magnetically active elements of
the simulated part.

Exchange Energy (J/m3
): The
component of the average energy density for the magnetically
active elements of the simulated part due to exchange
interactions.

Anisotropy Energy (J/m3
): 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/m3
): The component
of the average energy density for the magnetically active
elements of the simulated part due to self-demagnetizing fields.

Zeeman Energy (J/m3
): 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.

Controls
The middle section of the user interface window contains a series of
buttons providing user control over the
solver. After a problem
description server application has been selected, the LoadProblem
button triggers a fetch of a problem description from the selected
server. The LoadProblem button may be selected at any time to
(re-)load a problem description from the currently selected server.
After loading a new problem the solver goes automatically into a paused
state. (If no problem description server is selected when the
LoadProblem button is invoked, nothing will happen.) The
Reset button operates similarly, except that the current problem
specifications are used.

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
terminatesmmSolve2D. 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 average energy densityE
is a function of
M
specified by Brown's equations [4], 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
[5], 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 [15] and [2].

The Landau-Lifshitz ODE (5) is
integrated using a second order
predictor-corrector technique of the
Adams type. The right side of (5) 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 Ms
before evaluating the energy and effective
fields. The right side of (5) is evaluated at the
predicted
M
, which is then combined with the value at the current
step to produce a linear interpolation of
dM/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
O(dt3)
.

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
is
reached. A control point event may
be raised by the ODE iteration count, elapsed simulation time, or by the
maximum value of
|MxHeff|/Ms2
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 µm x
1 µm part discretized with 5 nm cells will require
approximately 62 MB.

Known BugsmmSolve2D requires the damping coefficient to be non-zero.
See the MIF 1.1 documentation for details on specifying the damping
coefficient.

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.

A bug in the network traffic handling code of
Tcl on Windows 9X systems can sometimes interfere
with communications between the control interface of mmSolve2D and
the actual computation engine. If mmSolve2D is sending out data
to two or more data display services every iteration, the resulting
network traffic can ``crowd out'' the receipt of control messages from
the control interface. You may observe this as a long delay between the
time you click the Pause button and the time the solver stops
iterating. This bug first appeared in Tcl release 8.0.3, and remained
through Tcl release 8.1.1. It is fixed in
Tcl releases 8.2 and later, which we recommend for OOMMF users on
Windows 9X systems. Other platforms do not have this problem.