Review of WRF GCC containers

[vanderwb]

Per @benkirk's request, here are my thoughts on the WRF GCC containers...

In general, things look good to me. I have the following comments:

1. emacs (and an LSP extension I guess) seems like an unnecessary build dependency for WRF. Will we support everyone's text editor of choice? 😄
2. If this doesn't result in libjasper being version 1.9, you may want to force that, as newer versions of jasper can cause issues. (addendum - I see later that you build 1.900.1)
3. I don't think HDF5 support in WRF is commonly used, and so you could probably disable and then not build the Fortran component of HDF5 (though I'm agnostic on your choice - it's probably no harm to add)
4. Did you choose not to use szip support in HDF5 for a particular reason? I usually enable it when building out netCDF stack.
5. Occasionally people want DAP support with netCDF, but I agree with not using it here. People can run bare-metal netCDF commands for that.
6. --disable-dap shouldn't be necessary for the Fortran component of netCDF (it is inferred from the C library)
7. Any reason not to use |& when running tee? Hopefully you don't get any errors, of course, but sometimes non-fatal stuff gets dumped to stderr.
8. The WRF folks recommend a dm build, but this seems to make a dm+sm build of vanilla WRF. IMO, if we are offering a container for compatibility, we should go with the base case, not the config that is most performant some of the time while breaking entirely for other model runtime setups.
9. There are some folks who use MPI-enabled WPS, but compiling it serially as you do makes sense to me for the base-case here. 👍

[benkirk]

Thanks @vanderwb !

Heres some answers and follow-on questions:

1. I'll remove when "publishing" after iterations. While the trial-and-error iteration inside a running container continues, so will emacs. All this learning gets folded into the final Dockerfile and scripts, and then emacs can go.
2. Good to know. The zypper version of libjasper is much newer. WPSv4 compiles against it, but I've not tested those utilities. You would recommend just using 1.900.1 across the board?
3. [...combined below...]
4. also good to know. So you'd suggest the only need for hdf5 is to support netcdf, not as important to point WRF to it? I settled on the szip choice early, rather than chasing its dependencies, but that was without much thought. Easy to revisit.
5. 👍
6. 👍
7. nope, good catch
8. agreed for final version. rationale similar to for now, building the dm+sm variant is intended to be a more stressing software engineering exercise more than a recommendation at this point.
9. 👍

Do you see any value going the other direction with the I/O libs - pursuing parallel netcdf I/O?

[vanderwb]

2. Given that this is an "older software compatibility" container, I think so. I've seen a couple of other crufty packages have issues with libjasper2/3 in Spack, so I pin the version to 1.900.1 there.
3. In my experience, yeah. I think if you build HDF5 support into WRF, you can use HDF files as an output/restart format. But I've never seen someone at NCAR do that.

As for parallel-netcdf, I'm not sure. The order of use I've seen in terms of popularity is 1) standard I/O, 2) split per-task I/O, 3) pnetcdf I/O.

If parallel-netcdf is easy to add, it doesn't seem like a bad idea to provide it. That said, would it be performant in a container build? Does the MPI binding bring in Lustre/GPFS MPI-IO capabilities?