wrf-cmake / wps Goto Github PK

Currently, link_grib.py does not behave the same as link_grib.csh from a CLI argument perspective. E.g. link_grib.csh also accepts a list of filenames, typically provided via shell expansion (foo_*), where link_grib.py only accepts a folder.

E.g. calc_ecmwf_p.exe is installed in root, but should be under util/.

At some point we added the following log statement:

And here:

This was only used for debugging and should probably be removed again.

Similarly to WRF-CMake/wrf#10, add support to compile in release mode with debug info.

To be consistent with other repos/projects, we should modify the licence text to:

# WRF-CMake (https://github.com/WRF-CMake/WPS).
# Copyright 2018-2019 M. Riechert and D. Meyer. Licensed under the MIT License.

I installed WRF & WPS using brew successfully. I tried to implement them in GIS4WRF with MPI [n=2]. Clicking [Run Geogrid] reported 'PMIX ERROR: ERROR in file gds_ds12_lock_pthread.c at line 206'. However, it still reported '! Successful completion of geogrid. !' The same error was reported when I clicked [Run Metgrid] and [Run Real].
My OS is macOS 10.15. I attached the log file from Geogrid. Thank you.
geogrid.log.0000.zip

Using the command line, export PMIX_MCA_gds=hash can fix the issue. However, how can we address this when we try to run WRF & WPS in GIS4WRF?

A change in HDF5 imposes DEBUG/NDEBUG preprocessor definitions onto its consumers (like us, indirectly via NetCDF):

target_compile_definitions(${HDF5_LIB_TARGET}
    PUBLIC
        ${HDF_EXTRA_C_FLAGS}
        ${HDF_EXTRA_FLAGS}
        $<IF:$<CONFIG:Debug>,DEBUG,NDEBUG>
    PRIVATE
        $<$<BOOL:${HDF5_ENABLE_TRACE}>:"H5_DEBUG_API">  # Enable tracing of the API
        $<$<BOOL:${HDF5_ENABLE_DEBUG_APIS}>:"H5Z_DEBUG;H5T_DEBUG;H5ST_DEBUG;H5S_DEBUG;H5O_DEBUG;H5I_DEBUG;H5HL_DEBUG;H5F_DEBUG;H5D_DEBUG;H5B2_DEBUG;H5AC_DEBUG">
)

This is a big problem as the string DEBUG in any preprocessed source code would be replaced by an empty string. Having NDEBUG defined is normal as that's a convention, but DEBUG is a very general term. For WPS, it breaks the build because that identifier is used:

We're currently experiencing this problem as MSYS2 updated its HDF5 package, picking up the change. A temporary work-around is to undefine the DEBUG preprocessor definition via -UDEBUG.
We will have to keep the work-around for quite a while though (forever?) as we won't know which version people will be using. Looking at the release dates of HDF5, affected versions are >= 1.10.3.

Tested with: wps-cmake-4.1.0-basic_nesting-serial-x64-linux-release.tar.xz
The executables under util directory doesn't define the RPATH on the binary dynamic section.
For example util/calc_ecmwf_p.exe:

$  objdump -p util/calc_ecmwf_p.exe
....
Dynamic Section:
  NEEDED               libgfortran.so.5
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
....

[some output ommited]

It can be fixed like:

$ patchelf --force-rpath --set-rpath "\$ORIGIN/../.libs" --replace-needed libgfortran.so.5 libgfortran-2e0d59d6.so.5.0.0 util/calc_ecmwf_p.exe
$ objdump -p util/calc_ecmwf_p.exe
.....
Dynamic Section:
  RPATH                $ORIGIN/../.libs
  NEEDED               libgfortran-2e0d59d6.so.5.0.0
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6

the fixing includes also to point the right SO.

Regards

(from GIS4WRF/gis4wrf#163 (comment))

geogrid.exe ERROR: Could not open C:\Users\First Last\Documents\gis4wrf\datasets\geog/topo_gmted2010_5m/index

The file exists, and using only paths without whitespaces works around the issue.

This is mostly copying the compiler config files from WRF-CMake.