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 26
(12-Dec-2006). 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.
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/tracker/?func=detail&aid=1071807&group_id=10894&atid=110894
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/tracker/index.php?func=detail&aid=1602208&group_id=10894&atid=110894
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)
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
michael.donahue@nist.gov
21-Feb-2008