-
Notifications
You must be signed in to change notification settings - Fork 10
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
GitHub Issue NOAA-EMC/GSI#604 Undefined values found in radar reflectivity direct DA #605
GitHub Issue NOAA-EMC/GSI#604 Undefined values found in radar reflectivity direct DA #605
Conversation
src/gsi/read_dbz_nc.f90
Outdated
if(l4dvar.or.l4densvar) then | ||
timeb=real(mins_an-iwinbgn,r_kind) | ||
else | ||
timeb=zero |
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.
Why could we just use the " timeb=real(mins_an-iwinbgn,r_kind)" ? The obs relative to the analysis time could be non-zero even for 3dvar . When the fget is used for 3dvar, the non-zero timeb would also produce differences for timeb=0 case. So, I think if the general use of "timeb=real(mins_an-iwinbgn,r_kind)" does work, this should be unanimously used.
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.
In my understanding, the radar reflectivity NetCDF file doesn't include the observation time and it is assumed that the observation time is the same as the analysis time. That is why I used "timeb=real(mins_an-iwinbgn,r_kind)" for 4DVar and 4DEnVar.
When the fget is used for 3dvar, the non-zero timeb would also produce differences for timeb=0 case.
Are you pointing out the case of FGAT (First Guess at Appropriate Time)? I forgot to think about FGAT. I will fix to use "timeb=real(mins_an-iwinbgn,r_kind)" also in the 3DVar case.
a4dc2cc
to
b96a464
Compare
src/gsi/read_dbz_nc.f90
Outdated
@@ -337,6 +338,7 @@ subroutine read_dbz_nc(nread,ndata,nodata,infile,lunout,obstype,sis,hgtl_full,no | |||
|
|||
call w3fs21(iadate,mins_an) !mins_an -integer number of mins snce 01/01/1978 | |||
rmins_an=mins_an !convert to real number | |||
timeb=real(mins_an-iwinbgn,r_kind) |
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.
Sure. this should work for various time-related situations.
An update: Please allow me share my clarified thoughts now:(.
I think here we should stick to the "assumption" that all dbz obs are at analysis time. Hence, the timeb should always be timeb=0. How will it be used in 4d da and fgat should be considered in other places including the specification of variables like t4df.
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.
In other places, timeb is defined by (observation time) - (head of assimilation window) for 4D DA. In case (observation time) = (analysis time) is assumed, 'timeb=real(mins_an-iwinbgn,r_kind)' is required. In the case of 'timeb=zero', GSI regards that reflectivity was observed at the head of the assimilation window, but we don't expect that.
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.
In read_dbz_nc.f90, timeb is commented as "observation time relative to analysis time" and is used as it as in
cdata_all(7,iout) = timeb*r60inv ! obs time (analyis relative hour)
So, please stick to this definition of timeb. If this sub couldn't have any information about actual observation time, just let timeb=0 for both 4dvar/fgat and 3dvar.
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.
I confirmed that reflectivity was assimilated at the head of the assimilation window (not analysis time) in the case of 'timeb=zero' in 4DEnVar. So, I think this comment is wrong. How should I do?
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.
@shoyokota I think t4dv is also undefined as shown below. Is this an issue when you ran your case with debug mode gsi? That will be great if it is also taken care of in this PR. From my point of view, it think it could be defined as timeb+ (analysis time - the beginning time of the time window). You could see how it is set in other observation 's setup subroutine
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.
@TingLei-NOAA This t4dv is only used in thinning independently in each timeslot. However, it is assumed that all the inputted reflectivity observations were observed at the analysis time here. So, we don't have to input any specific times as t4dv here, and the result doesn't depend on t4dv as long as it is the same in all reflectivity observations. Here, I modified here to timedif=zero simply to prevent undefined values.
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.
@shoyokota if you runs doesn't go through this part. We could let it be the current codes (with that comment) for future developers to take care . It should be analysis time - the begin of the time window. We don't need to enforce this part also work with that all obs are being at the analysis time . And, even with assumption/requirement that dbz obs being on the analysis time, the fgat/4dvar could still be invoked for other observations could be distributed on different time levels. So, I prefer leaving it to be updated in the future rather than making a change with unnecessary assumptions.
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.
This part is computed in the case of radar_no_thinning=F even now, so I think some kind of fix is needed. Is it better to add comments such as 'observation time (hour) should be input for 4D observations in 3D thinning, but 3D observations here' at the right of 'timedif=zero'?
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.
@shoyokota Thanks for the clarification. I will add my thoughts on those specific codes respectively.
b96a464
to
664d072
Compare
src/gsi/read_dbz_nc.f90
Outdated
@@ -337,6 +338,7 @@ subroutine read_dbz_nc(nread,ndata,nodata,infile,lunout,obstype,sis,hgtl_full,no | |||
|
|||
call w3fs21(iadate,mins_an) !mins_an -integer number of mins snce 01/01/1978 | |||
rmins_an=mins_an !convert to real number | |||
timeb=real(mins_an-iwinbgn,r_kind) |
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.
Ok, I think now, we agree timeb should be the observation time relative to the begin of the time window.
You could change that wrong comment . And, could you confirm in "timeb=real(mins_an-iwinbgn,r_kind)" , iwindbgn is in the same time coordinates as mins_an?
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.
Yes, I tested 'timeb=real(mins_an-iwinbgn,r_kind)' with 4DEnVar, and radar reflectivity was assimilated at the analysis time as we expected.
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.
Good. Thanks.
src/gsi/read_dbz_nc.f90
Outdated
@@ -452,7 +454,7 @@ subroutine read_dbz_nc(nread,ndata,nodata,infile,lunout,obstype,sis,hgtl_full,no | |||
|
|||
|
|||
ntmp=ndata ! counting moved to map3gridS | |||
timedif=abs(t4dv) !don't know about this | |||
timedif=zero |
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.
Could you add a comment that here, the obs are assumed on the analysis time?
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.
That is great for this PR to sort out some obs time related issues in dbz obs processing.
Thanks to the developer!
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.
Just , hopefully, the last question. For line 493 (read_dbz_nc.f90)
cdata_all(7,iout) = timeb*r60inv ! obs time (analyis relative hour)
The comments should be changed to "!obs time relative to the beginning of the DA window".
664d072
to
7b0d453
Compare
@chunhuazhou Could you review Sho's changes? Thanks. |
@hu5970 could you handle this PR during my absence? |
7b0d453
to
6e9da0e
Compare
I run regression tests on WCOSS2 (cactus):
The netcdf_fv3_regional and hwrf_nmm_d3 failed because of the scalability test. Not the critical failure. |
@shoyokota @hu5970 |
The current GSI develop branch has some trouble to run under DEBUG mode. |
@hongli-wang Since such issue was not found in @shoyokota 's dbz DA using GSI at debug mode, could you do some further tracing on this issue? Missing values? a wrong array index? And you could make quick PR with the fix. Or if your case are on (or can be transfered to ) hera or orion, you can point me to your case and I could have a look into it. Thanks! |
@hongli-wang @hu5970 Thank you for letting me know the crash. Even after the current modification in this PR, it seems that some undefined values are still detected in the case of "DIAG_RADARDBZ=T." (My test was being done with "DIAG_RADARDBZ=F.") Now I'm working on additional modification to prevent these undefined values. I guess it can be prevented by small modification of read_dbz_nc.f90. Could you extend the due date of this PR until completing my additional modification and its review? |
@shoyokota @TingLei-NOAA |
@shoyokota Please sync with develop and test the code again. This PR is straightforward and we should be able make it in time. Thanks, Ming |
4fea628
to
be615b3
Compare
be615b3
to
d4319a1
Compare
@hu5970 @ShunLiu-NOAA The modification and the sync with develop have been done. Could you confirm if it is possible to be merged? |
@shoyokota I will run a regression test on WCOSS2. Could you post your ORION regression test result here? |
d4319a1
to
fa93eb7
Compare
@ShunLiu-NOAA I did sync with the current develop branch. Now the regression tests are running on Orion. Once they are finished, I'll show the results. |
WCOSS2 regression tests were completed on CACTUS. The result is posted here. Test project /lfs/h2/emc/lam/noscrub/emc.lam/Shun.Liu/gsi_regression/GSI/build |
The ORION regression test was also completed. The test #4 exceeded maximum allowable threshold time and failed the scalability test. The test #8 failed only the scalability test. However, these are not fatal failures and all tests were reproducible.
|
@ShunLiu-NOAA should one of us send a request to merge this PR tomorrow? Thanks, Ming |
@shoyokota could you please sync your branch with "develop"? Ming and I will run regression test again on WCOSS2 and HERA. Hopefully, we can merge this today. |
fa93eb7
to
d13602f
Compare
@ShunLiu-NOAA @hu5970 I synced my branch with "develop" now. |
@shoyokota Thanks, Shun and I are working on regression cases on Hera and WCOSS2. |
@shoyokota could you please sync your branch with develop again? there is another PR merged into develop. Thank you. |
…ivity direct DA
d13602f
to
607acd2
Compare
@ShunLiu-NOAA I synced it. |
The regression test on Hera are all good:
|
Test project /lfs/h2/emc/lam/noscrub/emc.lam/Shun.Liu/gsi_regression/GSI/build 100% tests passed, 0 tests failed out of 9 |
Description
To prevent some undefined values found in the radar reflectivity direct DA (if_model_dbz=T and l_use_dbz_directDA=F), corresponding parts are fixed. It doesn't change the result except for the case of the execution with the debug option.
Fixes #604
Type of change
How Has This Been Tested?
The radar reflectivity DA test with the RRFS setting was done on Orion. After this modification, EnVar was completed even with the debug option. This modification didn't change the result in the test without the debug option.
Checklist
Due date for this PR is 9/15/2023. If this PR is not merged into
develop
by this date, the PR will be closed and returned to the developer.