noaa-emc / nceplibs-bufr Goto Github PK

@edwardhartnett @aerorahul

Now that testing is enabled by default, do we still need -DENABLE_TESTS=ON in README.md (in the Installation instructions) and in .github/workflows/main.yml? It might be cleaner if we just remove these - any thoughts?

In my BUFRLIB repository in VLab, I have an update to subroutines READLC and WRITLC that I'd been planning to introduce in the next version for the WCOSS and on my website. Now that I'm working to fully merge everything into the NCEPLIBS-bufr repository on GitHub, I'd like to bring these updates over to GitHub and just work from there going forward.

Subroutine READLC was modified to return a "missing" character string if
the requested mnemonic isn't found in the subset. Previously, the subroutine would return a string of all blank characters in such cases. Likewise, subroutine WRITLC was modified to print a warning message if the requested mnemonic isn't found in the subset definition, whereas the library would previously abort in such cases. I'll include a test for each of these cases as part of a new test program once I submit a pull request for this issue.

@jbathegit run these commands:

cmake -DCMAKE_Fortran_FLAGS="-fprofile-arcs -ftest-coverage" -DENABLE_TESTS=ON .. && make clean && make VERBOSE=1 && make test
gcovr -r ../ . --html --html-details -o example-html-details.html

Then open the file example-html-details.html to see the code coverage report.

Here's a snapshot:

The overall test coverage is 50%. This is pretty good, but we need it to be above 70% for sure. Can you identify areas for additional testing? (Alternatively, some of the code may be dead and can be removed instead of tested, which is even better.)

Some functions that leap out: src/copybf.f, src/copymg.f, src/copysb.f, src/cpbfdx.f, src/cpdxmm.f, src/cpymem.f, src/cpyupd.f are all untested...

As we identify areas for increased testing, add issues. When you have made a complete pass through the coverage report, and identified the first pass of tests that are needed, we can close this issue.

4 of the 10 example codes in test (specifically, test_IN_1, test_IN_4, test_IN_5 and test_OUT_4) use master BUFR table files, which as of today are now part of the distribution package within the new tables subdirectory. Up until now, static copies of some of these same files have been provided separately within the bufr.tar archive file that is pulled from emcrzdm.

The goal now will be to have the above test codes point to the master BUFR table files in tables, and at which point we can remove the legacy copies from within bufr.tar. The tricky piece is that the directory where the master BUFR tables live needs to be known to these test codes at compile time and provided as an argument to subroutine mtinfo. One idea may be to use CMake variable substitution to supply this argument within the source codes at compile time.

My understanding of how the dynamic allocation build of bufrlib is supposed to work is that if the sizing of the bufr is not specified, it defaults to the size used for the static allocation. This should make it possible to swap an SA library for a DA version. Unfortunately, this does not seem to work with the GSI using either the old makefile build system or the just completed CMake build system. Can this be fixed?

As discussed in meeting on 11/2/20, there is an external HTML documentation site for NCEPLIBS-bufr. It should be referenced in the README. (@jbathegit can you put the link in this issue or in the README?)

This external documentation contains additional text that describes NCEPLIBS-bufr and its functions.

Some of the external docs refers to specific functions and can be moved to those code files. Other parts are general and will be moved to user_guide.md (or perhaps other .md files in the docs directory if needed).

This is related to #15

CI needs to test on macOS as well as ubuntu. This is related to #68

src/copybf.f, src/copymg.f, src/copysb.f, src/cpbfdx.f, src/cpdxmm.f, src/cpymem.f, src/cpyupd.f are all untested

There is a legacy Makefile in the src directory that should be removed.

This will come after #77

Currently we build 3 flavors of the library, 4, 8, and D. Instead, use fortran interfaces and kinds to provide one library that handles all three cases.

Not sure when this should happen, we want to try this out on a simpler project first.

From another issue or PR (can't remember which) it turned out that some tests are run for intel compiler only?

What's that about?

That will make it hard to run good testing. Also, it's not clear why the compiler should make that much of a difference in a test. Perhaps the test can be re-worked to also work on gnu.

To answer a question from @jbathegit I don't know of any way of measuring code coverage for intel compilers, nor do I have one on my development system. So that's uncharted territory.

Also our CI system runs on GNU. So we are not running those intel tests and they are doing us little good.

It's normal to list all the source code in the CMakeLists.txt file.

I see the impulse to simplify this long list, but putting it in a separate file really doesn't help.

For example, it's typical to do something like:

find . -name CMakeLists.txt | xargs grep code_file.f

to find all the instances of code_file.f in the build system. Putting the list of code files in a separate cmake file just hides it.

Well I used to know how to do this, so I've got to figure it out again. ;-)

As described here:
NOAA-EMC/NCEPLIBS#121

If a user has installed miniconda as an example, the cmake FindPython script, by default, prefers the macos framework python installation over any other, even when the PATH is set to point to the user's miniconda installation.

This breaks if for instance the frameworks python is version 3.7 and the users miniconda version is 3.8. (This is how the issue was found.) The setup.py build procedure for the Python API builds a shared library file with the python version embedded in its name (eg, _bufrlib.cpython-37-darwin.so when python3.7 is used to run setup.py). When the frameworks version is 3.7 (used for the build) and the miniconda version is 3.8 (attempting to import ncepbufr), the shared library file cannot be loaded because miniconda expects the file name to be _bufrlib.cpython-38-darwin.so (with a 38 instead of a 37 embedded in it's name).

It would be nice if the build, install process for cmake would use the user's python installation instead of the macos framework so that share library file name is consistent with what the user wants to use.

In my BUFRLIB repository in VLab, I have an update to subroutine WRITSA that I'd been planning to introduce in the next version for the WCOSS and on my website. Now that I'm working to fully merge everything into the NCEPLIBS-bufr repository on GitHub, I'd like to bring this update over to GitHub and just work from there going forward.

The update to the subroutine allows the return of up to two BUFR
messages during the same call to the subroutine, in the rare instances where more than one BUFR message could become available during such a call. I'll include a test for for this situation as part of a new test program once I submit a pull request for this issue.

In my BUFRLIB repository in VLab, I have an update to subroutines UFDUMP and UFBDMP that I'd been planning to introduce in the next version for the WCOSS and on my website. Now that I'm working to fully merge everything into the NCEPLIBS-bufr repository on GitHub, I'd like to bring these updates over to GitHub and just work from there going forward.

These two subroutines are used as offline diagnostic tools to generate verbose dump listings of the contents of a BUFR subset. Subroutine UFDUMP was modified to improve the logic for sequence tracking,
and to increase the format width for integer code figure and bit number values when printing associated meaning strings. Subroutine UFBDMP was modified to fix a bug when checking for the "missing" value in long character strings (i.e. longer than 8 bytes) and to enable printing of up to 120 characters for such strings. I'll include a test for each of these cases as part of a new test program once I submit a pull request for this issue.

All,

Recently I tried to compile the NCEP_bufr library in GEOS which led to an issue with compiling with GCC 10 with moda_mstabs.F:

[  0%] Building Fortran object src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/moda_mstabs.F.o
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:39:44:

   39 |    CHARACTER*4, BIND(C) :: CBBW(MXMTBB)
      |                                            1
Error: BIND(C) Variable ‘cbbw’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:42:48:

   42 |    CHARACTER*120, BIND(C) :: CBELEM(MXMTBB)
      |                                                1
Error: BIND(C) Variable ‘cbelem’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:41:46:

   41 |    CHARACTER*8, BIND(C) :: CBMNEM(MXMTBB)
      |                                              1
Error: BIND(C) Variable ‘cbmnem’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:37:45:

   37 |    CHARACTER*4, BIND(C) :: CBSCL(MXMTBB)
      |                                             1
Error: BIND(C) Variable ‘cbscl’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:38:47:

   38 |    CHARACTER*12, BIND(C) :: CBSREF(MXMTBB)
      |                                               1
Error: BIND(C) Variable ‘cbsref’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:40:47:

   40 |    CHARACTER*14, BIND(C) :: CBUNIT(MXMTBB)
      |                                               1
Error: BIND(C) Variable ‘cbunit’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:45:46:

   45 |    CHARACTER*8, BIND(C) :: CDMNEM(MXMTBD)
      |                                              1
Error: BIND(C) Variable ‘cdmnem’ at (1) must have length one
/discover/swdev/mathomp4/Models/GEOSgcm-with-bufr-GCC10/GEOSgcm/src/Shared/@NCEP_Shared/NCEP_bufr/moda_mstabs.F:44:47:

   44 |    CHARACTER*120, BIND(C) :: CDSEQ(MXMTBD)
      |                                               1
Error: BIND(C) Variable ‘cdseq’ at (1) must have length one
src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/build.make:1903: recipe for target 'src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/moda_mstabs.F.o' failed
make[3]: *** [src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/moda_mstabs.F.o] Error 1
CMakeFiles/Makefile2:10370: recipe for target 'src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/all' failed
make[2]: *** [src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/all] Error 2
CMakeFiles/Makefile2:10377: recipe for target 'src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/rule' failed
make[1]: *** [src/Shared/@NCEP_Shared/NCEP_bufr_r4i4/CMakeFiles/NCEP_bufr_r4i4.dir/rule] Error 2
Makefile:2554: recipe for target 'NCEP_bufr_r4i4' failed
make: *** [NCEP_bufr_r4i4] Error 2

Note: our version of this file is exactly the same as the one here.

Now, we are not compiling with DYNAMIC_ALLOCATION (for good or ill). Intel seems to not care (at least how we call Intel), but a workaround for now with GNU will be turn that on, but I can't by fiat do that for all compilers since I have no idea how to test the effects (we know GNU can't run our ADAS at the moment).

I'm going to ping @tclune who has the Fortran knowledge to know why this is an issue.

We are fully committed to the CMake build system. There will be no more make-based build systems, and no more build scripts. This script should be removed.

The JEDI IODA projects use python API's to the bufr library for converting BUFR data into IODA data format.
One such API is the py-ncepbufr developed by Jeff.Whitaker and is currently housed in the JCSDA github repository here

This is a requirement for the JEDI IODA project.

Until then, we will continue to use the one under JCSDA organization.

We need to test with gfortran 10. Should be possible on Github actions.

@jbathegit can you tell me about the DA build and then I will explain it in the README?

Sorry if you have explained it to me before - if so I failed to capture it in the documentation and need to add it.

Some builds use dynamic memory and some don't? I see this in the CMakeLIsts.txt:

# Determine the kinds upfront (both src/ and test/ need them).
# Both GNU and Intel support DYNAMIC_ALLOCATION
list(APPEND kinds "4_DA" "8_DA" "d_DA")
# Only Intel supports STATIC_ALLOCATION
if(CMAKE_C_COMPILER_ID MATCHES "^(Intel)$")
  list(APPEND kinds "4" "8" "d")
endif()

Then in the src/CMakeLists.txt we have:

  # determine ALLOCATION based on kind
  if(${kind} MATCHES "^([4|8|d]_DA)$")
    set(allocation_def "DYNAMIC_ALLOCATION")
  else()
    set(allocation_def "STATIC_ALLOCATION")
  endif()

So we are building some versions of the library with and without DA?

README.md in utils directory should be added to doxygen docs

I'm trying to figure out what this file is used for, since I don't see it being referenced anywhere in any other .md files, and I don't see it displayed anywhere on the GitHub web site. The content seems important, but again I don't see where it's actually used or displayed anywhere.

Thoughts?

Following the latest merge into develop, the test_OUT_3_4_DA.x fails on macOS with GNU 9.3.0

[100%] Linking Fortran executable test_OUT_3_4_DA.x
cd /Users/rmahajan/scratch/bufrWork/python/nceplibs-bufr/build/test && /usr/local/Cellar/cmake/3.18.1/bin/cmake -E cmake_link_script CMakeFiles/test_OUT_3_4_DA.x.dir/link.txt --verbose=YES
/usr/local/bin/gfortran-9  -g -fbacktrace -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk CMakeFiles/test_OUT_3_4_DA.x.dir/test_OUT_3.f.o -o test_OUT_3_4_DA.x  ../src/libbufr_4_DA.a
Undefined symbols for architecture x86_64:
  "_cfe", referenced from:
      _dlloctbf_ in libbufr_4_DA.a(dlloctbf.c.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [test/test_OUT_3_4_DA.x] Error 1
make[1]: *** [test/CMakeFiles/test_OUT_3_4_DA.x.dir/all] Error 2
make: *** [all] Error 2

The current version in the VERSION file is:
11.3.1.1

But there is a tagged release 11.4.0.

OK, we don't need 4 numbers. 3 works for every other project and will work well for this one too. ;-) So the VERSION file should be updated to 11.4.0.

The next release can be 11.5.0 or 11.4.1...

There is a file bufrlib.prm. It is not included in the cmake build. It contains this:

If this file is not being used, let's remove it.

C-----------------------------------------------------------------------
C	Maximum number of Section 3 FXY descriptors that can be
C	written into a BUFR message by the BUFRLIB software.

	PARAMETER ( MAXNC = 600 )
C-----------------------------------------------------------------------
C	Maximum number of entries in the internal string cache.

	PARAMETER ( MXS = 1000 )
C-----------------------------------------------------------------------
C	Maximum number of entries in the internal descriptor list cache.

	PARAMETER ( MXCNEM = 450 )
C-----------------------------------------------------------------------
C	Maximum number of 2-04 associated fields that can be in effect
C	at the same time for any given Table B descriptor.

	PARAMETER ( MXNAF = 3 )
C-----------------------------------------------------------------------
C	BUFRLIB "missing" value.  The default value for BMISS is set
C	within subroutine BFRINI, but it can be modified by the user via
C	a subsequent call to subroutine SETBMISS.

	COMMON /BUFRBMISS/ BMISS
	REAL*8  BMISS
C-----------------------------------------------------------------------

We want users of this code to run tests, so they should be enabled by default, as is the common custom.

Also:

• rename CHANGELOG as Release Notes
• reorder content from newest versions (top) to oldest versions (bottom)
• display within GitHub.io web pages

bufr_v11.4.0 tag has incorrect VERSION file.
The VERSION file still reads 11.3.1.1

Can someone please update the VERSION file in that tag ASAP?
Downstream projects are using the VERSION from find_package to make decisions and the critical version is 11.4.0.

In my BUFRLIB repository in VLab, I have an update to subroutine UFBSEQ that I'd been planning to introduce in the next version for the WCOSS and on my website. Now that I'm working to fully merge everything into the NCEPLIBS-bufr repository on GitHub, I'd like to bring this update over to GitHub and just work from there going forward.

The update to the subroutine deals with a situation where the number of available data levels exceeds the amount of user-provided array space when reading from an input file. Previously, the software would abort in such cases without returning any data whatsoever, but with the change it will now print a diagnostic and return with the number of levels equal to the amount of array space that was provided. I have a sample test case for this situation and will include it as part of a new test program once I submit a pull request for this issue.

README should conform to requirements here:
NOAA-EMC/NCEPLIBS#120

Past code changes should go into a RELEASE_NOTES.md doc, if you want to keep them.

On-going code changes should be listed in the release notes, not in the README.

We have a VERSION file.

We also have code like this (src/bvers.f):

	IF (LEN(CVERSTR).LT.8) GOTO 900

	CVERSTR = '11.3.0'

	RETURN

I'm not sure that is going on with the length check here. Why is that necessary?

Instead, we create a file like this, but called bvers.f.in. Instead of:

CVERSTR = '11.3.0'

it will have:

CVERSTR = '@PROJECT_VERSION@'

Then, in the CMakeLists.txt file, we will have:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/bvers.f.in ${CMAKE_CURRENT_BINARY_DIR}/bvers.in @ONLY)

Then, at CMake configure time, the VERSION file will be read, setting @PROJECT_VERSION@, which will then be substituted into the bvers.f file.

As a result, there will be no need to ever change the bvers.f.in file each time the version changes.

There is now a standard way to call C from Fortran.

We are doing this sort of thing, but it is no longer necessary (from src/bufrlib.h):

/*
** On certain operating systems, the FORTRAN compiler appends an underscore
** to subprogram names in its object namespace.  Therefore, on such systems,
** a matching underscore must be appended to any C language references to
** the same subprogram names so that the linker can correctly resolve such
** references across the C <-> FORTRAN interface at link time.  This needs
** to be done for any subprogram that is either:
**   1) a C function, or
**   2) a FORTRAN subprogram called from C
*/
#ifdef UNDERSCORE
#define arallocc   arallocc_
#define ardllocc   ardllocc_
...

The bufr files in the "dump" are a result of the dumpjb step. Several bufr operations occur in this step; one of which is combining bufr files from the "tank" into a single bufr file in the "dump". This is done by the obsprocessing code combfr.f.

combfr.f is a generic bufr utility that concatenates a number of bufr files into a single one and would ideally reside in NCEPLIBS-bufr.

This issue relates to adding a utility to split the "dump" bufr file into its subsets, so that they can be read in by the DA framework of JEDI.
When the DA framework reads bufr files straight from the "tank", this utility won't be used (although may still be useful).

Currently twe build a static and a dynamic allocation memory model.

Let's eliminate the static build and make the dynamic build the only build.

I suspect from the inclusion of an "UNDERSCORE" flag that this build is using the old, non-standard way of calling between C and Fortran code.

Fortunately there is a standard way to do this now. Once we convert to it, we can remove the UNDERSCORE and all related shenanigans.

Not sure when this should happen. Probably after #78

What is the level of testing for this repo?

I see that there are tests and they are being run by github actions! Nice!

@jbathegit do you have a feel for how well this testing covers the code in this repo? Do we need more testing, and, if so, specifically what additional tests should we have?

As noted in the discussion for #88 , all sample programs under /utils need to have an associated test code under /test. Currently, only gettab has an associated test code, so we still need them for readbp, readmp, binv, sinv, and cmpbqm at some point.

There's no specific deadline for this task; rather, this is just a placeholder for tracking this issue and for any further discussion or developments.

Add Python Api from Jeff Whitaker.
The python api is used in JEDI IODA projects.

There is a Conf directory with a bunch of files. What are these for? Are they still used?

Greg Thompson just noticed that a bunch of CTests are failing after the most recent updates to the develop branch... I updated my repo and got the same result he did. I'm using gcc version 9.3.

Test project /home/rmclaren/Work/NCEPLIBS-bufr/build
Start 1: test_IN_1_4_DA
1/20 Test #1: test_IN_1_4_DA ...................***Failed 0.00 sec
Start 2: test_IN_1_4
2/20 Test #2: test_IN_1_4 ......................***Failed 0.00 sec
Start 3: test_IN_2_4_DA
3/20 Test #3: test_IN_2_4_DA ................... Passed 0.03 sec
Start 4: test_IN_2_4
4/20 Test #4: test_IN_2_4 ...................... Passed 0.03 sec
Start 5: test_IN_3_4_DA
5/20 Test #5: test_IN_3_4_DA ................... Passed 0.05 sec
Start 6: test_IN_3_4
6/20 Test #6: test_IN_3_4 ...................... Passed 0.06 sec
Start 7: test_IN_4_4_DA
7/20 Test #7: test_IN_4_4_DA ...................***Failed 0.00 sec
Start 8: test_IN_4_4
8/20 Test #8: test_IN_4_4 ......................***Failed 0.00 sec
Start 9: test_IN_5_4_DA
9/20 Test #9: test_IN_5_4_DA ...................***Failed 0.05 sec
Start 10: test_IN_5_4
10/20 Test #10: test_IN_5_4 ......................***Failed 0.06 sec
Start 11: test_OUT_1_4_DA
11/20 Test #11: test_OUT_1_4_DA .................. Passed 0.02 sec
Start 12: test_OUT_1_4
12/20 Test #12: test_OUT_1_4 ..................... Passed 0.02 sec
Start 13: test_OUT_5_4_DA
13/20 Test #13: test_OUT_5_4_DA .................. Passed 0.07 sec
Start 14: test_OUT_5_4
14/20 Test #14: test_OUT_5_4 ..................... Passed 0.07 sec
Start 15: test_OUT_2_4_DA
15/20 Test #15: test_OUT_2_4_DA .................. Passed 0.08 sec
Start 16: test_OUT_2_4
16/20 Test #16: test_OUT_2_4 ..................... Passed 0.09 sec
Start 17: test_OUT_3_4_DA
17/20 Test #17: test_OUT_3_4_DA .................. Passed 0.03 sec
Start 18: test_OUT_4_4_DA
18/20 Test #18: test_OUT_4_4_DA ..................***Failed 0.02 sec
Start 19: test_gettab
19/20 Test #19: test_gettab ...................... Passed 0.04 sec
Start 20: test_split_by_subset
20/20 Test #20: test_split_by_subset ............. Passed 2.02 sec

65% tests passed, 7 tests failed out of 20

See NOAA-EMC/NCEPLIBS#154

OK, up to now we have just renamed a file. But the next step is to create the inc file at build time, instead of having it in the repo. The inc file will then look like as shown below.

Note that the MAXNC and the MXNAF parameters will get substituted values.

Do we have any tests that specifically depend on MAXNC and MXNAF?

C-----------------------------------------------------------------------
C	Maximum number of Section 3 FXY descriptors that can be
C	written into a BUFR message by the BUFRLIB software.

	PARAMETER ( MAXNC = @MAXNC@ )
C-----------------------------------------------------------------------
C	Maximum number of entries in the internal string cache.

	PARAMETER ( MXS = 1000 )
C-----------------------------------------------------------------------
C	Maximum number of entries in the internal descriptor list cache.

	PARAMETER ( MXCNEM = 450 )
C-----------------------------------------------------------------------
C	Maximum number of 2-04 associated fields that can be in effect
C	at the same time for any given Table B descriptor.

	PARAMETER ( MXNAF = @MXNAF@ )
C-----------------------------------------------------------------------
C	BUFRLIB "missing" value.  The default value for BMISS is set
C	within subroutine BFRINI, but it can be modified by the user via
C	a subsequent call to subroutine SETBMISS.

	COMMON /BUFRBMISS/ BMISS
	REAL*8  BMISS
C-----------------------------------------------------------------------

In my BUFRLIB repository in VLab, I have an update to subroutine STNDRD that I'd been planning to introduce in the next version for the WCOSS and on my website. Now that I'm working to fully merge everything into the NCEPLIBS-bufr repository on GitHub, I'd like to bring this update over to GitHub and just work from there going forward.

The update to the subroutine fixes an internal calculation when standardizing messages which contain only one subset. It was discovered after researching a WCOSS operations failure back in March, and it was temporarily patched there, but now I'd like to bring the patch into the GitHub baseline. I still have the failed WCOSS test case saved off from March, and I'll include it as part of a new test program once I submit a pull request for this issue.

We want the first sentance of every documentation block treated as the "brief" description, which has special value in doxygen.

The latest tagged release of the software is 11.4.0; however, the VERSION file still says its 11.3.1.1, and the src/bvers.f file still says its 11.3.0. We need to make sure that all of these are in sync. Ideally, when incrementing the version number, it would be nice if we could do it in just one place and then have that new number automatically propogate everywhere else.

Add another utility from @jack-woollen that dumps the bufr table from a file.

@aerorahul I would welcome input on this one.

In autotools systems I would expect to include the .inc files in the list of code files. In that way dependencies can be tracked. (That is, changes in the inc file could trigger rebuild of files that depend on it.

Is that not the case is cmake?

We have a file src/bufrlib.inc (formerly src/bufrlib.prm), but it is not part of the cmake list of sources for the NCEPLIBS-bufr library.