Should NCEPLIBS support eccodes?

Question

Should NCEPLIBS support eccodes?

edwardhartnett opened this issue 4 years ago · 8 comments

Should we support the eccodes package.

does it have github repo?
will they accept PRs?
is there a future planned?
are there other users?
is it stable and well-tested?
what is python API like?
what did Jeff W. write?

After some investigation we should have a meeting with the whole gang for a discussion of eccodes and whether or not we want to support it locally, and whether it should be used for python, and what role wgrib2 will play moving forward.

Answer 1 · 2020-10-20T20:24:56.000Z

@edwardhartnett We make use of eccodes for several UFS-S2S applications.

The git repo is here: https://github.com/ecmwf/eccodes

I cannot say with 100% certainty, but I don't know that Jeff Whitaker (assuming that is the Jeff W. you are referencing) has written any of it. I believe most is a result of the former GRIB API and other developments internal to the EC.

Answer 2 · 2020-10-20T20:26:20.000Z

Just curious - where did this requirement come from? ecCodes is a full suite of programs, including its own set of native BUFR and GRIB2 encoders and decoders.

Answer 3 · 2020-10-20T20:35:27.000Z

@jbathegit there is a need for a python API for grib. Jeff W. wrote one, and that's popular and some people want to use it, but it depends on eccodes. We either have to support eccodes (at least the grib parts), or else come up with a python API to Grib (on a tight schedule).

So the question is: if we wanted to use eccodes, how hard would it be for us to support it? How well could we rely on it? Etc. No decision has been made yet, this issue is to gather information for that decision.

Do you know anything about eccodes? Do you have any feedback? If so, post it here...

Answer 4 · 2020-10-20T20:50:29.000Z

I've never used it myself, but I know a good portion of Europe uses it to encode and decode BUFR and GRIB. So it's well-established software, but if we pull in the entire package, then that ends up being yet another set of BUFR and GRIB packages that we're now supporting. Seems a bit redundant to me, but again maybe I'm missing something.

Answer 5 · 2020-10-20T21:09:20.000Z

Certainly it is not an ideal solution.

Answer 6 · 2020-11-18T13:41:01.000Z

Response to email to eccodes team, asking about attitude towards collaboration and contributions, and team size supporting eccodes:

Daniel Varela Santoalla on 18/Nov/20 9:44 AM

| Dear EdwardThe general support principles for all our public software packages are listed in the following pagehttps://confluence.ecmwf.int/display/SUP/Software+support+principlesnamely we cannot make any commitments of specific response times or "quality of service" but we always endeavour to help our users as much as we can, specially when solutions can have an impact across the whole user community.Regarding the resources dedicated to eccodes, we do have some support and some development resources, but often shared with other projects in an as-needed basis. It is not a large team but we feel it is adequate for the current state of the software.We are very receptive to any code contributions you may want to submit via GitHub (https://github.com/ecmwf/eccodes). And not only bug fixes but some new features may be acceptable too, specially in the area of support for grids and encodings. The key element is to have unit tests for anything submitted that can give us confidence that your contribution does not have a detrimental effect to other users. For more information please see https://confluence.ecmwf.int/display/SUP/ECMWF+software+on+GitHubHope this helps, but do not hesitate if you need any more information.Kind regardsDaniel VarelaECMWF Software Support

Answer 7 · 2020-11-20T16:05:24.000Z

CRTM (https://github.com/JCSDA/crtm/) supports ecbuild, and build out of master and develop branches. I would be in support of using eccodes (ecbuild specifically), it would make my life marginally easier, but it's not required. We use eccodes by default in all JCSDA/JEDI libraries and applications, and have had very little need to interact with the ECMWF support. When we have had questions, they're very responsive. They use Apache 2.0 license as well, which is conformant with future licensing requirements for other NOAA projects. While I'd rather see a solution that we have full autonomy over, I think there's a valid argument for using eccodes. The ecbuild system is just a set of cmake wrappers, so you can make use of existing cmake modules (e.g., findnetCDF.cmake) without having to change the modules. The CMakeLists.txt files, however, have to use the ecbuild commands. I can't speak to the grib-api or other codes that they are using.

Answer 8 · 2023-01-26T07:39:16.000Z

I believe this issue can be closed. We support eccodes but NCO has required some edits to the package before it is installed.