-
Notifications
You must be signed in to change notification settings - Fork 148
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
Updates for handling CrIS SWIR data #587
Conversation
…r. Codes: qcmod.f90, setuprad.f90, crtm_interface.f90
…; updating scene-dependent error subroutine for CrIS
…hannel for use in thinning, if the LW band is not present
@erinjones2 , please assign two peer reviewers to look over the changes in this PR. This is part of step 4 under GSI: How to Make Changes. |
@RussTreadon-NOAA, @ADCollard and @emilyhcliu have agreed to review this PR; it doesn't look like I have permissions to assign them as reviewers. |
Thank you @erinjones2 for reaching out to two peer reviewers. @ADCollard and @emilyhcliu have been added as reviewers to this PR. |
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 am not at all sure what the physical rationale is for doing separate longwave and shortwave cloud detections. The cloud detection scheme is not even physically appropriate for channels affected by sunlight.
If there is a good reason, we should also consider the most flexible way of implementing this so it is appropriate for all instruments.
src/gsi/qcmod.f90
Outdated
do i=1,nchanl | ||
if(wavenumber(i) > r2000)then | ||
! check for sun glint for CrIS at wavenumbers shortward of 2386.88 | ||
if(cris)then |
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.
Is there a reason for this if (cris) logic? Wouldn't the sun-glint test be applicable to all ir sounders?
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.
It should be. We were focused only on looking at and making modifications for CrIS SW, hence the if (cris) logic. I can modify the code to make this generic for all SW, if that's preferred.
src/gsi/qcmod.f90
Outdated
@@ -2223,7 +2255,7 @@ subroutine qc_irsnd(nchanl,is,ndat,nsig,ich,sea,land,ice,snow,luse,goessndr, & | |||
if (qc_noirjaco3_pole .and. (abs(cenlat)>r60)) zero_irjaco3_pole=.true. | |||
|
|||
! If GOES and lza > 60. do not use | |||
if( goessndr .and. zasat*rad2deg > r60) then | |||
if( goessndr .and. zasat*rad2deg > r60 .and. (.not. cris_sw)) then |
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 would cris_sw be true for GOES? Or do you want to generalise this for all IR instruments?
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.
cris_sw shouldn't be true for GOES; this is a redundant check because I'm paranoid. It can be removed if preferred.
@@ -2237,7 +2269,9 @@ subroutine qc_irsnd(nchanl,is,ndat,nsig,ich,sea,land,ice,snow,luse,goessndr, & | |||
sfchgtfact=one | |||
if (zsges > r2000) then | |||
! QC1 in statsrad | |||
if(luse)aivals(8,is) = aivals(8,is) + one | |||
if (.not. cris_sw) then |
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 does the SW changes affect the QC decisions over high topography?
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.
It doesn't; this is included so obs aren't counted more than once, since qc_irsnd is called twice in setuprad (calling qc_irsnd twice pertains to the LW vs SW cloud detection... see cloud detection comment)
@ADCollard The cloud detection in our experiments was done using SW for a couple of reasons: First, we were wanting to use CrIS as a proxy for a sensor without a LW band; second, we were wanting to test whether the cloud detection scheme could be done using SW channels and still produce reasonable results. It seems as if it does, so we kept it that way: We also end up with more CrIS SW points passing QC when we use SW for cloud detection, which we attributed to the SW's higher vertical resolution. The LW channels can certainly be used instead, and the code can be modified accordingly if desired (this would also remove an extra call to qc_irsnd, but remove more SW obs in QC). Alternatively, the code can probably be modified to only use the SW channels for cloud detection if the LW channels aren't available... just let me know. |
@ADCollard @emilyhcliu Getting back to this now that SNPP may be switching to MW+SW. The changes that we discussed in late June have been made in my fork; the fork will likely need to be updated now to be in line with the main develop branch again. Will any other changes be required wrt the SW updates? |
For the time being close this PR with the possibility of this PR being reopened at a later date or a new follow-on PR being created. |
Description
These updates have been made to enhance the processing of CrIS SWIR observations:
Fixes #546
Type of change
How Has This Been Tested?
Experiments were run with these updates on Orion (and with earlier implementations of the updates on Hera). A summary of GSI enhancements and experiment results can be found here -
GSImeeting_20230509_ejones.pptx
These changes should not impact results if CrIS SWIR channels are not actively assimilated.
Regression tests were performed on Hera and can be found in /scratch2/NESDIS/nesdis-rdo1/Erin.Jones/regression_testing/tests_20230627
Results:
netcdf_fv3_regional failed a scalability test:
hwrf_nmm_d3 failed a time threshold test for hwrf_nmm_d3_loproc_updat (hwrf_nmm_d3_hiproc_updat did not fail):
Checklist
DUE DATE for this PR is 8/10/2023. If this PR is not merged into
develop
by this date, the PR will be closed and returned to the developer.