Moving empty and non-existent data table handling inside data_override

[GFDL-Eric]

Description
Instead of having these checks within the various couplers, we are moving the handling of empty and non-existent data_table and data_table.yaml files within data_override. Note that this involved hardcoding the file_id returned by open_and_parse_file for yaml files in order for that to be acted upon within data_override.

Fixes #934

How Has This Been Tested?
Compiles on skylake. This is mostly runtime changes and they have not been tested.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules
• New check tests, if applicable, are included
• make distcheck passes

[bensonr]

I've tested the if-test for diag_table existence in two FV3 solo tests (no grid_spec and an empty data_table) and it works as expected.

[rem1776]

Looks like this needs a merge with main to get rid of the tap-driver.sh changes

[GFDL-Eric]

I'm pretty sure this is already based on the 2022.01-beta2 tag, which is the latest commit? Unless another PR made a change?

[GFDL-Eric]

Now I get it... I rolled back the tap-driver.sh stuff to what's currently in main.

[rem1776]

@GFDL-Eric That file used to be auto-generated by autoreconf until #800 added it to the repo with some changes, so that probably messed up the merge. I see you fixed it now though

[thomas-robinson]

Is this compiler or system dependent?

[GFDL-Eric]

ugh, you're right, I thought I was being clever here and using a "standard". I guess I can just use INQUIRE instead?

[thomas-robinson]

Don't feel bad, i ALWAYS write write (6,*)

[GFDL-Eric]

I've now pushed a change that should also obviate the need to go through the reading table portion if the file doesn't exist... let me know if anything looks like it won't work with that.

[bensonr]

With the early exit for a non-existent data_table, are things initialized the same as if one had an empty data_table? I ask to make sure that future data_override calls will be handled in the same fashion.

[GFDL-Eric]

@bensonr, the only practical implications of exiting the read_table subroutine at that point (as opposed to going through with an empty table) are that the ntable, ntable_lima, and ntable_new values are not set to 0. However, those values are not used outside of the read_table subroutine. The line that sets table_size equal to 0 in read_table is sufficient for triggering the "return" in data_override_init for an empty data table or non-existent file.

[bensonr]

@GFDL-Eric - Does that mean subsequent calls to data_override will also return?

[GFDL-Eric]

not as it's currently written... that's gonna be a problem!

[GFDL-Eric]

hmm, actually, subsequent data_override_init calls should return because table_size should already be an established module variable after the first data_override_init call. As for calls to data_override itself with an empty table, assuming a do i=1,0 just gets skipped, those subroutines should also return. Also, nobody should be calling data_override (2D or 3D) with an empty data table in the first place.

[bensonr]

@GFDL-Eric - I'm clear on the behavior of data_override_init. It's the behavior of data_override called directly without any conditional or trigger around it. I've looked through an ESM codebase and only see unprotected instances in FMSCoupler and MOM6 (coupler functionality that seems to have been moved within) that could be a problem if an absent data_table isn't handled the same way as an empty data_table. With the exception of requiring a grid_spec.

[GFDL-Eric]

@bensonr For the data_override calls (both 2D and 3D), the first section in both subroutines attempts to find the index within the table. Here are the lines from 2D:

  if(PRESENT(override)) override = .false.
  index1 = -1
  do i = 1, table_size
     if( trim(gridname) /= trim(data_table(i)%gridname)) cycle
     if( trim(fieldname) /= trim(data_table(i)%fieldname_code)) cycle
     index1 = i                               ! field found
     exit
  enddo
  if(index1 .eq. -1) return  ! NO override was performed

data_table values are set to the default values on the first run of data_override_init, regardless of empty or non-existent data_table. Similarly, table_size is set to 0 on that first init. This should result in index1 remaining at -1 and the return being triggered on the last line, provided data_override_init has been called once (module_is_initialized = .true.). If it hasn't, it appears that 2D will fail, but 3D will not, because 3D has:

if(.not.module_is_initialized) &
       call mpp_error(FATAL,'Error: need to call data_override_init first')

We can add this protection to 2D to be safe, although it would only be applicable in cases where data_override_init was never called. Should we just go ahead and add it?

[bensonr]

@GFDL-Eric - sounds like we are good as is. I'll approve it here shortly.