Variables missing from ozone diagnostic files #618
Comments
|
Tag @CoryMartin-NOAA for awareness. g-w PR #1835 likely depends on resolution of the ozone diagnostic file problem documented in this issue. |
|
For extra information: Previous versions of GSI had ozone diagnostic files that had these fields: But in develop, they have only this field: I'm not sure if this is an intended change or not. If so, then the EnKF code needs updated appropriately to handle reading in these ozone diagnostic files. Conventional and radiance diagnostic files still have the |
|
Jim Jung reports the same problem from his global parallels on S4.
|
|
Orion test I reproduced @CoryMartin-NOAA and @wx20jjung eupd failures using the NOAA-EMC/GSI GSI PR #591 added a call to The However, @HaixiaLiu-NOAA made the following comment in issue #564
This echoes @CoryMartin-NOAA 's question. There is a mismatch between how
@jack-woollen's reply indicates that the jacobian question was raised by @jswhit and that the issue has been fixed
@jack-woollen and @jswhit , did we loose a change to We need a fix. We can not run global parallels using NOAA-EMC/GSI |
|
@RussTreadon-NOAA @CoryMartin-NOAA Sorry, I hadn't a clue before reading the latest notes. Now I see comparing to one version back there were three lines removed from setupoz rouine setupozlay. This probably done at Goddard. The three calls removed were presumably replaced by the commented out lines. If simply reverting these back in fixes the problem that would be nice. Thanks for the pointers. |
|
Thank you @jack-woollen for taking a look. Let me create a branch off |
|
Create branch |
|
Orion ctests The rtma failure is due to A check of the Rerun rtma ctest with following result The failure is due to The The updat Rerun the rtma test one more time. This time the test passed. Hera ctests This is an expected result. The change in WCOSS2 ctests The netcdf_fv3_regional test failure is due to A check of the Summary |
|
20210814 18 gdas C192L127 test on Orion Run g-w The minimum and maximum increments for u, v, tv, ps are non-physical. As a test, rerun with the oznstat file removed. This time the increment ranges look reasonable. Run Run Run Run Run Run Why does the combination of omi and ompstc8_n20 yield such large analysis increments? Each by itself does not result in non-physical increments? A closer look at |
|
Tagging @jack-woollen , @HaixiaLiu-NOAA , @jswhit , and @CoryMartin-NOAA for awareness. I'll repeat the omi & ompstc8_n20 test tomorrow on Hera to confirm similar behavior. |
|
Its possible I made a mistake in commenting out the first two lines of the if block below. |
|
Hera test However it is not the orders of magnitude larger range found on Orion. Additional investigation is necessary. |
|
Change GSI hash in working copy of Hera g-w to install GSI These are exactly the same {min,max} range values generated from the run using This calls into question the 9/10 tests run on Orion. The builds and setup need to be re-examined to ensure everything was done something correctly. |
|
Orion tests - rerun Install fresh copy of g-w Repeat Hera test by first installing GSI Install The two sets of analysis increment ranges are identical. This agrees with the Hera test results and expectation. The changes in PR #591 should not change analysis results. It is not clear why the 9/10 Orion test generated unexpected, non-physical results. Since Hera and Orion tests are now consistent and ctests pass, I'll stop here. |
@jack-woollen , I can not reproduce the 9/10 Orion cycled test results. 9/11 Orion tests behave as expected as do Hera tests. Yesterday's results must be due to operator error (me). There must be a mistake in my 9/10 experiment, g-w, or gsi setup. |
) **Description** PR #591 removed jacobian information from the netcdf ozone diagnostic file. This caused `enkf.x` to crash. This PR adds the removed ozone jacobian arrays back to the netcdf ozone diagnostic file. Fixes #618 **Type of change** - [x] Bug fix (non-breaking change which fixes an issue) **How Has This Been Tested?** The revised code was tested in the 20210814 18 gdas cycle of a C192L127 enkf parallel. The updated `gsi.x` created an oznstat file which was successfully processed by `enkf.x`. **Checklist** - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] New and existing tests pass with my changes
GSI PR #591 modified the information written to GSI ozone diagnostic files. Some variables are now missing and this breaks the EnKF update step,
eupd, in the global-workflow. This issue is opened to document the problem and develop a fix.The text was updated successfully, but these errors were encountered: