Open wangevine opened 1 month ago
@wangevine I'll take a look to see if I can see where the problem lies.
@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.
surface_forcing_wind
needs to either be z0
or ustar
. none
isn't implemented and could lead to problems.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.
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.
OK, I won't use surface_forcing_wind=none. Again, an error message would be friendly.
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.
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.
@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.
I am trying to run a new case using the DEPHY format with specified fluxes. There are two issues:
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.