We welcome any feedback and will add frequently asked questions to future editions of this document.
Build fails with message relating to the file
macro_built_in_functions.txt OR Metview fails to start because it cannot connect to port/host
This issue can occur, often on laptops, when the IP loopback is not set up. The quickest way to fix this is to set the environment variable:
and then resume the build. This variable will also need to be set before starting Metview.
On OpenSuSE 12 & 13 systems, a better solution is to go into Yast | Network Settings | Hostname/DNS : the option Assign Hostname to Loopback IP should be checked.
I get these errors when the Divrot module is linked:
These errors occur if emoslib was built without ecCodes support. When you build emoslib, you're given the option to build it with ecCodes support, as which point you should say 'yes' and tell it where to find the ecCodes libraries. Once you've rebuilt emoslib with this option, Metview should be able to link correctly with it.
Problems linking with Intel tools
We've had a report that when using the Intel compiler, the linking of the DataCoverage module produces errors with defined symbols from libemos. This can be because the Intel C++ compiler does not know that it needs to link with the Intel Fortran libraries (a few of Metview's modules use some Fortran code). A solution is to add the following to your CMake command when configuring Metview:
[ifort8.1path] is replaced by the path to where the Intel fortran libraries are.
How should I build ecCodes for Metview?
See the answers to the next two questions.
I get error messages saying that I need the -fPIC option
By default, EmosLib and ecCodes are built without this option. It is, however, needed on some systems. The flag can be added to the ecCodes build options, for example like this:
./configure CFLAGS="-fPIC -O2" <other options>
For Emoslib, this flag can be added to the
CFLAGS variable in the relevant configuration file in the config directory. Once these have been rebuilt, you should be able to link properly.
I get the following error message when I try to read GRIB data in Metview: “ecCodes ERROR : Unable to find boot.def”
It is possible to check a ecCodes installation from the command line by finding a GRIB file and typing:
If this error message appears, then ecCodes is not properly installed, and there are two ways to solve the problem.
To rebuild, ecCodes should be configured with the --prefix option before it can find its resource files, for example:
./configure --prefix=/usr/local <other options>
Another option, which does not require a rebuild of ecCodes, is to change the value of the environment variable GRIB_DEFINITION_PATH. The command grib_info will tell you the current value. Normally, it should be set to
/usr/local/share/eccodes/definitions, but you should first check that this directory exists.
I get NetCDF problems when I run 'configure'
On some systems, the NetCDF libraries can be in non-standard locations. Once you have found the location of your libraries, you can pass this information to Metview's configure command, e.g.
./configure --with-netcdf=/opt/netcdf-4 <other options>
This will work as long as the directory structure is like:
Some systems have structures such as
/usr/include/netcdf/ for the header files. In this case, it is best to pass these paths via variables to configure, e.g.
./configure CXXFLAGS=”-I/usr/include/netcdf” <other options>
If the library files are in a non-default location, then you will also need to supply this, e,g,
./configure LDFLAGS=”-L/usr/lib/netcdf” <other options>
Can I install Metview 4.x in the same directory as I have installed Metview 3.x?
Yes, it should be possible. The executables have different names for configuration files and use different directories (share instead of coast). You might however prefer a clear separation if you start to phase out Metview 3.
Should Metview 3 users start Metview 4 in a new user directory?
This is not necessary, as Metview 4 uses a different subdirectory for its system files (
<metview-home>/System instead of
<metview-home>/Metview). Icons which are valid only in Metview 3 will not be visible in Metview 4, and vice-versa, hence the two versions should live together without problems. However, if your users wish to make a clear separation, they can start Metview 4 with the '-u' option, for example: metview -u ~/metview4.
How can I report bugs or ask for help?
Please write an email to firstname.lastname@example.org . Please compress any larger files you might need to attach.