OOMMF OOMMF 1.2a3 Known Problems


Information on applying patches is given below. You can apply them individually, or apply this composite patch which contains all the patches up through and including item 21 (17-Dec-2004). Note that there are no patches for resolving items 1, 4, 14 and 15.

  1. 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.

  2. 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)

  3. 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.

  4. 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)

  5. 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)

  6. 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)

  7. 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)

  8. 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)

  9. 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)

  10. 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)

  11. 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)

  12. 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)

  13. 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)

  14. 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.

  15. 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)

  16. 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)

  17. 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)

  18. 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)

  19. 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)

  20. 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. (22-Oct-2004)

  21. 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)

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. 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

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}
to
# 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.

Commercial equipment and software referred to on these pages are identified for informational purposes only, and does not imply recommendation of or endorsement by the National Institute of Standards and Technology, nor does it imply that the products so identified are necessarily the best available for the purpose.


Back to the OOMMF 1.2 software page, or OOMMF project at NIST

michael.donahue@nist.gov
17-Dec-2004