Next: Credits Up: OOMMF Documentation Previous: The OVF 2.0 format

Troubleshooting

The OOMMF developers rely on reports from OOMMF users to alert them to problems with the software and its documentation, and to guide the selection and implementation of new features. See the Credits for instructions on how to contact the OOMMF developers.

The more complete your report, the fewer followup messages will be required to determine the cause of your problem. Usually when a problem arises there is an error message produced by the OOMMF software. A stack trace may be offered that reveals more detail about the error. When reporting an error, it will help the developers diagnose the problem if users cut and paste into their problem report the error message and stack trace exactly as reported by OOMMF software. In addition, PLEASE include a copy of the output generated by tclsh oommf.tcl +platform; this is important because it will help OOMMF developers identify problems that are installation or platform dependent.

Before making a report to the OOMMF developers, please check the following list of fixes for known problems. Additional problems discovered after release will be posted to version specific ``patch'' pages at the OOMMF web site.

When compiling, there is an error about being unable to open system header files like stdlib.h, time.h, math.h, or system libraries and related program startup code. This usually indicates a bad compiler installation. If you running on Windows and building with the the Microsoft Visual C++ command line compiler, did you remember to run vcvars32.bat to set up the necessary environment variables? If you are using the Borland C++ compiler, are the bcc32.cfg and ilink32.cfg files properly configured? In all cases, check carefully any notes in the chapter Advanced Installation pertaining to your compiler.
When compiling, there is an error something like:
```
<30654> pimake 1.x.x.x MakeRule panic:
Don't know how to make '/usr/include/tcl.h'
```
This means the header file tcl.h is missing from your Tcl installation. Other missing header files might be tk.h from the Tk installation, or Xlib.h from an X Window System installation on Unix. In order to compile OOMMF, you need to have the development versions of Tcl, Tk, and (if needed) X installed. The way to achieve that is platform-dependent. On Windows you do not need an X installation, but when you install Tcl/Tk be sure to request a ``full'' installation, or one with ``header and library files''. On Linux, be sure to install developer packages as well as user packages. Other platforms are unlikely to have this problem. In the case of Xlib.h, it is also possible that the tkConfig.sh file has an incorrect entry for TK_XINCLUDES. A workaround for this is to add the following line to your oommf/config/platforms/platform file:
```
$config SetValue TK_XINCLUDES "-I/usr/X11R6/include"
```
Adjust the include directory as appropriate for your system.
When compiling, there is an error indicating that exceptions are not supported.
Parts of OOMMF are written in C++, and exceptions have been part of the C++ language for many years. If your compiler does not support them, it is time to upgrade to one that does. OOMMF 1.2 requires a compiler capable of compiling source code which uses C++ exceptions.
Compiling with gcc produces syntax errors on lines involving auto_ptr templates.
This is known to occur on RedHat 5.2 systems. The auto_ptr definition in the system STL header file memory (located on RedHat 5.2 systems in the directory /usr/include/g++) is disabled by two #if statements. One solution is to edit this file to turn off the #if checks. If you do this, you will also have to fix two small typos in the definition of the release() member function.
When compiling there is an error message arising from system include directories being too early in the include search path. Try adding the offending directories to the program_compiler_c++_system_include_path property in the platform file, e.g.,
```
$config SetValue program_compiler_c++_system_include_path \
      [list /usr/include /usr/local/include]
```
On Solaris, gcc reports many errors like
ANSI C++ forbids declaration `XSetTransientForHint' with no type

On many Solaris systems, the header files for the X Window System are not ANSI compliant, and gcc complains about that. To work around this problem, edit the file oommf/config/platforms/solaris.tcl to add the option -fpermissive to the gcc command line.
On Windows, when first starting oommf.tcl, there is an error:
```
Error launching mmLaunch version 1.x.x.x:
        couldn't execute "...\omfsh.exe": invalid argument
```
This cryptic message most likely means that the pre-compiled OOMMF binaries which were downloaded are for a different version of Tcl/Tk than is installed on your system. Download OOMMF again, taking care this time to retrieve the binaries that match the release of Tcl/Tk you have installed.
When first starting oommf.tcl, there is an error:
Error in startup script: Neither Omf_export nor Omf_export_list set in

The file oommf/pkg/net/omfExport.tcl may be missing from your OOMMF installation. If necessary, download and install OOMMF again.
When launching oommf.tcl on Unix systems, there is an error of the form:
error while loading shared library: libtk8.4.so: cannot open shared object file: No such file or directory

This typically happens because the libtk#.#.so (and/or libtcl#.#.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, include
```
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
```
in your ~/.bashrc file (bash shell users) or
```
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/usr/local/lib
```
in 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.
When starting OOMMF in the Cygwin environment on Windows, the mmLaunch window appears briefly, then disappears without any error messages.
Some old versions of Tcl/Tk included with the Cygwin environment (i.e., /usr/bin/tclsh) had bugs in the socket code that caused OOMMF to crash in this manner. This problem is fixed in current Cygwin releases.
I ran out of memory!
Are you using mmGraph to monitor a long-running simulation? All data sent to mmGraph is kept in memory by default. See the mmGraph documentation for information on how to manage this problem.
When running many OOMMF applications, some of them become non-responsive.
Operating systems place an upper limit on the number of files a process may have open at one time. The number varies, but the default count is usually a few hundred to perhaps a few thousand. OOMMF applications communicate with one another across localhost sockets. Each socket connection counts as an open file, so if you are running hundreds of OOMMF applications under one account you may hit this limit. You can explore increasing the open file limit (e.g., on Linux and macOS see the -n option to ulimit), but a more robust solution is to divide your collection of OOMMF jobs into several smaller independent groups and run each group under separate host + account servers with the launchhost utility.

OOMMF Documentation Team
September 30, 2022