The basic installation procedure should be sufficient to install OOMMF on most Unix systems. Sometimes, however, the build will fail due to missing Tcl header files (tcl.h, tk.h) or libraries (e.g., libtcl.so, libtk.so). This problem can usually be solved by installing a “development” version of Tcl/Tk, which may be found on the operating system installation disks, or may be available from the system vendor. There are also binary releases of Tcl/Tk for a number of systems available from ActiveState, under the name ActiveTcl. Alternatively, one may download the sources for Tcl and Tk from the Tcl Developer Xchange, and build and install Tcl/Tk from source. The Tcl/Tk build follows the usual Unix configure, make, make install build convention.
On most systems, OOMMF builds by default with relatively unaggressive compiler optimization options. As discussed earlier (Optimization), you may edit the appropriate oommf/config/platforms/ file to change the default compilation options. However, on some common systems (e.g., Linux, some BSD variants) OOMMF will try to deduce the hardware architecture (i.e., the CPU subtype, such as Pentium 3 vs. Pentium 4) and apply architecture-specific options to the compile commands. This is probably what you want if OOMMF is to be run only on the system on which it was built, or if it is run on a homogeneous cluster. If, instead, you intend to run OOMMF on a heterogeneous cluster you may need to restrict the compiler options to those supported across your target machines. In that case, open the appropriate configuration file in the oommf/config/platforms/ directory, and look for the lines
# You can override the GuessCPU results by directly setting or
# unsetting the cpuopts variable, e.g.,
#
# set cpuopts [list -march=skylake]
# or
# unset cpuopts
#
Uncomment either the “unset cpuopts” line to make a generic build, or else edit the “set cpuopts” line to an appropriate common-denominator architecture and uncomment that line.
In a similar vein, some compilers support a “-fast” switch, which usually creates an architecture-specific executable. The same considerations apply in this case.
An advanced alternative would be to define separate OOMMF “platforms” for each CPU subtype in your cluster. At a minimum, this would involve creating separate platform name files in oommf/config/names/ for each subtype, and then making copies of the appropriate oommf/config/platforms file for each new platform. The platform name files would have to be written so as to reliably detect the CPU subtype on each machine. See “Managing OOMMF platform names” for details on creating platform name files.
The platform build scripts for Linux, oommf/config/platforms/lintel.tcl (32-bit) and oommf/config/platforms/linux-x86_64.tcl (64-bit) contain sections supporting the Portland Group pgCC compiler. Non-threaded builds of OOMMF using this compiler run fine, but threaded builds segfault when running Oxsii/Boxsi. The source of this problem is not known at this time.