update GPSRO obs error and add additional data #825
Conversation
|
@RussTreadon-NOAA : Could you please add @ADCollard , @emilyhcliu , and @LidiaCucurull-NOAA as reviewers? Thank you! |
|
@XuanliLi-NOAA , Lidia can not, at present, be assigned as a reviewer. She does not belong to NOAA-EMC. I sent her an invitation to be an outside collaborator with read permission. If you have not yet done so, please reach out to Lidia and share with her your request that she review this PR. |
|
Thank you so much, Russ. I'll send an email to request Lidia's review on this PR. |
|
WCOSS2 ctest results The
|
|
Let me double check the qc section, it should be about the same. |
|
This is expected, I compared the numbers with those from my full resolution experiments. They are comparable. Penalty is smaller because of the larger obs error. |
There was a problem hiding this comment.
The changes look good. Please, double check the type of processing for GRACE-FO and Sentinel-6 in read_gps.f90. I believe these missions are not processed by UCAR/CDAAC, but unless I am reading it wrong, they are under the CDAAC group.
Also, you might want to consider removing new QC=7 since MetOP data is no longer rejected (and biases for future EPS missions will no longer exist either). Finally, the header text in setupbend.f90 seems to suggest that GRACE-FO is only assimilated below 8 km (the "< 8km" should be removed.)
|
@LidiaCucurull-NOAA , I just want to confirm, should we switch GRACE-FO and Sentinel-6 from the pccf to qfro check? Or should we remove them from both checks? They should have a quality flag. |
|
Xuanli and I met today. We discussed the code changes and some of my previous comments. I will check on which are the processing center for satellites ids 803, 804 and 66 to identify the right QC process to follow in read_gps. Also, it appears that the variable "repe_gps" is no longer used in setupbend.f90 with the new hybrid error model. Xuanli will test the code with the removal of this variable (which currently needs to be computed for each individual observation within a profile). This would save computational time and would make the code cleaner. |
|
What is the status of this PR? |
src/gsi/setupbend.f90
Outdated
| use m_gpsrhs, only: qcfail_jac | ||
| use m_gpsrhs, only: qcfail_one,qcfail_two,qcfail_three,qcfail_five | ||
| use m_gpsrhs, only: qcfail_six,qcfail_seven,qcfail_eight |
There was a problem hiding this comment.
@XuanliLi-NOAA Just curious and a suggestion.
The previous qc flags were: qcfail_loc,qcfail_high,qcfail_gross,qcfail_jac
It looks like you replace some of them to qcfail_one, qcfail_two, .... qcfail_eight.
Do these eight qc flags belong to the same type of checks (e.g. gross check) ?
If so, you may consider changing the name of the flag from qcfail_one to qcfail_gross1.
There was a problem hiding this comment.
No, they are not the same type.
qc = 1: beyond model top or bottom
qc = 2: gpstop (55 km or 45 km for commercial data)
qc = 3: gross check
qc = 4: super refraction
qc = 5: background bending angle > 0.05 rad
qc = 6: statistic (cutoff) QC
qc = 7: MetOp data < 8 km
qc = 8: ddnj < 0
The above information can be found in issue #819. I'll added this information in setupbend as comments. Thanks for the question!
|
@RussTreadon-NOAA @emilyhcliu , for some reason, my previous comment is gone. Here it is again. Lidia and I went through the code changes for the obs error and those look fine. She suggested to remove the redundant computation of repe_gps and clean the qcfail categories. Those changes has been made to setupbend and other related subroutines. I have conducted single cycle GSI tests and the results are as expected. The code is ready to be pushed. However, after confirming with UCAR and DWD regarding the quality flag for different satellite missions, Lidia suggested unifying it in read_gps. I conducted a single-cycle GSI test for 2024-10-22 12 UTC with this change, and the results indicate some differences. I'm not sure if we should examine this further before including it in the PR. Our old code used PCCF for CDACC and commercial data and QFRO for ROMSAF/EUMETSAT data. The new code now uses QFRO for all data. Here is the comparison of the old vs. new obs number in the diag file for 2024-10-22 12 UTC: The new diag file contains about 0.5% more data when switching to QFRO for this particular cycle (numbers may vary for other cycles). The difference is caused by Spire data, which are processed by UCAR (DO-4 data) or ROMSAF (EUMETSAT-purchased Spire). Previously, we didn't separate Spire data based on the processing center, so all Spire data used PCCF as the quality flag. However, some EUMETSAT Spire data have bit 6 (refractivity) on but bit 5 (bending angle) off (e.g., QFRO flag table 1,3,6,7). These profiles have PCCF = 0, meaning that they were rejected in the old code, but retained in the new code with QFRO. Note that this QFRO bit 5 quallity flag has been implemented for ROMSAF data (including MetOp) for a long time, and I do see MetOp profiles with bit 5 = 0 and bit 6 = 1, and these profiles were assimilated in GSI. I'm not sure whether it would be necessary to conduct an experiment before including this change. I have reached out to Lidia for her suggestions. |
|
@XuanliLi-NOAA : Your branch XuanliLi-NOAA:roobserr_update is three commits behind the head of GSI |
|
Thank you @XuanliLi-NOAA for keeping your branch in sync with |
|
@RussTreadon-NOAA Thank you so much for the reminder! |
|
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->I answered Xuanli in my previous email. We discussed the changes and all looks good. Regarding the last comment on the QC flags, no additional experiments are necessary. Let me know if there is anything else I need to do on my end. Thanks,Lidia --Lidia Cucurull, Ph.D., FAC-P/PMDirector, Quantitative Observing System Assessment Program (QOSAP)Office of Research, Transition, and Application (ORTA)NOAA Oceanic and Atmospheric ResearchU.S. Department of Commerce325 Broadway, R/OCAOBoulder, CO 80305 USAMobile: (720) 771-0830 | Time zone: US Mountain Timehttps://qosap.research.noaa.gov From: Xuanli Li ***@***.***>Date: Monday, February 10, 2025 at 9:33 AMTo: NOAA-EMC/GSI ***@***.***>Cc: Lidia Cucurull ***@***.***>, Mention ***@***.***>Subject: Re: [NOAA-EMC/GSI] update GPSRO obs error and add additional data (PR ***@***.*** @emilyhcliu , for some reason, my previous comment is gone. Here it is again.Lidia and I went through the code changes for the obs error and those look fine. She suggested to remove the redundant computation of repe_gps and clean the qcfail categories. Those changes has been made to setupbend and other related subroutines. I have conducted single cycle GSI tests and the results are as expected. The code is ready to be pushed.However, after confirming with UCAR and DWD regarding the quality flag for different satellite missions, Lidia suggested unifying it in read_gps. I conducted a single-cycle GSI test for 2024-10-22 12 UTC with this change, and the results indicate some differences. I'm not sure if we should examine this further before including it in the PR.Our old code used PCCF for CDACC and commercial data and QFRO for ROMSAF/EUMETSAT data. The new code now uses QFRO for all data. Here is the comparison of the old vs. new obs number in the diag file for 2024-10-22 12 UTC:old (pccf) new (qfro)Total obs: 806859 Total obs: 809229 (2370 data from 11 Spire profiles)The new diag file contains about 0.5% more data when switching to QFRO for this particular cycle (numbers may vary for other cycles). The difference is caused by Spire data, which are processed by UCAR (DO-4 data) or ROMSAF (EUMETSAT-purchased Spire). Previously, we didn't separate Spire data based on the processing center, so all Spire data used PCCF as the quality flag. However, some EUMETSAT Spire data have bit 6 (refractivity) on but bit 5 (bending angle) off (e.g., QFRO flag table 1,3,6,7). These profiles have PCCF = 0, meaning that they were rejected in the old code, but retained in the new code with QFRO. Note that this QFRO bit 5 quallity flag has been implemented for ROMSAF data (including MetOp) for a long time, and I do see MetOp profiles with bit 5 = 0 and bit 6 = 1, and these profiles were assimilated in GSI.I'm not sure whether it would be necessary to conduct an experiment before including this change. I have reached out to Lidia for her suggestions.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@LidiaCucurull-NOAA @emilyhcliu: The new push cleans up repe_gps computation (old obs error) in setupbend and unified the quality flag in read_gps. Previously, CDACC data used PCCF and ROMSAF data used QFRO. In the current code, all missions use QFRO bit 5 as the quality flag for bending angle and bit 6 for refractivity. |
|
Looks good! |
@LidiaCucurull-NOAA Could you please approve if the changes looks good? |
Description
This update includes the following for GPSRO:
Replacing the current GPSRO observation error with the new hybrid three-cornered hat error model.
Allowing Grace-FO (SAID=803 & 804) into GSI.
Turning off the previous MetOp 8-km check.
Adding more QC categories.
More description and the results from the regression tests are included in the issue #819
Resolves #819
Related PR: GSI-fix #26. This PR places Grace-FO (SAID=803 & 804) in assimilate (iuse=1) mode.
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Checklist