Fixes to allow FV3_HRRR_c3 to run with gnu debug plus PR #113, #106, and #103

[SamuelTrahanNOAA]

The c3 code cannot handle null pointers correctly. This changes some array argument declarations so tests pass. At the ufs-weather-model level, I've added hrrr_c3_debug tests for both the gnu and intel compilers. The new tests pass on Jet, Hera, and Cheyenne.

This PR includes #113 and #106

• Fixes CLM Lake restarts nine 3D fields that are constant #112
• Fixes FV3_HRRR_c3 suite crashes in c3 calls on Cheyenne with gnu compiler in debug mode. #101
• Fixes ozinterp and h2ointerp data is read when it is not needed #108
• Fixes The noahmptable.tbl file is mandatory, even for configurations that don't need it. #107
• Fixes GFS_phys_time_vary_init does not report errmsg/errflg correctly due to thread race condition #105
• Fixes incorrect filename in warning message for missing noahmptable.tbl #104
• Adds errflg=0 and errmsg='' in two routines that were missing them.

[lisa-bengtsson]

Changes look good, but it is a bit surprising the the cu_gf_deep.F90 doesn't run into the same problem?

[SamuelTrahanNOAA]

Changes look good, but it is a bit surprising the the cu_gf_deep.F90 doesn't run into the same problem?

Correct. I didn't change other schemes because I wanted to simplify the changes as much as possible.

My ufs-weather-model changes add hrrr_c3_debug and hrrr_gf_debug tests for both compilers. If we encounter problems again, we'll know.

[SamuelTrahanNOAA]

In a recent email about this PR, I got the usual question about WRF compatibility, so I'm pasting my answer here.

WRF needs a starting index for each dimension. By that, I mean the its: part of its:ite. If you remove both the its and the ite (dimension(:)) then the starting index is 1. That breaks WRF. However, if you keep the starting index (dimension(its:)) then the array starts at its and WRF will work. If you include the ite then CCPP will crash with the gnu compiler if you pass a null pointer.

In short, your dimensions must look like this

dimension(its:,kts:) :: my_3d_array
dimension(its:) :: my_2d_array
dimension(kts:) :: my_column_array

That way, both WRF and CCPP work.

[dustinswales]

In a recent email about this PR, I got the usual question about WRF compatibility, so I'm pasting my answer here.

WRF needs a starting index for each dimension. By that, I mean the its: part of its:ite. If you remove both the its and the ite (dimension(:)) then the starting index is 1. That breaks WRF. However, if you keep the starting index (dimension(its:)) then the array starts at its and WRF will work. If you include the ite then CCPP will crash with the gnu compiler if you pass a null pointer.

In short, your dimensions must look like this

dimension(its:,kts:) :: my_3d_array
dimension(its:) :: my_2d_array
dimension(kts:) :: my_column_array

That way, both WRF and CCPP work.

@SamuelTrahanNOAA Your are spot on.

[dudhia]

@dustinswales does it actually break WRF? We just like to keep the absolute index for debugging purposes.

[dustinswales]

e absolute index for debugging purposes.

@dudhia
@SamuelTrahanNOAA is the expert on null pointers :)
But from my understanding,
changing from its:ite -> : will break the WRF code, but the CCPP will work
changing from its:ite -> its: will work for both hosts.

[SamuelTrahanNOAA]

does it actually break WRF? We just like to keep the absolute index for debugging purposes.

Loops inside the WRF physics use its as a starting index. If the arrays start at 1 and you access index its, it may be far beyond the allocated array. The its:ite may be 2560:2610. Lose the its and the array bounds will be 1:51. Accessing index its=2560 puts you past the array bounds.

Also, WRF arrays are declared with memory bounds, not tile bounds:

dimension(ims:ime,kms:kme,jms:jme)

So long WRF passes arrays to the low-level physics routines like this, it'll work:

call thing(grid%var(its:ite,kts:kte,jts:jte))
or
call thing(var(its:ite,kts:kte,jts:jte))

[dudhia]

@SamuelTrahanNOAA I see. Yes, we can't do that in WRF as we also pass in its. CCPP must be treating those as 1.

[SamuelTrahanNOAA]

I've merged #106 into this PR since the UFS code managers plan to merge the two simultaneously.

[BrianCurtis-NOAA]

Can we get at least one re-approval since there have been code changes since the latest approval. Just need someone to be OK with those newer changes.

[grantfirl]

@BrianCurtis-NOAA This still looks good to me after the combination of PRs.

[SamuelTrahanNOAA]

@haiqinli - Please confirm I merged your changes correctly.

[haiqinli]

@SamuelTrahanNOAA Thank you very much! Your merging looks good to me.

[jkbk2004]

@grantfirl @dustinswales All tests are done at ufs-community/ufs-weather-model#1893. Can you merge this pr?