debufr failing with internal write overflow

[DavidHuber-NOAA]

When compiled with spack-stack on Hera, the debufr application is failing with an internal write error:

[David.Huber@hfe01 .github]$ module use /scratch1/NCEPDEV/nems/role.epic/spack-stack/spack-stack-1.5.1/envs/unified-env/install/modulefiles/Core
[David.Huber@hfe01 .github]$ module load stack-intel/2021.5.0
[David.Huber@hfe01 .github]$ module load bufr/12.0.1
[David.Huber@hfe01 .github]$ debufr /scratch1/NCEPDEV/nems/David.Huber/GSI/ptmp/tmpreg_global_4dvar/global_4dvar_loproc_updat/nsstbufr -o tmp
forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write
Image              PC                Routine            Line        Source
libifcoremt.so.5   00007F9D5FED9E79  for__io_return        Unknown  Unknown
libifcoremt.so.5   00007F9D5FF3BCAE  for_write_int_fmt     Unknown  Unknown
libbufr_4.so       00007F9D5FA3105A  mtfnam_                    57  mtfnam.f
libbufr_4.so       00007F9D5FA74E90  ireadmt_                  213  ireadmt.f
libbufr_4.so       00007F9D5FA24978  getcfmng_                 151  getcfmng.f
debufr             000000000040F8D3  fdebufr_f                 261  debufr.F90
debufr             000000000040E0CB  main                      346  debufr.c
libc-2.17.so       00007F9D5EAF5555  __libc_start_main     Unknown  Unknown
debufr             000000000040D329  Unknown               Unknown  Unknown

When compiled with hpc-stack, there is no issue. Looking into mtfnam.f and ireadmt.f, it appears that the maximum length for a BUFR table filename is 132 while for the Hera installation, the full path length for the tables is 155-156. This should probably be increased.

FYI @wx20jjung

[jbathegit]

It looks like we do have a bit of an inconsistency in the library, because variable MTDIR is dimensioned as character*240 in mtinfo.f, but only as character*100 in mtfnam.f and ireadmt.f. So we should probably bump the latter two up to character*240 (which would also match the length of cmtdir in bfrini.f90.in), and then correspondingly bump STDFIL and LOCFIL to be character*275 in ireadmt.f

I'll work on this, but I'll also need to come up with a new CI test to verify that the increased array sizes don't blow up something else.