OOMMF eXtensible Solver

The OOMMF eXtensible Solver (OXS) top level architecture is shown in the class diagram below. The “Tcl Control Script” block represents the user interface and associated control code, which is written in Tcl. The micromagnetic problem input file is the content of the “Problem Specification” block. The input file should be a valid MIF 2.0 file (see the OOMMF User's Guide for details on the MIF file formats), which also happens to be a valid Tcl script. The rest of the architecture diagram represents C++ classes.

Figure 4.1: OXS top-level class diagram. The Problem Specification is the input MIF file. The blue clouds are support classes and code. The red clouds are abstract Oxs_Ext classes. The yellow clouds are concrete child Oxs_Ext classes; the black outlines are standard OOMMF classes, and green outlines are third party extensions.

All interactions between the Tcl script level and the core solver are routed through the Director object. Aside from the Director, all other classes in this diagram are examples of Oxs_Ext objects—technically, C++ child classes of the abstract Oxs_Ext class. OXS is designed to be extended primarily by the addition of new Oxs_Ext child classes. The general steps involved in adding an Oxs_Ext child class to OXS are:

1. Create a subdirectory under oommf/app/oxs/local, and add source code files with class definitions into this subdirectory. The C++ non-header source code file(s) must be given the .cc or .cpp extension. (Header files are typically denoted with the .h extension, but this is not mandatory.)
2. Run pimake to compile your new code and link it in to the OXS executable.
3. Add the appropriate Specify blocks to your input MIF 2.0 files.

The source code can usually be modeled after an existing Oxs_Ext object. Refer to the Oxsii section of the OOMMF User's Guide for a description of the standard Oxs_Ext classes, or below for an annotated example of an Oxs_Energy class. Base details on adding a new energy term are also presented below. The pimake application automatically detects all files in the oommf/app/oxs/local directory with the .cc or .cpp extensions, and searches them for #include requests to construct a build dependency tree. Then pimake compiles and links them together with the rest of the OXS files into the oxs executable. Because of the automatic file detection, no modifications are required to any files of the standard OOMMF distribution in order to add local extensions. Local extensions are then activated by Specify requests in the input MIF 2.0 files. The object name prefix in the Specify block is the same as the C++ class name. All Oxs_Ext classes in the standard distribution are distinguished by an Oxs_ prefix. It is recommended that local extensions use a local prefix to avoid name collisions with standard OXS objects. (C++ namespaces are not currently used in OOMMF for compatibility with some older C++ compilers.) The Specify block initialization string format is defined by the Oxs_Ext child class itself; therefore, as the extension writer, you may choose any format that is convenient. However, it is recommended that you follow the conventions laid out in the MIF 2.0 file format section of the OOMMF User's Guide.

OOMMF Documentation Team
September 27, 2024