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

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}

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

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

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