Notation

• Hexagonal boxes with green text indicate one of the two simulation packages involved: OOMMF for the finite difference method, or magpar for the hybrid finite element/boundary element method.

• Diamonds containing red text show a source compiler or a script interpreter, such as gcc or Python.

• Parallelograms show a fundamental library necessary for the compilation of one of the simulation packages.

• Ellipses with purple text show an intermediate data set necessary for ``gluing'' components together.

• Boxes with blue text indicate a complex custom application designed to convert or otherwise handle the input and output of one application or library.

• Trapezoids with grey text demonstrate a presentation output file; numerical data
  would be a hysteresis loop, for example, whereas graphical data would be a magnetisation visualisation.

• Ellipsoids with red text show a supporting external application necessary for visualisation, pre- or post-processing or runtime.

Conversion between data sets or to interpret a data set as the input of another program is performed by a custom application not necessarily indicated on the diagram in figure E.1 for clarity.

The build of the hybrid finite element/boundary element package magpar is much more complicated than that of its finite difference peer, OOMMF. OOMMF is available from the NIST website as either a source code package with a straightforward build process or as a precompiled binary application for many architectures and operating systems, such as GNU/Linux or Microsoft Windows. The framework of the three-dimensional micromagnetic problem solver, Oxs (the OOMMF Extensible Solver), is shown in figure E.2. The blue items in boxes here show areas which can be straightforwardly extended to include, for example, a twenty-six neighbour exchange energy contribution rather than the standard six neighbour exchange provided as standard with OOMMF. Oxs provides a powerful mechanism for extending this micromagnetics package.

Conversely, magpar is dependent on many highly optimised mathematics libraries which have been developed by different organisations and individuals for many years. While the result of each of these is a library which is extremely powerful with respect to its individual application (linear algebra, matrix transformation, differential equation solvers), compatibility and ease-of-use suffer. Although these issues will be addressed in due course, it alienates many members of the physics community as one must be familiar with software development in a UNIX-like environment to successfully use the software when provided in this form.

In theory, of course, binaries of magpar could be provided just as for OOMMF, however given the automatic calibration and tuning of the mathematical libraries involved, performance would be adversely affected, and there is no guarantee that the results would be accurate. Taking advantage of the features provided by one particular architecture can introduce dangerous imprecision when run on another similar architecture, especially when considering floating point computation cancellation and round-off errors (Schulte and Swartzlander, 2000).

Figure E.2: The OOMMF extensible solver framework. Blue items in boxes indicate extensible areas