OOMMF eXtensible Solver
Keywords: progman

Next: Sample Oxs_Energy Class Up: OOMMF Documentation Previous: OOMMF Variable Types and

#
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 1: OXS top-level class diagram.

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. Add new source code files to `oommf/app/oxs/local` containing your class definitions. The C++ non-header source code file(s) must be given the `.cc` 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` extension, 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.

Subsections

- Sample `Oxs_Energy` Class
- Writing a New `Oxs_Energy` Extension

OOMMF Documentation Team
September 29, 2018