Disk space

A collection of large hard disks is also beneficial to allow the long-term storage of previous simulation runs, assisting with the rapid retrieval of past vector data created by simulations.

Either 32-bit (single precision) or 64-bit (double precision) floating point numbers (IEEE, 1985) can be used to store the components of the vector data. The case for selecting one precision over another can be argued (Goldberg, 1991) from two perspectives: storing 32-bit numbers will save disk space if the extra precision offered by 64-bit numbers is not necessary, however vector interpolation used by certain visualisation techniques (e.g. the calculation of streamlines, figure 2.20) may benefit from a higher-precision. Further arguments for the use of single or double precision numbers can be found in Bennett Goldberg (1967), Demmel (1984), Goldberg (1991) and Knuth (1998). It is worth noting that OOMMF will perform the simulation using double precision numbers irrespective of the precision of the output format, and the solver component of magpar (Balay et al., 2002, Balay et al., 1997) uses double precision numbers.

Double precision floating point numbers usually require eight bytes of storage each. To store the magnetisation vectors for a given mesh in OOMMF, each position of the mesh requires three 64-bit numbers to describe it ($x$, $y$ and $z$ components). This gives a simple equation for calculating the amount of space needed to store one set of magnetisation data for a simulation:

$$s = a + {l_x \over c_x}{l_y \over c_y}{l_z \over c_z} {3p \over 8}$$ (2.41)

where $a$ is the space consumed by a header describing the relationship between the vector data and the simulation, $l_x$, $l_y$ and $l_z$ represent the size of the complete mesh, $c_x$, $c_y$ and $c_z$ are the edge lengths of the discrete cell and $p$ is the number of bits used to store one floating point number. Note that with OOMMF, even empty cells (i.e. where $\vert\ensuremath{\mathbf{M}}\vert=0$) are stored by default.

For example, to store the magnetisation vectors for a sphere of diameter 120nm ( $l_x = l_y = l_z = 120 \times 10^{-9}$m) with a cubic mesh cell size of 5nm$^3$ ( $c_x = c_y = c_z = 5\times 10^{-9}$m) with 64-bit precision ($p=64$), $(120/5)^3 * (8*3) = 331776$ bytes of disk space are needed, plus a small fixed overhead. If a coarser mesh were used, such that $c_x = c_y = c_z = 10 \times 10^{-9}$m, then only 41472 bytes of disk space are necessary to store the magnetisation data for one timestep.

For a complete simulation many sets of magnetisation vector data are stored, each usually representing a particular ``stage'' -- a point where the magnetisation configuration for an externally adjustable factor, such as applied magnetic field, is considered stable. A typical simulation might have 100 of these stages. In the case of the sphere example above, this equates to over 31 megabytes of disk space. For a sphere of double the diameter with a high field step resolution (giving 1000 stages if $-500\mathrm{mT} \leq B_x \leq 500\mathrm{mT}$ and $B_x$ is reduced in 1mT steps), over 2.5 gigabytes of storage space would be necessary. Doubling the mesh resolution and the diameter further, such that $c_x=c_y=c_z=2.5$nm and $d=480$nm, the amount of required disk space grows to well over 150 gigabytes.