Configuring METplus to find MET

[benjamin-cash]

Hello,

I had two questions about configuring METplus with MET:

1. When using Docker/Singularity, as far as I can tell I just get the various binaries via /usr/local/bin. What value should I set for MET_INSTALL_DIR? There is no /share directory provided as part of the container, so far as I can tell.
2. After installing MET via compile_MET_all.sh there is no bin directory, no exec directory, and no share directory. The binaries for the various tools are in locations like src/tools/other/ascii2nc. Do the binaries need to be moved manually into a bin directory?

@jprestop @j-opatz

[jprestop]

Hi @benjamin-cash.

When using Docker/Singularity, as far as I can tell I just get the various binaries via /usr/local/bin. What value should I set for MET_INSTALL_DIR? There is no /share directory provided as part of the container, so far as I can tell.

I don't know the answer offhand, but if you run "which point_stat" that will give you the directory that the executable is located in. For example:

cheyenne2:jpresto> which point_stat
/glade/p/ral/jntp/MET/MET_releases/11.0.1/bin/point_stat

You'll want to remove the "/bin/point_stat" from the path and end up with "/glade/p/ral/jntp/MET/MET_releases/11.0.1" (in this example) as the value for MET_INSTALL_DIR. Please feel free to check in here if you're unsure.

After installing MET via compile_MET_all.sh there is no bin directory, no exec directory, and no share directory. The binaries for the various tools are in locations like src/tools/other/ascii2nc. Do the binaries need to be moved manually into a bin directory?

That should not be the case. It sounds like perhaps the MET tools did not install successfully. They should have been installed in a bin directory with the "make install" step. Do you still have access to your screen output from running the compilation script that you could pass along here so that we can take a look? You can't really complete your first question without us resolving your second question first.

[benjamin-cash]

Hi @jprestop

My initial post combined two separate issues which is causing some confusion, so I'm going to write two separate replies. :) Regarding the installation via singularity.

(metplus_env) [bcash@hopper1 MET-11.0.1]$ singularity run /containers/dgx/UserContainers/bcash/met-11.0.1
Singularity> which point_stat
/usr/local/bin/point_stat

Digging into this some more it looks like there is also a /usr/local/share, so I think I should be set for the singularity install.

[benjamin-cash]

Hi @georgemccabe - In this case I've only installed MET via docker, not METplus, so those variables do not appear to be set.

[georgemccabe]

You shouldn't need to install MET if you are using Docker. We provide images on DockerHub that comes with everything installed. Why do you need to install it yourself in a Docker container?

[benjamin-cash]

Hi @georgemccabe - I'm doing this as part of the focus group, so I wanted to try out the various different ways of installing MET. I hadn't actually read far enough ahead to realize I could get MET and METplus in a single container, I will also give that a try. :)

[georgemccabe]

Hi @benjamin-cash, I'm sorry, I didn't know the back story. Thanks for participating in the focus group!

[benjamin-cash]

No worries! And I did give metplus via docker a go and it worked right out of the box and was nearly instantaneous. :)

[benjamin-cash]

Regarding installation via compile_MET_all.sh, I am looking at the make_install.log and I don't see any error messages. The make_test.log output has lots of lines like

DEBUG 1: Start ascii2nc by bcash(72896210) at 2023-03-06 21:36:53Z cmd: ../src/tools/other/ascii2nc/ascii2nc ../data/sample_obs/ascii/sample_ascii_obs.txt ../out/ascii2nc/sample_ascii.nc -v 2

so the tests at least are all pointing to that src/tools/other directory. However! Looking in the output from the compile script I see things like this:
Compiling libraries into: /groups/BCASH/tar_files/..//external_libs
and
cd /groups/BCASH/MET-11.0.1
./configure --prefix=/groups/BCASH/tar_files/../ --bindir=/groups/BCASH/tar_files/..//bin BUFRLIB_NAME=-lbufr GRIB2CLIB_NAME=-lgrib2c --enable-grib2 --enable-python > configure.log 2>&1

That double slash before external_libs and bin makes me think that while the script correctly harvested the MET version from somewhere that information didn't propagate to the compile and configure commands properly.

[jprestop]

@benjamin-cash Please run "which point_stat" and tell me what you get back.

[benjamin-cash]

I tracked down where the problem came from, closing. :)

[benjamin-cash]

There was an issue with the initial directory naming structure.