search

NOAA-EMC / NCEPLIBS-g2

Utilities for coding/decoding GRIB2 messages.
Other
6 stars 15 forks source link

combine grib_util with this repo #296

Closed edwardhartnett closed 3 months ago

edwardhartnett commented 2 years ago

Seems like we can move the grib utilities in with g2.

We can add an option ENABLE_UTILITIES=OFF for those who want to build g2 without the utils.

Since grib_util depends on g2 already, this will mean the same software gets built, but with one less repo, build system, and dependency.

@Hang-Lei-NOAA @BoiVuong-NOAA @DusanJovic-NOAA comments welcome.

Hang-Lei-NOAA commented 2 years ago

I think this is a good plan. Previously, we moved nemsi_utils into nemsio library

DusanJovic-NOAA commented 2 years ago

grib_util repository contains programs that do not depend on g2, wgrib for example. It does not even deal with grib2 format. I do not see a reason why would wgrib be in g2 repo at all. This repo should be just a grib2 decoding/encoding library nothing else, in my opinion. I hope we do not turn this repo into a collection of random programs that process grib messages.

edwardhartnett commented 1 year ago

I will close this issue and ponder.

A better way may be to re implement these utils in the g2c library and let the grib_util repo fade away.

edwardhartnett commented 1 year ago

We will move the GRIB2 Fortran utilities from grib_util to g2. This will allow us to reduce the number of repos in NCEPLIBS, a long-standing goal, and improve testing of the g2 library. (Sometimes a bug shows up in the utility tests, so we should have them with the g2 library.)

Those who wish to build without the utilities may do so. A CMake option will exist for that.

Will this turn the g2 library into a random collection of utilities, some of which may not be very helpful to everyone? No, because it does not mean we will add random utilities. However, we already have some utilities, and we must support them. Doing that will be easier in the g2 repo than in a separate repo.

We can leave the GRIB1 utils in grib_util, if they can be deprecated soon. If not, we will move them to the GRIB1 repo, w3emc.

edwardhartnett commented 8 months ago

Well the above plan won't work well either, because some of the utilities depend on both w3emc and g2.

OK, I will close this issue and continue to ponder...

edwardhartnett commented 4 months ago

And we are back again! This time we are going to complete this issue.

Yes, some of the utilities depend on w3emc, but so does g2 itself, which has some w3emc calls within it.

We already have the option -DBUILD_WITH_W3EMC, when set to ON, w3emc is used, when set to off, it is not. We will continue to use this option to control building the utilities. If BUILD_WITH_W3EMC is off, then we will not build any of the utilities which depend on it. If it is on, then we will build all utilities. We can add a -DBUILD_UTILITIES which allows the user to opt out of building any utilities. (In all cases, default values will reflect what works best on WCOSS2.)

Recent experience dealing with tocgrib2 have demonstrated that the utilities are intimately linked to the g2 code. When any bug is found in the utilitiy, a new release of both g2 and grib_util is required. These closely-related codes will benefit from being in the same repo.

@AlysonStahl-NOAA will be working on this. See https://github.com/NOAA-EMC/NCEPLIBS-grib_util/issues/332

Since we just did a release of g2 and grib_util, this is a perfect time to do the merge. There will be no further releases of the grib_util repo. Moving forward, the utils will be installed with g2.