BLRTM v12.17 — `OPNODF` "Unit number too large" crash on IMRG=35 prestored-OD merge, only with `-fdefault-integer-8`

[mirfjc]

Symptom

When LBLRTM v12.17 (built with osxGNUdbl flags including -fdefault-integer-8) is invoked on AER's own RADSUM example TAPE5 (RADSUM/run_examples/tape5.lbl.sample), the first $-section runs cleanly and produces all 42 ODdeflt_NNN per-layer optical-depth files. The second $-section (IMRG=35, downwelling-radiance merge from prestored ODs) crashes:
At line 1547 of file ../src/lblrtm.f90
Fortran runtime error: Unit number in I/O statement too large

Line 1547 is the OPEN (UNIT=KOPEN, FILE=FILE1, ...) inside SUBROUTINE OPNODF at lblrtm.f90:1546-1547. KOPEN should be KFILE (=10) or KODFIL (=17) per the surrounding logic, both small valid Fortran I/O units. The "too large" error indicates KOPEN is holding a garbage value when it reaches OPEN.

Trigger

Same trigger as the companion bug (TMPBND zeroing under -fdefault-integer-8, filed alongside this issue as a comment on #82): the osxGNUdbl flag combination, specifically -fdefault-integer-8.
FCFLAG="-fdefault-integer-8 -fdefault-real-8 -fdefault-double-8
-frecord-marker=4 -fallow-argument-mismatch -std=legacy"

The same v12.17 source built with osxGNUsgl (no -fdefault-integer-8, no -fdefault-real-8) processes the exact same TAPE5 to completion, produces TAPE61/62/63 per-angle radiance, and feeds RADSUM cleanly to a sensible OUTPUT_RADSUM.

Reproducer

Set up LBLRTM and RADSUM (both built osxGNUdbl)
cd LBLRTM/external_tools/RADSUM/run_examples
ln -sf /lblrtm_v12.17_OS_X_gnu_dbl ./lblrtm
ln -sf /radsum_v2.7_OS_X_gnu_dbl ./radsum
ln -sf ./TAPE3
ln -sf <absco-ref_wv-mt-ckd.nc> ./absco-ref_wv-mt-ckd.nc
cp tape5.lbl.sample TAPE5
./lblrtm
Output:
At line 1547 of file ../src/lblrtm.f90
Fortran runtime error: Unit number in I/O statement too large
After exit: 42 ODdeflt_NNN files exist (section 1 succeeded), but
no TAPE61/62/63 (section 2 crashed before writing them).

Source state

SUBROUTINE OPNODF at lblrtm.f90:1516-1558:

COMMON /ADRFIL/ KODFIL, kradtot, KTEMP, KFILAD, K_REFTRA, k_rddn_sfc
COMMON /IFIL/ IRD, IPR, IPU, NOPR, NFHDRF, NPHDRF, NFHDRL, NPHDRL,  &
&             NLNGTH, KFILE, KPANEL, LINFIL, NFILE, IAFIL, IEXFIL,  &
&             NLTEFL, LNFIL4, LNGTH4

if (kflg .lt. 0) then
   kopen = kodfil
else
   kopen = kfile
endif

WRITE(IPR,910) LAYER, NLAYER
INQUIRE (UNIT=KOPEN, OPENED=OP)
IF (OP) CLOSE (KOPEN)

WRITE(FILE1, HFMODL) PTHODL, LAYER
OPEN(UNIT=KOPEN, FILE=FILE1, FORM=CFORM, STATUS='OLD')   ! line 1547

Both KODFIL (set to 17 at lblrtm.f90:571) and KFILE (set to 10 at lblrtm.f90:612) are small valid I/O unit numbers. With -fdefault-integer-8, the COMMON-block layout / call-boundary handling apparently corrupts KOPEN somewhere in the IMRG=35 dispatch path.

The companion bug (TMPBND zeroing, comment on #82) shows a similar COMMON-block-corruption pattern in /BNDPRP/ — TMPBND is correctly read from Record 1.4 but is zeroed before XMERGE accesses it. Both issues localize to "non-default-mode code paths under -fdefault-integer-8".

Workaround

Build with osxGNUsgl (single precision):
gmake -f make_lblrtm all P_TYPE=sgl FC_TYPE=gnu PLTFRM=OS_X
FC=gfortran FCFLAG="-frecord-marker=4 -fallow-argument-mismatch -std=legacy"
UTIL_FILE=util_gfortran.f90

(The default osxGNUsgl makefile.common rule lacks -fallow-argument-mismatch and -std=legacy, both of which v12.17 needs to compile on modern gfortran. With those added, the single-precision build runs the AER RADSUM example end-to-end and produces the expected OUTPUT_RADSUM to within 0.7% of the double-precision reference values.)

Suggested investigation

Combine this with the companion bug (TMPBND zeroing, commented on #82) into a single CI step in AER's release workflow: smoke-test osxGNUdbl (which sets -fdefault-integer-8) by running the shipped RADSUM example to completion and validating OUTPUT_RADSUM end-to-end. Both bugs surface immediately on that test path.

Cross-reference

Related to #82 (TMPBND zeroing under -fdefault-integer-8) — same root-cause flag, same workaround, but a distinct code path and a distinct symptom (crash vs silent wrong answer).