check_multifile error (possibly boundary file-related?)

[kearneyb10k]

While developing some new biology modules for our Bering Sea ROMS domain, I seem to have broken... something... related to how boundary condition files are processed. I have exhausted all my usual techniques for tracking down the mistakes/bugs/etc, so I'm hoping someone here might have some suggestions for how to further diagnose this.

Background:

The base code is a fork of Kate Hedstrom's ROMS with sea ice (my fork here, development branch is newbestnpz).

I'm attempting to compile the code with a variety of different biological modules, including COBALT and an updated version of BEST_NPZ. The BEST_NPZ updates involve migrating BEST_NPZ from a much older version of base ROMS, circa 2009, but with much more recently-updated biology. Getting my newer version of BEST_NPZ working in the Hedstrom base code has involved an extensive overhaul of the way biological tracer variables (pelagic, ice, and benthic) and diagnostic variables are defined, allocated, and passed between routines throughout the ROMS code. I assume the problem I'm hitting comes from a mistake on my part when adding these edits, most likely having something to do with the ice biology tracer boundary conditions (the only boundary-related code I knowingly touched).

The error:

I am currently compiling the code in 3 different configurations: 1) physics only, 2) COBALT biology, and 3) BEST_NPZ biology. All 3 compile without error. When running, I use as near-identical inputs as possible for all 3, including identical sets of forcing and boundary condition files. The physics-only and cobalt simulations run cleanly in my very short 1-day test runs. The BEST_NPZ option throws the following error:

Code: Select all

forrtl: severe (194): Run-Time Check Failure. The variable 'multifile_info_s2d_$LCHECK' is being used in 'check_multifile.f90(373,13)' without being defined
Image              PC                Routine            Line        Source             
romsG_bestnpz_202  00000000019B6EB9  multifile_info_s2         373  check_multifile.f90
romsG_bestnpz_202  00000000019CA17B  check_multifile_          105  check_multifile.f90
romsG_bestnpz_202  0000000000770EE7  initial_                  280  initial.f90
romsG_bestnpz_202  000000000040C5F4  ocean_control_mod         120  ocean_control.f90
romsG_bestnpz_202  000000000040B3BD  MAIN__                     73  master.f90
romsG_bestnpz_202  000000000040B25E  Unknown               Unknown  Unknown
libc-2.17.so       00002B76C1974555  __libc_start_main     Unknown  Unknown
romsG_bestnpz_202  000000000040B169  Unknown               Unknown  Unknown

Digging into the error message, it seems that there's a problem checking the boundary condition input files. More specifically, the BRY(i,ng)%Nfiles variable (for i=1, ng=1) is a negative value (-1610612736) when passed to the multifile_info_s2d subroutine, so the DO ifile=1,Nfiles loop that is supposed to set the Lcheck variable is never executed. But... BRY(i,ng)%Nfiles was properly set and able to be used as a similar loop counter back in the read_phypar routine, as evidenced by the correct printout of "Input Boundary Condition" files in the standard output. And the identical set of boundary condition files runs without error for the versions of the code compiled with COBALT.

I have combed through my edits and cannot find any place that I touched the BRY array. Does anyone have any insight as to what might be happening here?

Attached are log files for the 3 simulations. I added a quick print statement to the check_multifile.f code (print *, S(i,ng)%Nfiles); you can see the printout of that diagnostic statement after the GET_STATE stuff and before GET_NGFLD (as expected in cobalt and physics-only run, not so for bestnpz).

[kearneyb10k]

In case any future readers are interested...

I finally, through copious use of print statements, tracked the source of this error to a typo in get_state.F, where I had mistakenly treated my benthic tracer variables as 2D rather than 3D variables (their vertical dimension is always set to 1 in my applications, but there remains the ability to set the number of benthic layers >1). Print statements before and after the call to nf_fread2d [that-should-have-been-nf_fread3d] showed that the values of BRY(i,ng)%Nfiles were changed to the incorrect negative values during the course of that call... even though that call was targeting the initialization file and had nothing to do with boundary conditions?!?

I'm still pretty mystified by this one, but as with most things ROMS, I'm going to accept that I will never truly understand half of what the code is doing. Fixed the typo, and the code now moves past this point smoothly.