...
| Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Possible problems
| Info | ||
|---|---|---|
| ||
OpenIFS support: openifs-support@ecmwf.int. |
| Note | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
Possible issues with the Cray systems (using cce or gnu compilers) are related to building shared libraries and linking with supporting netcdf and python libraries. 1. If problems occur, first try using the option "--disable-shared" (configure) or "-DBUILD_SHARED_LIBS=OFF") to only build statically linked libraries. 2. If linking problems still occur, try unloading the Cray ATP module which has been known to cause problems.
3. -llibm link error. If the following occurs:
set the environment variable CRAYPE_LINK_TYPE=dynamic (or add the compiler option '-dynamic'). 4. Missing python library If this error occurs when compiling _gribapi_swig.so:
it means the directory path of the python library is not on the linkers list of directories to search. Make sure the python module is loaded. Then check any PYTHON environment variables set by the module and confirm the location of the libpython (or other version) library. Set the environment variable LIBRARY_PATH to the correct directory so that the linker can find it:
|
| Note | ||
|---|---|---|
| ||
We currently recommend not using a higher optimization level than -O1 with the Intel compiler. Failures have been seen with grib_api and the Intel compiler when compiled with -O2. Some versions of the Intel compiler (v14.0.x) can produce an error "unknown option -soname" when using 'configure. If this occurs try using "--disable-shared" or try the cmake command instead. |
| Note | ||
|---|---|---|
| ||
For the IBM xlc compiler we recommend disabling the creation of 'shared libraries' which is known to cause problems with some versions of grib_api. In this example, note the use of the '_r' form of the IBM compiler to ensure grib_api is compiled 'thread-safe'. |
Compiling, checks and installing
After configuration the next steps are to compile grib-api and install it. To compile grib_api do:
| Code Block |
|---|
make | tee make.out |
which will send all the output from the make command to the file 'make.out' as well as the terminal. This is recommended as the output is lengthy.
| Info | ||
|---|---|---|
| ||
If using cmake, it will normally hide all the output from the compile commands. If you want to see the compile command (to check the compile options), do: make VERBOSE=1 |
| Info | ||
|---|---|---|
| ||
If your computer has multiple cores as many, use the -j flag to make to build grib_api faster. e.g.
|
Next, to verify grib_api works correctly run:
| Code Block |
|---|
make check | tee check.out |
Verify that all the grib_api tests have passed. If not, go back and check your configure options. In case of difficulty, contact Software.Support@ecmwf.int.
Compiling, checks and installing
After configuration the next steps are to compile grib-api and install it. To compile grib_api do:
| Code Block |
|---|
make | tee make.out |
which will send all the output from the make command to the file 'make.out' as well as the terminal. This is recommended as the output is lengthy.
| Info | ||
|---|---|---|
| ||
If using cmake, it will normally hide all the output from the compile commands. If you want to see the compile command (to check the compile options), do: make VERBOSE=1 |
| Info | ||
|---|---|---|
| ||
If your computer has multiple cores as many, use the -j flag to make to build grib_api faster. e.g.
|
Next, to verify grib_api works correctly run:
| Code Block |
|---|
make check | tee check.out |
Verify that all the grib_api tests have passed. If not, go back and check your configure options. In case of difficulty, contact Software.Support@ecmwf.int.
Finally, to install grib_api do:
| Code Block |
|---|
make install | tee install.out |
At the end of this step, in the directory $HOME/ecmwf/ we are using in this example you should now have a directory called grib_api (or some other compiler suffix) which contains the following:
| Code Block |
|---|
% ls grib_api
bin include lib share
% ls grib_api/lib
libgrib_api.a libgrib_api.la libgrib_api_f77.a libgrib_api_f77.la libgrib_api_f90.a libgrib_api_f90.la pkgconfig |
After this stage, next steps are to download and install FCM and then download the OpenIFS code and accompanying files.
Possible problems
| Info | ||
|---|---|---|
| ||
OpenIFS support: openifs-support@ecmwf.int. |
| Note | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
Possible issues with the Cray systems (using cce or gnu compilers) are related to building shared libraries and linking with supporting netcdf and python libraries. 1. If problems occur, first try using the option "--disable-shared" (configure) or "-DBUILD_SHARED_LIBS=OFF") to only build statically linked libraries. 2. If linking problems still occur, try unloading the Cray ATP module which has been known to cause problems.
3. -llibm link error. If the following occurs:
set the environment variable CRAYPE_LINK_TYPE=dynamic (or add the compiler option '-dynamic'). 4. Missing python library If this error occurs when compiling _gribapi_swig.so:
it means the directory path of the python library is not on the linkers list of directories to search. Make sure the python module is loaded. Then check any PYTHON environment variables set by the module and confirm the location of the libpython (or other version) library. Set the environment variable LIBRARY_PATH to the correct directory so that the linker can find it:
|
| Note | ||
|---|---|---|
| ||
We currently recommend not using a higher optimization level than -O1 with the Intel compiler. Failures have been seen with grib_api and the Intel compiler when compiled with -O2. Some versions of the Intel compiler (v14.0.x) can produce an error "unknown option -soname" when using 'configure. If this occurs try using "--disable-shared" or try the cmake command instead. |
| Note | ||
|---|---|---|
| ||
For the IBM xlc compiler we recommend disabling the creation of 'shared libraries' which is known to cause problems with some versions of grib_api. In this example, note the use of the '_r' form of the IBM compiler to ensure grib_api is compiled 'thread-safe'. |
| Info | ||
|---|---|---|
| ||
Some HPC batch systems have a different hardware architecture for their login (or frontend node) to the batch node, but the frontend compilation system is targeted at the batch nodes. This is known as cross-compilation. If this is the case you may see failures in the 'make check' stage because the checks, although compiled for the backend batch nodes, are being run on the frontend nodes | ||
| Info | ||
| ||
Some HPC batch systems have a different hardware architecture for their login (or frontend node) to the batch node, but the frontend compilation system is targeted at the batch nodes. This is known as cross-compilation. If this is the case you may see failures in the 'make check' stage because the checks, although compiled for the backend batch nodes, are being run on the frontend nodes and therefore may not work correctly. If this is the case on your system, we recommend using a batch job to do the 'configure; make; make check; make install' steps. In some cases, the batch system cannot be used for compilation at all. In this case, you have to compile on the frontend but without extra flags 'configure' will assume the build is for the frontend. You can make use of the --host option to ensure the build is correct for the architecture of the batch system. Again though, the tests will fail, a small serial batch job is recommended to make sure grib_api is installed correctly. Note if you plan on using the grib_api software in your own software that runs on the frontend nodes you will need to install grib_api twice; one for the batch system and again for the frontend system. If you have any questions installing grib_api in this type of environment, please contact: openifs-support@ecmwf.int for assistance. |
Finally, to install grib_api do:
| Code Block |
|---|
make install | tee install.out |
At the end of this step, in the directory $HOME/ecmwf/ we are using in this example you should now have a directory called grib_api (or some other compiler suffix) which contains the following:
| Code Block |
|---|
% ls grib_api
bin include lib share
% ls grib_api/lib
libgrib_api.a libgrib_api.la libgrib_api_f77.a libgrib_api_f77.la libgrib_api_f90.a libgrib_api_f90.la pkgconfig |
...
of the batch system. Again though, the tests will fail, a small serial batch job is recommended to make sure grib_api is installed correctly. Note if you plan on using the grib_api software in your own software that runs on the frontend nodes you will need to install grib_api twice; one for the batch system and again for the frontend system. If you have any questions installing grib_api in this type of environment, please contact: openifs-support@ecmwf.int for assistance. |
Verify the installation
To verify that the installation was successful, first ensure that the grib_api bin directory is added to your PATH environment variable and then run the grib_info command e.g.
...