Adding GLM Flash Extent Density to GSI Observer #588
Comments
|
WCOSS2 ctests
The following failures are due to non-reproducible analysis results between the update (
The A check of the does not reveal anomalous behavior. This is a non-fatal fail. The timing scalability test should be examined and either improved or removed to avoid misleading ctests results.
|
|
Orion ctests The The loproc control wall time is noticeably larger than the update. The hiproc wall times are comparable. This is not a fatal fail. The Comparison of wall times shows a mixed bag The hiproc update wall time is about 12 seconds higher than the control but the loproc control is 3x greater than the update. There is considerable variability in the wall times for the control and update. This is not a fatal fail. The non-reproducible behavior between update and control observed on WCOSS2 is not observed on Orion. |
|
I did regression test for this PR on WCOSS2: The reason for RTMA failure is: The test results on Cactus: |
|
Thank you very much, @hu5970 , for running this test. Your results make sense. Mine do not. Let me attempt to replicate your results |
|
I ran
Ming's pass result is expected given the nature of the Is something wrong with my WCOSS2 (Cactus) environment? I'll continue this investigation tomorrow. Sorry for delaying PR #590. Hopefully the reason for the odd results above can be quickly sorted out tomorrow. |
|
I recompiled the develop twice with Russ' ".bashrc" and recompiled the fed branch. Then I rerun the "netcdf_fv3_regional" twice. Both are passed. Still cannot figure out why executable from Russ produced different results. When use Russ's develop executable, the "netcdf_fv3_regional" fail. The cost function for radiance are different: |
|
Interesting result @hu5970 . I, also, can not explain the observed behavior. I built Who else on the RRFS team has WCOSS2 access? (S)he could repeat our tests and see what happens. I don't want to delay PR #590 but we need an explanation of the observed behavior. |
|
@RussTreadon-NOAA I used ems.lam account to build regression test suite and got the same results as my own account. |
|
Excellent idea, @hu5970 . Let me try both the emc.global and emc.da accounts. |
|
Use PR605 to test the regression suite issue we have for this PR. All tests are under Build PR605 executable Setup regression: Run regression: The results of the test: Repeat netcdf_fv3_regional case: The global enkf fails because of namelist. PR 065 need to be synced with develop. Checking the iteration of the netcdf_fv3_regional: Those are the same values from PR590 tests. |
|
@hu5970 , I can reproduce your PR #590 results if my working copy of Cactus Cactus The The ctests copy their fix from the working copy of This is odd. I can not explain what I see. |
|
I used the same steps to run regression tests for PR 614: Both "netcdf_fv3_regional" and "hwrf_nmm_d3" can reproduce the control results. No critical failures in the test. The check of the first iteration for netcdf_fv3_regional: |
|
I thought that fix under "develop" is not needed for the regression test and that is why I usually run regression test without fix filled under "develop". But I did the new test with fix filled with I thought it is the same like clone with "--recursive" because the fix is the only submodule. I am trying to clone develop with "--recursive" and then rerun the regression tests. If it produces different results from "develop" without "--recursive", I will compare two "develop"s to see if there are difference we should investigate. |
|
@RussTreadon-NOAA I cloned the develop: git clone https://github.com/NOAA-EMC/GSI.git --recursive The test of "netcdf_fv3_regional" still has the same results: |
|
@hu5970 , you've tried very hard to reproduce what I see. You can't do so from either your WCOSS2 account or ems.lam. I see differences between develop and GSI_FED depending on whether or not develop fix is empty or filled. This does not make sense but the results are on disk. I am not the handling reviewer for PR #590 I can not approve or merge PR #590. This does not prevent others from approving and merging PR #590. |
|
@RussTreadon-NOAA Thanks for your hard efforts to make sure the robust of the GSI system. I will try to make a fresh branch and merge the code from David in case there are some unknown history in his branch. I will do test again with new branch and then maybe ask an EMC colleague to help run a single case "netcdf_fv3_regional" to confirm. If the new branch and tests look good, I will try to merge the code. |
|
Thank you @hu5970 |
<!-- PLEASE READ --> <!-- Before opening a PR, please note these guidelines: - Each PR should only address ONE topic and have an associated issue - No hardcoded or paths to personal directories should be present - No temporary or backup files should be committed - Any code that was disabled by being commented out should be removed --> **Description** Initialization of the operational RRFSv1 will include assimilation of flash-extent density (FED) observations from the GOES Geostationary Lightning Mapper (GLM). The current PR is the first of at least 3 that will be needed to introduce the capability of FED assimilation into the code and regional workflow. The new capabilities that are added to GSI are: * reading NetCDF FED observations * applying an observation operator that maps the model state to FED. Much of the code was originally developed by Rong Kong at OU-CAPS (Kong et al. 2020, Wang et al. 2021, Kong et al. 2022; https://doi.org/10.1175/MWR-D-19-0192.1, https://doi.org/10.1175/MWR-D-20-0406.1, https://doi.org/10.1175/MWR-D-21-0326.1). Recently, the observation operator has been modified by Amanda Back and Ashley Sebok based on tests with regional, convection-allowing FV3 forecasts. The new observation operator includes a cap of 8 flashes / minute for both the observed and simulated FED. The observation operator is specific to the 3-km regional FV3 application in RRFS. Development of a more general observation operator is left to future work. Fixes #588 <!-- Please include relevant motivation and context. --> <!-- Please include a summary of the change and which issue is fixed. --> <!-- List any dependencies that are required for this change. --> <!-- Please provide reference to the issue this pull request is addressing. --> <!-- For e.g. Fixes #IssueNumber --> **Type of change** Please delete options that are not relevant. - [ ] Bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update **How Has This Been Tested?** Initial tests were with NOAA-EMC GSI-EnKF code obtained in April 2023 and modified to include the assimilation of FED observations. A prototype of RRFSv1 was cycled hourly for 2.5 days, and the EnKF assimilation included FED data assimilation. For the current PR, only the GSI observer with FED (and radar reflectivity) observations was tested. It produces identical results to those obtained in April 2023. <!-- Please describe the tests that you ran to verify your changes and on the platforms these tests were conducted. --> <!-- Provide instructions so we can reproduce. --> <!-- Please also list any relevant details for your test configuration --> **Checklist** - [ ] My code follows the style guidelines of this project - [X] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] New and existing tests pass with my changes - [ ] Any dependent changes have been merged and published **DUE DATE for this PR is 8/24/2023.** If this PR is not merged into `develop` by this date, the PR will be closed and returned to the developer. --------- Co-authored-by: Ming Hu <Ming.Hu@noaa.gov>
Preparing for GSI-EnKF assimilation of GLM flash extent density in Rapid Refresh Forecast System (RRFSv1). First, FED observation handling and observation operator will be added to GSI.
The text was updated successfully, but these errors were encountered: