Metview's documentation is now on readthedocs!

Please go to https://metview.readthedocs.io/en/latest/

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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:

METVIEW_LOCALHOST=1

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:

CXXLD  bin/Divrot
../../lib/libMars.a(lib_libMars_a-pproc.o): In function `ppintf':
/build/src/libMars/pproc.c:459: undefined reference to `intf2'
../../lib/libMars.a(lib_libMars_a-pproc.o): In function `makeuv':
/build/src/libMars/pproc.c:858: undefined reference to `intuvs2_'
/build/src/libMars/pproc.c:851: undefined reference to `intuvp2_'
../../lib/libMars.a(lib_libMars_a-pproc.o): In function `vector_postproc':
/build/src/libMars/pproc.c:672: undefined reference to `intvect2_'

 

These errors occur if emoslib was built without GRIB_API support. When you build emoslib, you're given the option to build it with GRIB_API support, as which point you should say 'yes' and tell it where to find the GRIB_API 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:

-DCMAKE_EXE_LINKER_FLAGS="-L[ifort8.1path]/lib -lifcore"

where [ifort8.1path] is replaced by the path to where the Intel fortran libraries are.


How should I build GRIB_API 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 GRIB_API are built without this option. It is, however, needed on some systems. The flag can be added to the GRIB_API 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: “GRIB_API ERROR : Unable to find boot.def”

It is possible to check a GRIB_API installation from the command line by finding a GRIB file and typing:

 grib_ls <path/to/grib/file>

If this error message appears, then GRIB_API is not properly installed, and there are two ways to solve the problem.

To rebuild, GRIB_API 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 GRIB_API, 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/grib_api/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:

<with-netcdf>/include, <with-netcdf>/lib.

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 metview@ecmwf.int . Please compress any larger files you might need to attach.

 

  • No labels