[INSTALL] nceplibs-bufr v11.6.0

[jbathegit]

Note: Please search to see if an issue already exists for the software you are requesting to be installed.

Which software in the stack would you like installed?
This is the next release version of the nceplibs-bufr library, which is already part of hpc-stack. It is available from https://github.com/NOAA-EMC/NCEPLIBS-bufr/releases/tag/bufr_v11.6.0

What is the version/tag of the software?
https://github.com/NOAA-EMC/NCEPLIBS-bufr/tree/bufr_v11.6.0

What compilation options would you like set?
Give a detailed list of compilation options, compiler and MPI flavors and versions, etc.

Which machines would you like to have the software installed?
All HPC machines where bufr_v11.5.0 and earlier versions are currently installed. In particular, there are developers on WCOSS2 (cactus, dogwood, acorn) waiting for the release of the new v11.6.0

Any other relevant information that we should know to correctly install the software??
The build and install instructions are in the README.md file at https://github.com/NOAA-EMC/NCEPLIBS-bufr.

Additional context
When working with the NCO SPA office to install this package on WCOSS2, please ask them to:

• Remove all of the environment variable definitions for BUFR_INC[48d]_DA and BUFR_LIB[48d]_DA, since _DA builds are no longer available beginning with v11.6.0
• Add the following environment variable definitions to the new bufr/11.6.0 module file:
  • DEBUFR=$bufr_ROOT/bin/debufr.x
  • XBFMG=$bufr_ROOT/bin/xbfmg.x

[aerorahul]

@jbathegit

We append CMAKE_INSTALL_PREFIX/bin to the PATH variable in the modulefile.
All bufr utilities are thus available on the command-line once the module is loaded

Adding variables such as DEBUFR and XBFMG is discontinued practice. We didn't have these before and I don't recommend adding it now.
Users in their scripts should not have to rely on these variables in the environment. They can define it in their use by doing this:

module load bufr/11.6.0
DEBUFR=$(which debufr.x)
XBFMG=$(which xbfmg.x)

For e.g. when netcdf is loaded, netCDF utilities such as ncdump, ncgen are automatically available. There is no need to define these in the modulefile individually.

[jbathegit]

OK, I'm fine with that approach, and in which case you can skip my request to add those new envvars. If the bin subdirectory is prepended to $PATH, then the which command will certainly do the trick to locate those executables, as you noted.

Please do make sure to remove all of the _DA envvars though. Those are defined in the existing module file for v11.5.0, but they'll no longer exist with v11.6.0+

[kgerheiser]

Done on Jet, Orion, Gaea.

[kgerheiser]

I manually removed the _DA variables, but there should be a way to automate it. I think it's possible to do an if within the .lua, but I have to figure out the specifics.

[jbathegit]

@aerorahul @kgerheiser

I just took a look at the new bufr/11.6.0 module on WCOSS2, and it still contains setenv commands for BUFR_INC[48d]_DA and BUFR_LIB[48d]_DA. As a reminder, there are no longer any _DA builds with v11.6.0+ so could we please get those environment variable definitions removed from that module?

Or is there someone else I/we should talk to about this?

[christopherwharrop-noaa]

@kgerheiser / @climbfuji - I need this one (bufr-11.6.0) on Cheyenne as well. Would that be easy to do?

[climbfuji]

@christopherwharrop-noaa Given the switch to the EPIC-maintained hpc-stack in PR ufs-community/ufs-weather-model#1146 - to be committed today or tomorrow - is this still needed in the old location (/glade/p/ral/jntp/GMTB/...)?

[christopherwharrop-noaa]

@climbfuji - I don't know anything about old/new location. I need it installed in the location of the stack that is used by the ufs-community, which it looks like that PR is doing. Is bufr-11.6.0 installed in the new location?

[christopherwharrop-noaa]

@climbfuji - Wait a second.... That PR is updating modulefiles for the ufs-weather-model, not the app. So, I need bufr-11.6.0 installed in the location used by ufs-community/ufs-srweather-app. I don't know if there is a PR to update the ufs-srweather-app's env files, but right now they point to the old location.

[christopherwharrop-noaa]

@climbfuji - This also raises the question about where to send/open issues. If the UFS is going to use EPIC-maintained hpc-stack installations on various platforms, where/how do we send issues/requests? I'm assuming there will be EPIC folks monitoring issues here on the hpc-stack github site?

[climbfuji]

Yes, they will. Also, the srweather app should try to update to the new location as soon as this is possible. The hpc-stack changes in the ufs-weather-model are made in preparation for the SRW App public release as far as I know.

…

On Mar 31, 2022, at 8:21 AM, Christopher Harrop ***@***.***> wrote: @climbfuji <https://github.com/climbfuji> - This also raises the question about where to send/open issues. If the UFS is going to use EPIC-maintained hpc-stack installations on various platforms, where/how do we send issues/requests? I'm assuming there will be EPIC folks monitoring issues here on the hpc-stack github site? — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RPEJOL5SNU4QZHDKULVCWYGVANCNFSM5HWLPYZQ>. You are receiving this because you were mentioned.

[christopherwharrop-noaa]

I'll ask about it in the SRW App code mgmt meeting today. Depending on the timeline, it might be ok to just wait. As it stands, users wanting to run RRFS on Cheyenne can manually edit the srw_common file to change the version of bufr to 11.5.0. Not idea, but not a total disaster either.

[climbfuji]

I installed bufr-11.6.0 for both intel-2021.2.0 and gnu-10.1.0 in the old (GMTB) hpc-stack location. Please give it a try.

[christopherwharrop-noaa]

@climbfuji - Thank you! It looks like it works. I'm having a bit of trouble with the GNU test because of other reasons (The find_package(lapack) in GSI isn't finding BLAS for some reason...) but the Intel one definitely works.

[climbfuji]

@climbfuji - Thank you! It looks like it works. I'm having a bit of trouble with the GNU test because of other reasons (The find_package(lapack) in GSI isn't finding BLAS for some reason...) but the Intel one definitely works.

If you are using the module unuse ... export MODULEPATH ... workaround then maybe it's for the same reason as for Intel MKL previously.

[climbfuji]

In this case I think we can close this issue as completed?

[christopherwharrop-noaa]

@climbfuji - It's fine by me, but I wasn't the one who opened it. So you should probably ask @jbathegit if his issues are resolved.

[jbathegit]

As far as I'm concerned we could have closed this last December. I didn't realize it was still open.