Several users of SPIS have observed some difficulties during the loading of the VTK modules of SPIS on some very recent or up-to-date computers. The error message is generally: "Impossible to load the VTK module XXX..."

This may be due to several reasons:

a) On Linux, the problem probably may appears if you use a 64bit version for the JVM. This is due to the JNI layer, between VTK (C++) and SPIS (JAVA), which is very sensitive on both the JVM version and the fact to be in 32 or 64 bits.

The general rule is:

• The version of the JVM used to run a JNI component should be equal or higher than the version used to compiled it.
• If the JNI layer has been compiled in 32 bits, it should be used in 32 bits (and idem for 64 bits).

The VTK distribution provided with the current verion of SPIS (3.6) has been compiled with JVM 1.5, 32 bits of SUN, which is provided in the ThirdPart directory of SPIS.

Please notice, that if you run SPIS-UI with a new JVM, the Jython scripts may completely be re-compiled into new Java classes and breaks the compliance with the JNI layer. If you come back to your old JVM, sometimes the classes files are not properly re-compiled and the disturbances may continue to appear. To avoid this, please clean all *py.class files using in the SPIS-UI directory the clean.sh scripts as follow:

sh clean.sh

A migration to 64 bits, JVM 1.6 and VTK 5.0 is currently under process, but we still need to clean up one very old module of SPIS before.

b) Under windows, the observed problems seems depend of some system updates (not identified however) and/or if you have another VTK installation (typically an installation of Paraview outside SPIS) that overload the environment variable and more especially the PATH.

The problem apparently appears when the PATH and sometimes the LD_LIBRARY_PATH, used for the dynamical loading of native libraries like VTK, points toward a wrong directory for VTK. Please check this value and remove all references to other VTK installation.

These questions and feedbacks have been initially submitted by Bjarne Andersson (ESA/ESTEC) and Simon Clucas (ESA/ESTEC).

Best, Ju.