Height Adjustment of Background 10-m Wind Gust When Analyzing Near-surface Wind Gust observations in GSI for HRRR-3DRTMA#863
Conversation
mesonet near-surface wind gust observations in HRRR-based 3DRTMA. 1. adding code to turn on the wind height adjustment for 3DRTMAr, using the code already implemented in GSI for 2DRTMA/URMA; 2. adding code to read surface roughness from WRF-ARW firstguess, which is used in the height-adjustment scheme based on Similarity theory (developed by Steve Levine, Xiaoyang Zhang and Manuel for 2DRTMA.)
hu5970
requested review from
AnnetteGibbs-NOAA,
ManuelPondeca-NOAA,
MatthewMorris-NOAA,
TingLei-NOAA,
guoqing-noaa and
hu5970
|
Does the rtma ctest exercise the new functionality added by this PR? If not, how have the changes in this PR been tested and confirmed to work as intended? Will this code be implemented in operations? A debug A debug It's my understanding that NCO pre-implementation testing requires applications to be built and run in debug mode. |
|
@RussTreadon-NOAA Thanks! |
@RussTreadon-NOAA Thank you so much for the questions. I have not compiled GSI in "DEBUG" mode and tested the debug gsi.x yet. I will do this test soon and let you know what I find. As the error message you showed with the rtma ctest, For 3DRTMA, it is based on hybrid 3DEnVar, not (2D)RTMA, so 3DRTMA run does not call subroutines in "anisofilter.f90", since anisotropic recursive filter is mainly used in (2D)RTMA applications. So I assume 3DRTMA run with debug gsi.x should not crash in anisofilter since 3DVar analysis does not use it. But definitely that is an issue for RTMA CTest. @TingLei-NOAA -Gang |
@TingLei-NOAA @RussTreadon-NOAA Thank you! -Gang |
|
@GangZhao-NOAA , you are right. PR #862 will not enter We don't require GSI PRs to pass a debug test. NCO pre-implementation testing requires a successful debug test. Since NOAA-EMC/GSI supports operations and future GSI -based implementations, GSI developers should think ahead, test for debug failures, and fix any failures before sending code to NCO. |
|
@GangZhao-NOAA Yes. the PR#862 will not go into develop branch. You could add that change to your branch if you are satisfied with that fix. And I think that is always a good practice to let debug mode GSI finish its runs successfully. |
…ion) to calcualte the wind reduction factor used in analysis of near-surface wind gust for 3DRTMA.
are only needed for non-neutral scheme, not neutral scheme.
|
@TingLei-NOAA @guoqing-noaa @hu5970 @ManuelPondeca-NOAA @MatthewMorris-NOAA @AnnetteGibbs-NOAA, I made some changes to the code, mainly in setupgust.f90 and read_prepbufr.f90. In brief, the modifications include adding new subroutine rtma3d_comp_fact10 in setupgust.f90 to calculate the "factw" at the observation height under non-neutral conditions in PBL, and fixing an issue that zges(1), mid-layer height of model bottom layer at obs location, was re-set to 10 meters in 3DRTMA run, but over 75% wind gust obs from type 180 were rejected. For details, see the updated google doc -- "Notes on Changes in GSI for Height Adjustment in Analysis of Wind Gust". Please review this PR #863 with the latest committed code. The latest commit passed all of 6 the current GSI CTests on Hera and WCOSS2 (Cactus). Here are the brief results of the CTests: On WCOSS2 (Cactus): Thank you! -Gang |
|
@RussTreadon-NOAA @TingLei-NOAA @ShunLiu-NOAA @hu5970
No. Current RTMA ctest does NOT exercise the new functionality added by this PR #863 . My current work (including this PR #863) are oriented for 3DRTMA (usually in GSI code, the new functions/features are controlled by specific options, such as "l_rtma3d). So regular RTMA, and other DA applications (such as Global DA, Regional DA, etc.) should not use any of these new features, and also their results and performance should not be influenced by these new features. The modified code passed the all of the 6 GSI regression tests. And I also ran the original GSI code and my modified GSI code in a real case, the results are identical, noting that when running my modified GSI code, the new features were turned off.
The new feature was tested in the same real case. The main purpose of this PR #863, is to "re-calculate" the wind reduction factor "factw" to the actual observation sensor height, instead of at the standard value 10 meters, for the Mesonet wind gust observations. The "re-computed" factw and original factw are both stored in the obs-diag file for wind gust (in netcdf format). In obs diag file from the real case test run, the values of re-calculated factw are generally adjusted to a smaller value (<1), compared to the original factw (=1.0). This is as expected, since the actual heights of wind sensor of a fair amount of mesonet obs are lower than 10 meters (such as 7, 5, or even 2 meters), correspondingly the adjusted factw should be reduced furtherly.
Yes, this code would be implemented in operations later. I compiled the code in debug mode, and ran the 6 ctests, they all crashed due to floating invalid, except for global_enkf test which passed. Currently the issue with debug mode is beyond the scope of this PR #863 and related Issue #857. I will re-visit the issue with debug mode GSI soon. |
|
@guoqing-noaa @ManuelPondeca-NOAA @TingLei-NOAA @MatthewMorris-NOAA @AnnetteGibbs-NOAA If you have a chance, could you please review this PR? Thanks. |
| ! do n = 1, ncount | ||
| ! write(6,'(1x,A,2X,A16,2X,F5.2,2x,I3.3)')'readin_windht_list::prov+subrpov height:',provlist(n), heightlist(n), n | ||
| ! end do | ||
|
|
There was a problem hiding this comment.
Please clean those commented code.
There was a problem hiding this comment.
There was a problem hiding this comment.
@hu5970
Hi Ming,
Those commented lines were cleaned off. You may go ahead check the updated code now.
Thank you!
-Gang
| if (neutral_stability_windfact_2dvar) then | ||
| sfcr = data(isfcr,i) | ||
| factw=log(max(sfcr,zob)/sfcr)/log(ten/sfcr) | ||
| i_factw = 3 |
There was a problem hiding this comment.
the additional i_factw will change behavior of the previous codes? or it is a fix missing in previous codes?
There was a problem hiding this comment.
@TingLei-NOAA
Hi Ting,
This new variable, i_factw, does not change the behavior of the code, and it is also not a fix to the code. It actually has no any influence to the results of the code. I just used i_factw to mark the way how "factw" was re-computed or adjusted, and output it in the netcdf-format obs-diag file.
It might cause some confusion, so I will remove it from the code.
Thank you for pointing this out!
-Gang
| else if(l_rtma3d) then | ||
| call rtma3d_comp_fact10_(dlat,dlon,dtime,zob,skint,sfcr,isli,mype,factw) | ||
| end if | ||
| i_factw = 4 |
There was a problem hiding this comment.
OK, I see, i_factw is a new variable incorporated in this PR.
There was a problem hiding this comment.
@TingLei-NOAA
Hi Ting,
I removed the variable i_factw. You may check the updated code now.
Thank you!
-Gang
…ind gust analysis: 1. cleaning off a few commented lines in windht.f90 2. removing the previously-added variable i_factw in setupgust.f90
|
@TingLei-NOAA @hu5970 @guoqing-noaa @AnnetteGibbs-NOAA @MatthewMorris-NOAA @ManuelPondeca-NOAA @ShunLiu-NOAA @RussTreadon-NOAA There was an update to develop branch of official EMC-GSI, so I merged this latest update to my working branch. Then following Ming and Ting's comments, I cleaned off the commented lines in windht.f90 and removed the variable "i_factw" (which was just added in the previous commit of this same PR) in setupgust.f90, this variable has no any influence to the results. So now the code for this PR has been updated. I also re-ran Regression tests with GSI Ctest Suite on WCOSS2 and Hera. It passed all the 6 tasks of the CTest on WCOSS2 Cactus and Hera. The changes are very trivial, so if you already approved this PR on the previous commit, I am sure your approvals are still good for this one, if you do not have time, you do not need to re-review this commit. If you have not review this PR yet, you may check the code now. Thank you very much! Here are the brief report of CTests on WCOSS2 Cactus: Here are the results from CTests running on Hera: |
…rface Wind Gust observations in GSI for HRRR-3DRTMA (NOAA-EMC#863) - The height adjustment scheme is based on the Similarity Theory for turbulence boundary layer. In fact, it already had been implemented in GSI (by @ManuelPondeca-NOAA, @StevenLevine-NOAA and @xyzemc a few years ago) for 2DRTMA/URMA (see the if-block of "if(zob < ten)" in setupgust.f90). In this work, the same code would be also used for 3DRTMA run. - Need to add code in GSI read in the Roughness Length (ZNT) from the firstguess file, or using the default value of roughness set in GSI for regional analysis (which is 0.05, might be too small for some area).
8 participants
Description
Motivation
Method
Summary_of_Changes_in_GSI
See this Google document -- "Notes on Changes in GSI for Height Adjustment in Analysis of Wind Gust"
Fixes Issue #857
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Checklist
my updated GSI commit #d69a6fd vs control/original GSI code (commit #bed9513)
Here is the reports of the regression tests on WCOSS2 (Dogwood):
Here is the reports of the regression tests on Hera: