OOMMF Home next up previous contents
Next: Data Table Display: mmDataTable Up: OOMMF Documentation Previous: Micromagnetic Problem File Source:


The 2D Micromagnetic Solver: mmSolve2D

mmSolve2D Screen Shot

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.

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

tclsh app/oommf/oommf.tcl mmSolve2D [-console] [-tk|-notk]

The command line options -tk and -notk determine whether or not mmSolve2D has its own window. By default it does not ( -notk). With no window, an instance of mmSolve2D may keep running while a window system goes down and comes back up again (on some platforms). This is useful since a single instance of mmSolve2D may need to run for hours or days at a time to solve one problem. When mmSolve2D does have a window ( -tk), it does not place anything in its window, nor does it even display its window. The only effects of the presence of the window are that any error messages will be displayed in pop-up windows, that the -console option becomes available for displaying a console window in which interactive Tcl commands may be typed, and that (on some platforms) the termination of the windowing system will terminate the program. Running mmSolve2D with the -tk option is generally useful only for debugging.

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. An Equilibrium event occurs whenever the solver determines that an equilibrium magnetization state has been reached. An Interactive event occurs for a particular output type whenever the corresponding ``Interactive Outputs'' button is clicked in the panel of control buttons. 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 Equilibrium 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:

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 an equilibrium is reached, after which the solver pauses. The Run selection differs in that when equilibrium 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. (Field state schedules are discussed below.) 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 (in MIF 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 an ``equilibrium'' event. In particular, if you are manually accelerating the progress of the solver through a hysteresis loop, and want to send non-equilibrium 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.

Details
Given a problem description, mmSolve2D integrates the Landau-Lifshitz equation [6,8]

$\displaystyle {\frac{d\textbf{M}}{dt}}$ = - $\displaystyle \gamma$ M x Heff - $\displaystyle {\frac{\gamma\alpha}{M_s}}$ M x $\displaystyle \left(\vphantom{\textbf{M}\times\textbf{H}_{\rm eff}}\right.$M x Heff$\displaystyle \left.\vphantom{\textbf{M}\times\textbf{H}_{\rm eff}}\right)$, (1)

where
M   is the pointwise magnetization (A/m),  
Heff   is the pointwise effective field (A/m),  
$\displaystyle \gamma$   is the gyromagnetic ratio (m/(A·s)),  
$\displaystyle \alpha$   is the damping coefficient (dimensionless).  

The effective field is defined as

Heff = - $\displaystyle \mu_{0}^{-1}$$\displaystyle {\frac{\partial E}{\partial\textbf{M}}}$.

The average energy density E is a function of M specified by Brown's equations [3], including crystalline 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. At present, Neumann boundary conditions are assumed.

The crystalline 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 [4]. The more common four-neighbor scheme is available as a compile-time option. See the file app/mmsolve/magelt.cc for details.

The self-magnetostatic field is calculated using fast Fourier transform (FFT) techniques. Inside each cell, the magnetization is assumed constant along the z-axis. In the xy-plane, two models are supported: constant magnetization and constant charge. The model is selected as part of the problem description in MIF format.

The Landau-Lifshitz ODE (1) is integrated using a second order predictor-corrector technique of the Adams type. The right side of (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 Ms before evaluating the energy and effective fields.) The right side of (1) 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 first order Euler step is used to prime the predictor-corrector solver. A fourth order Runge-Kutta solver is included in the code, 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 app/mmsolve/grid.cc for all details of the integration procedure.

The integration is stopped and equilibrium is assumed when the maximum value of |M x Heff|/Ms2

drops below the value specified for ``Converge |mxh| Value'' in the problem description.

Known Bugs

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 95 and Windows 98 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 network traffic used to send out that data 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 release 8.2 and later, which we recommend for OOMMF users on Windows 95 Windows 98 systems. Other platforms do not have this problem.


OOMMF Home next up previous Contents

OOMMF Documentation Team
February 23, 2000