Current Issues

Below is an overview of currently known issues for each of the downloadable packages.

BEAT

Read errors with GOME-2 L1 files

Counter to what is stated in v9A of the GOME-2 L1 Product Format Specification document, GIADR records will not always occur just once in a product. They can be optional, or even occur twice. Because of this, you may encounter errors (such as "ERROR: trying to read beyond the end of the file") when trying to access such GOME-2 L1 files with BEAT/CODA.

An updated codadef that fixes this problem has already been created (but it is not yet included in the current BEAT and VISAN packages). You can update the codadef file manually by downloading the updated CODA definition file EPS-20120109.codadef and use it to replace the old version of the EPS codadef file in your installation. The directory of the CODA definition files (using the default installation prefix) is:

If you installed both BEAT and VISAN you will have to update the codadef file in both installations.

In addition, EUMETSAT already indicated that they will provide updates to the PFS documents to reflect to correct occurence rate of GIADRs in a product.

Problem compiling BEAT against static HDF4 libraries

When compiling BEAT with HDF4 enabled, and where HDF4 is build with only static libraries (which is the default), BEAT may provide the following error during compilation:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 -W -Wall -static -L/usr/local/lib -o codacheck codacheck.o libcoda.la 
libtool: link: gcc -g -O2 -W -Wall -o codacheck codacheck.o  -L/usr/local/lib ./.libs/libcoda.a -lz /usr/local/lib/libjpeg.so
Undefined symbols:
  "_GRreftoindex", referenced from:
      _init_hdf4Vgroups in libcoda.a(libcoda_la-coda-hdf4-definition.o)
  "_VFnfields", referenced from:
      _init_hdf4Vdatas in libcoda.a(libcoda_la-coda-hdf4-definition.o)
  "_SDend", referenced from:
      _coda_hdf4_close in libcoda.a(libcoda_la-coda-hdf4-definition.o)
  "_GRstart", referenced from:
      _coda_hdf4_open in libcoda.a(libcoda_la-coda-hdf4-definition.o)

This is due to an issue with 'libtool', a tool to deal with shared/static libraries and which is used by various open source packages (including BEAT).

There are (at least) three ways of working around this problem:

"cannot open shared object" errors in IDL/MATLAB interface on Linux

If you install BEAT in the default location (/usr/local/) on Linux then on some systems you will first have to run the ldconfig tool, without parameters, as root to update the cache of installed libraries. If you do not do this then the CODA, BEAT-I and BEAT-II libraries that are installed in /usr/local/lib will not be accessible by the IDL and MATLAB interface modules that link to them and you will therefore get an error if you try to run the IDL/MATLAB interfaces.

BEAT IDL interface on Linux - problems with HDF files containing zipped data

In October 2008 an issue was found with the use of the BEAT IDL interface on Linux. This had been fixed for most cases with the BEAT 6.0.1 release. However, there is still a case where you will encounter problems, which is when you try to use BEAT to read data that is stored in zip compressed form in HDF4 or HDF5 files.

The problem has to do with an incompatibility with the zip library that comes with IDL and the one that is publicly available. We have contacted ITTVIS about this situation and they have confirmed that it is an issue with IDL (7.0). The issue was tracked under Change Request number CR54835 within ITTVIS. It has yet to be verified whether the latest version of IDL contains a fix for the issue.

If you are using the BEAT-II interface of IDL to read data from an HDF file that contains zipped data then there is a possible workaround: You can use the beatl2dump tool to perform the ingestion and export this to a file:

beatl2dump binary -o data.bl2 product.hdf
(you can use the -f option to provide an ingestion filter)

You can then import the data.bl2 file in IDL using:

>>> beatl2_import('binary', 'data.bl2')

Note that this issue was only seen on Linux. It has been verified that it does not affect the BEAT IDL interfaces for Windows and Mac OS X. Whether other platforms (such as Solaris) are affected is unknown.

VISAN

VISAN won't run on Windows 2000

On Windows 2000 VISAN can terminate with the error 'Interpreter exited due to an exception'.

The problem is most likely due to a missing .dll (gdiplus.dll) on the system.

To install this dll, download the redistributable files for GDI+ from the Microsoft website.

When running the application choose a temporary location where the application can extract its files. Then, from the extracted files, copy the file asm\10\msft\windows\gdiplus\gdiplus.dll to the bin directory of your VISAN installation (e.g. C:\VISAN\bin). You can remove the extracted files afterwards.

VISAN crashes on Linux during startup

On some Linux systems VISAN can crash shortly after showing the startup splash screen.

The issue is most likely due to an issue in wxPython. This issue has already been raised to the wxWidgets team under ticket number #3871.

If you are affected by this issue you can disable showing of the splashscreen as a workaround. To do this, edit the file VisanApp.py that is located in the subdirectory lib/python2.6/site-packages/visan of your VISAN installation and just remove line #155 (containing the text 'self._CreateSplashScreen()').

Scientific Tutorial

There are currently no known issues.

GeoFit

There are currently no known issues.