-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update calculation of time-averaged radiation variables #241
base: ufs/dev
Are you sure you want to change the base?
Update calculation of time-averaged radiation variables #241
Conversation
…rect sub-fhswr/fhlwr bucket radiation values
…om *_post routines
@LarissaReames-NOAA Thanks for fixing this accumulation error!!! I have a small request. Could you combine GFS_rrtmg_post.F90 and GFS_rrtmgp_post.F90 into one module, say GFS_radiation_post.F90? The only piece in GFS_rrtmg_post is something that is needed for RRTMGP as well, but it was never added there. FWIW, back in the day Thompson MP and RRTMGP were both being developed for P8 independently and it was up to the GP developer at the time (me) to implement the Thompson changes as they came in, and it looks like I missed one :). |
@dustinswales I'm open to that. Would there need to be some if branch for the two schemes since RRTMG already has all the DDTs set inside the scheme? |
Sure, I guess. This was already part of the radiation interstitial cleanup plan, so it's fine if it happens here. We'll rename it to UFS* instead of GFS* in the future though. |
@LarissaReames-NOAA Yeah. There is a do_RRTMGP switch that could be passed in. If GP, assign flat-fields to DDT, always compute SW cloudy albedo. |
Okay, let me know how the latests changes look. I tested modified versions of a RRTMG and RRTMGP RT in the weather model and both looked good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me!
Thanks for making these changes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for these updates!
Hi Larissa, do you think we should remove the weighting function xmu(i) in the file dcyc2t3.f for the diffuse flux calculations? |
It can be done in a separate PR to remove the weighting function xmu(i) for the diffuse flux calculations. It is a different issue from this one. |
Description
This PR fixes incorrect diagnostic output for fhzero-averaged radiation variables output in the weather model and computed from the CCPP 'fluxr' array. Presently, there is a significant "sawtooth" appearance to these fields when output from ufs-weather-model (such as dswrf_ave and ulwrf_avetoa) when we expect smoother lines with jumps only at fhzero diagnostic reset times. Here is an example of the present (OLD) result and the result from the current PR (FIX) of DWRF_AVE from a 24-hour control C48 weather model regression test forecast.
To accomplish this, I moved all fluxr computations from the rrtmg_post and rrtmgp_post routines to the dcyc2t3_run routine, thus it is called, and fluxr accumulates radiation values, at every large dynamics time step. I did my best to move documentation of the variables to the dcyc2t3_run header as well.
Issue(s) addressed
Testing
Ran full ufs-weather-model regression test suite on Hera. See log files here:
/scratch1/NAGAPE/hpc-wof1/lreames/ufs-weather-model/tests/logs/log_hera
. You can also see forecast output from these tests in/scratch1/NCEPDEV/stmp2/Larissa.Reames/FV3_RT/rt_4109245
All regression tests fail as sfcf*.nc files, as well as post-processed grib2 files as a result, are not identical. New weather model baselines will be necessary.