DEPHY format with specified fluxes

[wangevine]

I am trying to run a new case using the DEPHY format with specified fluxes. There are two issues:

1. If I specify surface_type ocean, there is no flux and the fluxes in the output file are identically zero.
2. If I specify surface_type land, the fluxes in the output file are correct, but the temperature in the model decreases rapidly. It may be that the model is using large negative fluxes (maybe the missing value?).

All advection and nudging terms are turned off. Both issues occur with either the HRRR or GFS_v17_p8 suite.

Everything is on Hera under /scratch2/BMC/calnexfc/angevine/CCPP_SCM_v7.0
The case is called samens_015. Several versions of the input file are in data/processed_case_input/dephy_force_samens*. The one that I used most recently was copied to samens_015_SCM_driver.nc.

[grantfirl]

@wangevine I'll take a look to see if I can see where the problem lies.

[grantfirl]

@wangevine I've had some success debugging the issues. I used the samens_015_SCM_driver.nc from that location on Hera that you shared. Most of the problems that I was running into were due to missing data in the file.

1. The values for nudging_X in the global attributes were set to nonzero values, yet the associated X_nud data variables were missing.
2. The surface_forcing_wind needs to either be z0 or ustar. none isn't implemented and could lead to problems.
3. There is a bug/missing feature with respect to missing variables for the case input data file. The SCM code is written to expect that missing variables are set to -9999 rather than the default netCDF ones. I ran into an issue where pa_forc was missing in the netCDF file, but the SCM code didn't recognize it since the missing values were treated as some huge value by default, but it was expecting -9999 to be able to handle it. This can be fixed in the SCM code and I'll add an issue to do that. In the meantime, if you set whatever missing values you have to -9999, that might get around some problems.
4. Finally, at least for the suite that I was using, the PBL scheme divides by the wind_speed. Since both u and v were set to 0, this was causing NaNs. I've discovered that for non-prescribed surface flux suites, the wind speed is augmented by a convective gustiness factor and/or given a minimum value of 1, so the PBL scheme never divides by zero. For the prescribed surface flux suites, the calculation of wind didn't have that "safety" feature, but I should add this to the scm_sfc_flux_spec scheme to prevent this issue. In the meantime, you should be able to get past this error by setting u and v to some small non-zero value.

I didn't actually run into the first issue that you mentioned since I just used the last samens case file that you used, which had a land point. I think that problem could be related to point 2 above, but I'm not sure.

When you get a chance, please test some of the fixes above. I can implement some changes in the SCM and physics for points 3 and 4, although there are some temporary workarounds mentioned if you just want to move on.

[wangevine]

Thanks, Grant. I checked into your reply, and here's what I see.
1.a. You're correct that the global attributes in the samens_015_SCM_driver.nc file were wrong. I used the wrong template when creating that file. Clearly we can't expect the right behavior if we ask for nudging to missing variables. An error message to that effect would be helpful.
1.b. However, my first attempt (in dephy_force_samens_noadv.nc) had all the nudging and forcing attributes correctly set to zero, surface_type=ocean, and surface_forcing_wind=z0. This was the one that had zero fluxes in the output.

2. OK, I won't use surface_forcing_wind=none. Again, an error message would be friendly.

3. I agree that the code should use the netCDF missing values. That's what they're for, after all. Meanwhile I can work around that.

4. This is actually a scientific point, and the correct workaround/fix is not obvious. The PBL and/or surface layer schemes should not insist on non-zero wind speed, but they generally do get upset by that. Substituting a convective gustiness factor or a minimum value are both scientifically questionable, and for sure I would want that to be documented. The LES runs that I'm trying to emulate have a hack to use a non-zero surface wind for the flux calculations only, a hack I'm not comfortable with either. I will think about the least violent way to work around this, and I would welcome further discussion.

I'll reply again after I try these workarounds.

[wangevine]

@grantfirl , here is some more followup (see also above).
I can get a reasonable run with surface_type=land and no forcing/nudging. However, if I use surface_type=ocean, it still doesn't work (item 1b above). All with SCM_HRRR suite.

On item 4 (zero wind), I verified that using U,V=1 or U,V=0.1 work fine. U,V=0 still fails. According to Joe Olson, this shouldn't be a problem with the HRRR suite.

Next up, I tried using forc_wa=1 to impose some subsidence. It's doing something, because if my forcing file doesn't cover the entire run time, the model crashes (probably due to item 3 above). But if I cover the run time with correct values, it doesn't crash, but it also has no effect on the output. As in the theta profiles after 15 hours from runs with and without subsidence are identical, and w_ls in the output is identically zero. I tried multiplying the wa values by 10 with no effect.

As before, you can find the forcing files on Hera in the above directory with somewhat self-explanatory names.

I realize that introducing a new item here may be a non-optimal usage, feel free to suggest better ways of documenting my issues.