--General--

Problem::

When I start Cubit, I get a warning like: "WARNING: Unable to set STEPTOOLS path...".  Later, when I try to import or export a STEP model, the import/export fails.
 

Solution::

The directory structure that contains the step translator (usually libs/<machine_type>) must be writable by the person running Cubit.  Change the permissions on the directory structure--that should fix the problem.
 

Problem::

When I start Cubit, I get a warning like: "Fatal Error: Cannot map library libhealhusk.so"
 

Solution::

You didn't read the download instructions.  In each download directory it states that you must download the cubit*.gz file, AND the acis*.gz file.  Go back and do what the instructions say, and that should fix your problem.

--Sun Solaris--

Problem::

When I try to start Cubit, I get the following error:  "ld.so.1: /Cubit/cubit_SUN.6.0_exe:fatal: libxgl.so.3: open failed: No such file or directory".
 

Solution::

Solaris 8 does not provide by default a libxgl library.  6.0 and older versions of Cubit were linked against this library, so when Cubit tries to run and doesn't find the library, it fails.  To fix this, either move to a later version of Cubit, or download a dummy libxgl library to satisfy this dependency.  The link to download the library is http://wwwwswest.sun.com/technical-computing/ISV/libxgl.so.3 .  If you have root access, download it to the following location:
/opt/SUNWits/Graphics-sw/xgl/lib/libxgl.so.3
and make sure it is readable by everyone.

 If you don't have root access, download it in any directory (e.g. $HOME/xgl_dummy_lib) and then add that directory to your LD_LIBRARY_PATH environment variable before running CUBIT.

Note that this dummy library doesn't actually allow you to use XGL graphics (which isn't a big loss).  It just allows Cubit to run with the normal OpenGL or X-Windows graphics.
 

--Compaq/DEC Alpha--

Problem::

I downloaded Cubit and installed it correctly, but now I get an error after the splash screen that says something like "Bad system call(coredump)".  What's up with that?
 

Solution::

The most likely reason you're getting this problem is using an older version of the operating system.  The version of Cubit that we support on the Alpha platform runs on Tru64 Unix version 5.0 and higher.  If you're using Dec Unix 4.0x then you will probably have this problem.

--HP--

--Windows--

Problem::

I'm running Cubit on Windows NT, and my machine gets progressively slower every time I start a new Cubit session. What's happening?

Solution::

We've seen some memory problems with Windows NT. It seems as if NT doesn't release memory from a closed application like it's supposed to. We have not been able to reliably track this problem, but people who have reported the problem also reported that it has gone away with an upgrade to Windows 2000.

--SGI--

Problem::

When starting, cubit prints out error message, complaining that it can't find the "libhealhusk.so" even though the ./libs does exist, and the cubit script does find the path.
 

Solution::

When I remove lines pertaining to "modules" in the .cshrc file, for instance:

        if (-f /opt/modules/modules/init/csh ) then
           source /opt/modules/modules/init/csh
           module load modules nqe mpt
        endif

  Then cubit starts without problem.
 

--Linux---

 

Problem::

When I try to run Cubit on Linux , it complains about my not having the library libstdc++-libc6.1-2.so.3.
 

Solution::

One of our vendor libraries is linked against this version of the standard C++ libraries. You should be able to create a soft link from your version of the library to the one that is needed. For example, if you have a library /usr/lib/libstdc++-lib6.1-1.so.2, which is typical for RedHat 6.2, you would type (as root) ln -s /usr/lib/libstdc++-libc6.1-1.so.2 libstdc++-libc6.1-2.so.3 in your /usr/lib directory.  The correct libraries for the systems that we have current information are:
RedHat 6.2,  libstdc++-libc6.1-1.so.2
RedHat 7.1,  libstdc++-libc6.1-1.so.2

Note that if you can't do this as root you could also make the link in the libs directory that resides in your Cubit installation directory.
 

Problem::

I tried the previous fix, but now I get an interrupt whenever I try to run Cubit.
 

Solution::

The version of the libstdc++ library which you linked against is incompatible with the version of Cubit you are using.  Try creating the link, as in the previous solution, to a later version of the library.  For example, if you linked against libc6.1-1.so.2, try linking against libc6.2-2.so.2 instead.
 

Problem::

When I try to run Cubit on Linux, it complains  "Command not found".
 

Solution::

The Cubit script depends on ksh being installed.  RedHat doesn't install this automatically, some other distributions do.  For RedHat, install the rpm called pdksh****.rpm.  For your distribution, find out the rpm or package that will supply this shell, and  install it.
 

Problem::

When I try to run Cubit on Linux with an NVIDIA Quadro 4 graphics card, all I get is :

 Machine type is Linux 2.4.7-10smp
 Machine name is somemachine.someplace.net
 HOOPS Version 6.20-1
 Displaying on :0.0 using X11 driver.
 Now in Volume picking mode.
 ...Interrupt Detected. CUBIT Exiting...
 ...Interrupt Detected. CUBIT Exiting...
 

Solution::

The NVIDIA drivers don't like the normal x11 mode of running Cubit.  You will need to either remember to use opengl mode all the time (by typing cubit_LINUX.7.0.5 -driver opengl), or edit the cubit startup script (usually something like cubit_LINUX.7.0.5) to add the opengl driver by default:
Change the line that says:
${CUBIT_EXE} "$@"
to instead say:
${CUBIT_EXE} -driver opengl "$@"