OOMMF 1.2a3 Known Problems

Information on applying patches is provided below. You can apply the patches individually, or apply this composite patch which contains all the patches up through and including item 32 (3-June-2011). The composite patch should apply cleanly against the OOMMF 1.2a3 "source-only" distribution; it may also be applied against the "source + Windows executables" distributions, but will yield one irrelevant failed patch hunk. (If you get a message saying "Reversed (or previously applied) patch detected! Assume -R?", reply "no" and do not apply the hunk.) After applying the composite patch, you should rebuild OOMMF. Note that there are no patches for resolving items 1, 4, 14, 15, 22, 23 and 27.

NOTE: Building OOMMF 1.2a3 sources against Tcl/Tk 8.5.x or higher requires that patch 31 be applied. Building against Tcl/Tk 8.5.10 or higher requires additionally patch 32.

See also the troubleshooting page in the OOMMF User's Guide for additional, mostly system related, issues.

Problem: The MIF 2.0 input file format used by Oxs in earlier releases is not compatible with the MIF 2.1 input file format used by Oxs in OOMMF 1.2a3 and later.
Solution: Use the mifconvert command line utility to convert from MIF 2.0 to MIF 2.1.
Problem: On launch, the Oxs batch mode application Boxsi fails with the error message
Boxsi 1.2.0.3 error : can't read "nice" : no such variable
Solution: This is a bug in Boxsi. To correct, replace the file oommf/app/oxs/boxsi.tcl with this replacement file, or else apply this patch. (07-Nov-2002)
Problem: When compiling OOMMF using gcc 3.x the following error occurs:
oommf/pkg/nb/evoc.cc: In function `void Oc_Times(Oc_TimeVal&, Oc_TimeVal&)': oommf/pkg/nb/evoc.cc:529: `CLK_TCK' undeclared (first use this function)
Solution: This results from a combination of a bug in OOMMF and a backwards incompatibility in gcc. To fix, replace oommf/pkg/nb/evoc.cc with this replacement file, or else apply this patch. (19-Nov-2002)
Note: Item 12 documents an additional problem when using gcc 3.3.
Problem: When running with RedHat Linux 7.x on x86-based machines, Oxsii and Boxsi crash with no error message when loading certain input MIF files.
Solution: The version of the gcc compiler shipped with the RedHat 7.x line (namely gcc 2.96) has some issues with respect to exception handling. A workaround is to build OOMMF with frame pointers. First, edit oommf/config/cache/lintel.tcl. Find the section "# ...for GNU g++ C++ compiler"; you should see the line
$config SetValue program_compiler_c++_option_opt {format "-O3 -ffast-math -fomit-frame-pointer"}
change this to
$config SetValue program_compiler_c++_option_opt {format "-O3 -ffast-math"}
Then back in the base oommf directory run
./oommf.tcl pimake distclean ./oommf.tcl pimake
to rebuild OOMMF from scratch. (19-Nov-2002)

Problem: When building under Digital/Tru64 Unix or HP-UX, errors concerning OxsASFSpecifiedValue::isset are generated, such as:

cxx: Warning:
oommf/app/oxs/ext/atlasscalarfield.h,
line 26:
          too few arguments in macro invocation
  OxsASFSpecifiedValue() : isset(0), value(0.) {}
----------------------------------^
cxx: Error:
oommf/app/oxs/ext/atlasscalarfield.h,
line 26:
          name of member or base class is missing
  OxsASFSpecifiedValue() : isset(0), value(0.) {}
---------------------------^

Solution: This is caused by a naming conflict between Oxs and system header files. To fix, apply this patch. (09-Dec-2002)

Problem: The command line utility avf2ovf aborts if the -clip option is used.
Solution: This is a bug in the avf2ovf script file. To fix, either replace oommf/app/mmdisp/scripts/avf2ovf.tcl with this replacement file, or else apply this patch. (14-Mar-2003)
Problem: Oxs (oxsii and boxsii) output vector field files in "binary 8" mode only show 4 byte (7 decimal digit) accuracy. (The pre-compiled Windows executable releases of OOMMF do not suffer this problem. YMMV if you build from source.)
Solution: There is a typo in the vector field output code that causes double precision (8 byte) values to be narrowed to 4 bytes. The text-based output code is not affected by this bug, so the simplest solution is to select full-precision text-style output ("text %.17g") instead of binary. Alternatively, apply this patch and run
tclsh oommf.tcl pimake
from the top-level OOMMF root directory to recompile and link Oxs. This bug affects the C++ code, so rebuilding is required. (15-Mar-2003)
Problem: Opening Oxs or mmArchive interface windows from the mmLaunch "Threads" list brings up warning messages about a bad package being "loaded, but not provided".
Solution: This bug arises from an ambiguity in the Tcl documentation, and typically manifests when a binary package (such as Tk Img) is installed. This happens in particular with the ActiveState ActiveTcl 8.4.2.0 release. To fix, either replace oommf/pkg/oc/custom.tcl with this replacement file, or else apply this patch. (20-Mar-2003)
Problem: Tcl procs inside MIF 2.1 files cause Oxs to crash if any variables from the proc argument list are passed back in the return statement.
Solution: This is a reference counting bug in the C++ code. One workaround is to create an unreferenced copy of the argument variable(s) for return; for example, replace
proc MyField {x y z} { return [list $x $y $z] }
with
proc MyField {x y z} { return [list [expr {1*$x}] [expr {1*$y}] [expr {1*$z}]] }
The alternative is to replace oommf/app/oxs/base/util.cc with this replacement file, or else apply this patch. Since this affects the C++ code, rebuilding OOMMF is required. (22-Mar-2003)
Problem: When using the Oxs_UZeeman class in an Oxs MIF file, the total stage count is sometimes incorrect.
Solution: This can occur on machines that have an internal (register) floating point representation that is different from that stored in memory. Notably, this includes Linux/x86 systems, but the problem may occur on Windows if the Borland compiler was used to build OOMMF. To fix, either replace oommf/app/oxs/ext/uzeeman.cc with this replacement file or apply this patch. Then follow the instructions for rebuilding OOMMF. (26-Mar-2003)
Addendum: The 26-Mar-2003 file/patch had a bug that caused field ranges with 0 step count to be treated as having a step count of 1. The above links point to an updated version that fixes that too. (15-Apr-2003)
Problem: On Windows, a file access error occurs while running OOMMF. Typically the message will contain text like
couldn't open "C:/oxs-tdm227-1320-0.omf": permission denied
The actual name of the file will vary.
Solution: The source of the problem is OOMMF trying to create a temporary file in a directory to which it does not have write access. In part, this is due to a bug in OOMMF, which can be fixed by replacing oommf/pkg/oc/tempfile.tcl with this replacement file, or by applying this patch. Then check that you have an environment variable named TEMP, and that it is set to the name of a directory to which you have write access. Alternatively, you can set the OOMMF temporary directory by editing the file oommf/config/cache/wintel.tcl. Around line 100 you should see
# $config SetValue path_directory_temporary {C:\temp}
The leading '#' makes this line an unprocessed comment. Remove the '#', and change the directory from C:\temp to a directory where you have write access. (04-Jun-2003)
Problem: Building with the GNU g++ 3.3 compiler fails with a non-lvalue error in oommf/app/oxs/base/util.cc at line 96. (Thanks to R. P. Boardman for reporting this.)
Solution: Apply this patch, and if you haven't already, also the the patch at item 3, and rerun pimake. (09-Jun-2003)
Problem: The Schedule command in Oxs MIF 1.2 files breaks if the output name has an embedded space, as in
Schedule "Oxs_EulerEvolve::Total field" archive Stage 1
(Thanks to Ming Yan for uncovering this bug.)
Solution: Either replace oommf/app/oxs/base/mif.tcl with this replacement file, or else apply this patch. (10-Jul-2003)
Problem: OOMMF fails to build on some systems with the message
Unknown feature 'TCL_PREFIX' in configuration ...
or a similar message involving 'TK_PREFIX'.
Solution: The problem arises because OOMMF can't find the tclconfig.sh and/or tkconfig.sh files in the Tcl/Tk installation. Replacing oommf/pkg/oc/config.tcl with this replacement file, and oommf/app/pimake/csourcefile.tcl with this replacement file, should fix the problem on Debian Linux and BSD systems. (Thanks to Alexander Konovalenko and Brigham Young for help on uncovering and resolving this problem.) (28-Apr-2004)
Addendum: The original 28-Apr-2004 replacement config.tcl file failed to find tcl.h and tk.h on some systems. The above link points to an updated version that fixes that too. (29-Apr-2004)
Update (14-May-2004): Do not make this change on Windows. It may break OOMMF on that platform.
Problem: OOMMF doesn't recognize x86-based BSD systems.
Solution: Copy this platform name file to oommf/config/names/bsdi.tcl and this platform cache file to oommf/config/cache/bsdi.tcl. (27-Apr-2004)
Problem: Opening Oxs or mmArchive interface windows from the mmLaunch "Threads" list yields the error message
mmLaunch 1.2.0.3 Oc_Main error:
can't read "argv0": no such variable
(Thanks to Feodor Ogrin for reporting this bug.)
Solution: This bug should only bite if you have the OOMMF_ROOT environment variable set. To fix, either unset OOMMF_ROOT, replace oommf/pkg/oc/main.tcl with this replacement file, or else apply this patch. (04-Jun-2004)
Problem: Memory usage by mmDisp grows slowly over time, as a function of the number of frames displayed.
Solution: This is due to a bug in Tk's place geometry manager. As a workaround, either replace oommf/pkg/ow/entryscale.tcl with this replacement file, or else apply this patch. (15-Sep-2004)
Problem: On some Linux systems, memory usage by X grows dramatically as mmDisp displays more and more frames. (Thanks to M. Al-Saqer for spotting and helping to resolve this problem.)
Solution: This appears to be a memory leak in X involving cursor handling. As a workaround, replace oommf/pkg/ow/procs.tcl with this replacement file, or else apply this patch. If you are replacing the file, please note that there are files named "procs.tcl" in several directories. These are completely distinct files; replace procs.tcl in directory oommf/pkg/ow/ only and exactly. (27-Sep-2004)
Problem: Loading OVF 0.0 (aka SVF) format vector field files into Oxs fails, with the warning message
invalid command name "Vf_SvfIsType"
(Reported by K. Huska.)
Solution: This is a bug in the handling of OVF 0.0 files by Oxs. One can work around this bug by using in Oxs only OVF 1.0 files (both the interactive program mmDisp and the command line utility avf2ovf will convert from OVF 0.0 to OVF 1.0). Otherwise, either replace oommf/app/oxs/base/oxs.cc with this replacement file, or else apply this patch. This bug affects the C++ code, so rebuilding OOMMF is required. (22-Oct-2004)
Problem: Building OOMMF with Microsoft Visual C++ 7.0 fails with the message
couldn't execute "lib": no such file or directory
Solution: Your compiler installation is missing the "lib" librarian program. However, lib is just a wrapper around link /lib, so this problem is easily fixed by appropriate adjustments to the cache file. Either replace oommf/config/cache/wintel.tcl with this replacement file, or else apply this patch. See also item 25 and item 26. (22-Oct-2004)
Problem: Pimake aborts while building OOMMF with the error message
can't read "DBGX": no such variable
In particular, this happens on AIX systems. (Reported by C. Bayer.)
Solution: This problem arises due to tclConfig.sh and/or tkConfig.sh files with unusual contents. To work around, either replace oommf/app/pimake/platform.tcl with this replacement file, or else apply this patch. (17-Dec-2004)
Problem: On some Linux systems, launching oommf.tcl yields an error message of the form
error while loading shared libraries: libtk8.4.so: cannot open shared object file: No such file or directory
Solution: This typically happens because the libtk8.x.so (and libtcl8.x.so) files are installed in a directory not included in the ld.so runtime linker/loader search path. One way to fix this is to add that directory (say /usr/local/lib) to the LD_LIBRARY_PATH environment variable. For example, add
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
to your ~/.bashrc file (bash shell users) or
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/usr/local/lib
to your ~/.cshrc file (csh or tcsh shell users). Another option is to modify the ld.so cache; see the ld.so and ldconfig man pages for details. (6-Jun-2005)
Problem: On 64-bit systems, launching too many instances of Oxsii and/or Boxsi (typically about 8) causes mmArchive and sometimes some of the instances of Oxsii or Boxsi to become non-responsive and possibly burn CPU cycles.
Solution: This is a 64-bit specific bug in Tcl,
http://sourceforge.net/support/tracker.php?aid=1071807
To fix, upgrade Tcl/Tk to version 8.4.9 or later. (9-Mar-2006)
Update (29-Nov-2006): It turns out that there are two bugs in Tcl that can cause this problem. The Tcl/Tk 8.4.9 release fixed one of them, but the other remains as of this date. A fix is expected in Tcl/Tk 8.4.15. In the interim, it is possible to hack a fix into the Tcl source. See
http://sourceforge.net/support/tracker.php?aid=1602208
for details.
Problem: Stack trace information is lost in the reporting of application launch errors.
Solution: This problem should not affect normal program operation. However, it makes it more difficult to track down (and fix) configuration or other launch related errors. To fix, either replace oommf/pkg/oc/commandline.tcl with this replacement file, or else apply this patch. (1-Jun-2006)
Problem: Launching OOMMF on Windows brings up the error message
omfsh.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
and no "localhost" button appears in mmLaunch.
Solution: This problem occurs on builds of OOMMF made with the Microsoft Visual C++ 2005 compiler (v. 8.0), and is due to a backward incompatibility arising from stricter parameter checking in the system signal() call. To fix, either replace oommf/pkg/oc/oc.cc with this replacement file, or else apply this patch. This bug affects the C++ code, so rebuilding OOMMF is required. (12-Dec-2006)
Problem: Building OOMMF with the Microsoft Visual C++ 2005 compiler (v. 8.0) produces many warning messages.
Solution: None of the warnings are fatal, but you can get a cleaner build by replacing oommf/config/cache/wintel.tcl with this replacement file, or by applying either this patch for the OOMMF 1.2a3 source-only distribution, or this patch for the OOMMF 1.2a3 source + Windows executables distributions. See also item 20 and item 25. (12-Dec-2006)
Problem: For some input and configuration files, avf2ppm and avf2ps sometimes produce blank output files. (Reported by J. DeAngelis.)
Solution: This can be caused by the slice selection falling between and just missing two sample planes. mmDisp uses a slightly different slice selection algorithm, so it may pick up and display arrows where avf2ppm and avf2ps don't. A solution to this problem is to modify the "misc,centerpt" or "misc,relcenterpt" values in the plot_config array inside your config file so that the sample planes of interest are clearly inside the arrow/pixel span limits. For example, suppose you have an OVF file with z-thickness of 20e-9 and 4 layers spaced 5e-9 apart. If you set "viewaxis,zarrowspan" to 5e-9 to select a single layer, then the z-value in "misc,centerpt" should be one of 2.5e-9, 7.5e-9, 12.5e-9, or 17.5e-9, depending on which layer you want to display. An alternative solution is to enlarge the arrow/pixel span slightly; this, however, may select multiple layers. (21-Feb-2008)
Problem: mmArchive complains that data from Oxsii or Boxsi is a "floating-point value too small to represent".
Solution: This bug is platform specific, but occurs throughout the ActiveTcl 8.3.x and 8.4.x releases on Windows. To fix, either replace oommf/app/oxs/output.tcl with this replacement file, or else apply this patch. (18-Mar-2009)
Problem: mmDisp abruptly stops displaying vectors when the Data Scale control is set above the default setting. (Reported by Mark Mascaro.)
Solution: If you are viewing files (e.g., *.omf) from disk, one workaround is to edit the header of each file and change the "ValueRangeMinMag" value to 0.0. If the data portion of the files are in binary mode, be careful to use an editor that will write out the modified file without corrupting the data block. For a complete fix, apply this patch. Since this bug affects the C++ code, rebuilding OOMMF is required. (8-May-2010)
Problem: When built on a Linux x86_64 (64-bit) platform, OOMMF reports the Platform Name to be "unknown".
Solution: First, run 'tclsh oommf.tcl pimake distclean' to remove any existing installation under the "unknown" platform name. Then apply this patch, and follow the usual build process. (11-May-2011)
Problem: When building under Tcl/Tk 8.5.x, OOMMF complains
Tk version mismatch: /usr/lib/tkConfig.sh from 8.5 Running Tk 8.5.5
Solution: Apply this patch. (11-May-2011)
Problem: When building OOMMF, pimake fails trying to update a tclIndex file with the error
wrong # args: should be "puts ?-nonewline? ?channelId? string"
Thanks to R.A. van Mourik for reporting this problem.
Solution: This problem occurs with some recent versions of Tcl, and arises from the (accidental) removal of support for some deprecated syntax. To fix, apply this patch. (3-Jun-2011)

Notes on patch files:
A number of patch files are provided above for fixing problems. After downloading a patch, exit all OOMMF applications and cd to the top-level OOMMF directory (i.e., the directory named "oommf"). Then run the command

patch -p1 < patchfile

where patchfile is the name of patch file. If there are any patch "rejects", then some hand-editing may be necessary, but this shouldn't happen if you are patching against an unmodified OOMMF distribution.

The command `patch' is a Unix text processing utility. A version of patch for Windows is available as part of the GnuWin32 project. (Unfortunately, there are some issues on Windows 7.) The GnuWin32 patch utility does not install by default into a directory in the executable path, and unless told otherwise expects patch files to use Windows/DOS-style line endings. So, with GnuWin32, the patch command should look like

"C:\Program Files\GnuWin32\bin\patch.exe" --binary -p1 <patchfile

(On 64-bit versions of Windows, GnuWin32 installs by default under "C:\Program Files (x86)".) If the patch only affects Tcl code (files ending in the .tcl extension), then after applying the patch you can restart OOMMF and be good to go. If the patch affects the C++ source (.cc or .h files), then follow the rebuilding instructions in the next section.

Rebuilding OOMMF:
Any file replacement or patch involving OOMMF C++ source (files with the .cc or .h extension) will necessitate a recompile and relink of OOMMF. Of course, this requires a suitable compiler. To rebuild, first edit the oommf/config/cache/platform.tcl file, where platform is the name of your platform (e.g., wintel), to select the compiler you want to use. For example, in the Windows binary releases of OOMMF 1.2a3, the oommf/config/cache/wintel.tcl file is configured to use the Intel C++ compiler, icl. To use the Microsoft C++ compiler instead, change

# Microsoft Visual C++ # #$config SetValue program_compiler_c++ {cl /nologo /c /GX /GR} # # Intel C++ $config SetValue program_compiler_c++ {icl /nologo /c /GX /GR}

# Microsoft Visual C++ # $config SetValue program_compiler_c++ {cl /nologo /c /GX /GR} # # Intel C++ #$config SetValue program_compiler_c++ {icl /nologo /c /GX /GR}

(With regards to this particular example, see Item 20 above.)

Once the appropriate compiler is specified, cd to the top-level OOMMF directory (i.e., the directory named "oommf"), and issue the commands:

tclsh oommf.tcl pimake distclean tclsh oommf.tcl pimake

The first command ("distclean") deletes all binary object files and executables, so the second command can rebuild from scratch. This is necessary if you were using an OOMMF binary release, because it is unlikely that the release binaries are compatible with your compiler/linker. If you built from source, then you should be able to bypass the "distclean" step. Additional instructions can be found in the installation section of the OOMMF User's Guide.

DISCLAIMER: This software was developed at the National Institute of Standards and Technology by employees of the Federal Government in the course of their official duties. Pursuant to Title 17 Section 105 of the United States Code this software is not subject to copyright protection and is in the public domain.

OOMMF is an experimental system. NIST assumes no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

We would appreciate acknowledgment if the software is used.

Back to the OOMMF 1.2 software page, or

The National Institute of Standards and Technology (NIST) is an agency of the U.S. Commerce Department.

Privacy policy / security notice / accessibility statement / Disclaimer / Freedom of Information Act (FOIA) /
No Fear Act Policy / ExpectMore.gov (performance of federal programs) / NIST Information Quality Standards /
Environmental Policy Statement

Date created: November 7, 2002 | Last updated: June 3, 2011 Contact: Webmaster