OXS: An Extensible Public Domain Solver for Micromagnetics

Authors: M. J. Donahue and D. G. Porter
Event: Presented as Poster III-5 at HMM 2001, Ashburn Virginia, USA.

The Object Oriented Micromagnetic Framework project (OOMMF) is a collection of intercommunicating modules providing a complete, public domain package for micromagnetics. There are modules for display, control, and solving micromagnetic programs, as well as auxiliary programs for analysis, project building and maintenance. The existing solver in this framework, mmSolve2D, is a relatively monolithic code limited to solving 2D problems. A new solver is currently being developed, the OOMMF eXtensible Solver (OXS), which is not only fully 3D capable, but is also quite modular, allowing integration of new modules with no modification to existing code, and complete sub-module selection at runtime.

The central controlling class in OXS is the unique Oxs_Director object. During program initialization this object is created and is fed the problem specification (input) file. This file contains a sequence of Specify blocks, which have a simple form as illustrated by this example: 

   Specify Oxs_UniaxialAnisotropy:AnisA {
      K1 5.2e5
      axis { 0 0 1 }
   }
This block causes the Oxs_Director object to create an instance of an Oxs_UniaxialAnisotropy object, with instance name AnisA. The character string between the first curly brace and its mate, called the object initialization string, is fed to the AnisA object at the time of its construction. The details of the interpretation of the object initialization string are up to the author of the Oxs_UniaxialAnisotropy class, but are here rather straightforward: the anisotropy coefficient K1 is set to 5.2 x 105 J/m3, and the easy axis direction is set parallel to the z-coordinate axis.

The Oxs_UniaxialAnisotropy class is an example of the general Oxs_Ext (extension) class. Nearly all the objects in OXS inherit from this class (the notable exception being the Oxs_Director class), and are constructed at runtime by the Oxs_Director as requested by Specify blocks in the input file. The Oxs_Director maintains an index of all these objects, and provides facilities to access the objects, by either the end user or by each other. This provides a great deal of flexibility, because the user selects at runtime exactly which modules he wants to use, and how many of each. In addition to energy terms like the Oxs_UniaxialAnisotropy example above, entities like the discretization mesh, evolution control object, evolution step algorithm (e.g., particular Landau-Lifshitz ODE solvers or energy minimization routines) and material property distribution are all Oxs_Ext objects, and are all selected at runtime via Specify blocks in the input file.

The modular architecture of OXS provides not only flexibility at runtime, but also makes it easy to introduce new modules. The steps in adding a new Oxs_Ext class to OXS are:

  1. Copy an existing Oxs_Ext class or generic Oxs_Ext template header and definitions files into the project subdirectory oxs/local/.
  2. Change the class name in the new files to the name chosen for the new module. To avoid naming conflicts, third party class names should not begin with Oxs_, as that prefixed is reserved for use by classes in the standard OXS distribution.
  3. Modify and write new code as desired. Typically this will involve modifying the object constructor to process the object initialization string (from the object's Specify block in the input file), and adding appropriate code to a sub-class specific member function, such as the GetEnergyAndField routine required for energy terms.
  4. Compile the new code and link it into OXS by running the platform independent build utility, pimake, included in OOMMF. Pimake automatically builds all source code in the oxs/local/ directory.
  5. Create new input files as desired, including Specify blocks for the new module.
It is important to note that this process requires no changes to the files included in the standard OOMMF distribution. As long as the application programming interface (API) is unchanged, modules written for one release of OXS can be easily incorporated into new releases.

In conclusion, the Oxs_Ext extension class provides OXS with a flexible, modular architecture. This architecture allows a micromagnetic solver to be essentially constructed at runtime out of the available Oxs_Ext classes. Moreover, new Oxs_Ext classes may be easily written and added to OXS, by both OOMMF and third party developers.

Michael J. Donahue's home page or presentation page.

michael.donahue@nist.gov
18-May-2001