-
Notifications
You must be signed in to change notification settings - Fork 31
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
[End-to-End Test Code Sprint] Update GNSSRO converter and YAML #750
Comments
Updating GNSSRO converter and adding the yaml file to GDASApp end-to-end testing based on [#712](#712). New file: parm/atm/obs/config/gnssro.yaml: Added QC filters in the YAML Updated files: parm/ioda/bufr2ioda/bufr2ioda_gnssro_bufr.json: Updated the satellite information ush/ioda/bufr2ioda/bufr2ioda_gnssro_bufr.py: Updated pccf, qfro, and satelliteAscending flag Refer to [issue #750](#750) for testing details. JEDI/GSI comparisons revealed a cutoff near obs=0.03 Rad due to super refraction 2. The number of observations after QC in JEDI is also inconsistent with GSI.
Geopotential Height JEDI vs. GSI Large differences in Geopotential Height occur for data with GSI_qc = 1, or 7 and JEDI_qc = 12, 13, 15, or 19. When these QCs are applied, the data was cycled and the geopotential height was not computed correctly. The figure below shows geopotential height difference for data with large Hofx difference (>2%) and QC = 0: |
@XuanliLi-NOAA @ADCollard @emilyhcliu I've done a bit of digging around with some results below. Though I'm not sure I've found anything especially conclusive but perhaps after some discussion we can plan other things to look at. In order to investigate I added some code to UFO to read the GSI GeoVaLs when running h(x) from fv3-jedi. Basically the code lets you pass both fv3-jedi and gsi GeoVaLs to the operator at the same time and then you can choose which system provides specific variables. I conducted several experiments, altering which variables come from which system: exp_a:
gsi: [t, q, p, gph, sgph]
jedi: []
exp_b:
gsi: [q, p, gph, sgph]
jedi: [t]
exp_c:
gsi: [q, gph, sgph]
jedi: [t, p]
exp_d:
gsi: [q, gph]
jedi: [t, p, sgph]
exp_e:
gsi: [q]
jedi: [t, p, gph, sgph]
exp_f:
gsi: []
jedi: [t, q, p, gph, sgph]
exp_g:
gsi: [t, p, gph, sgph]
jedi: [q]
exp_h:
gsi: [t, q, p]
jedi: [gph, sgph] The following plots show hofx from JEDI vs h(x) from GSI. Blue points are all data and red are passing JEDI QC. In each the left plot shows the differnece (as a percentage) vs the GSI values. The right shows the same metric against impact height, all the problems seem to occur for lowest impact heights (<10km). exp_a, all GeoVaLs from GSI (sanity check on the code): exp_f, all GeoVaLs from JEDI: exp_h, height variable from JEDI: Differences in height GeoVaLS don't seem to be a big contributor. Experiment g is interesting. Where only specific humidity comes from JEDI. That recovers what looks like all the problems of having everything come from JEDI. When I plot specific humidity GeoVaLs (GSI) vs GeoVaLs (JEDI) at all levels there is quite a bit of spread: So perhaps this is the closest thing to a smoking gun to look into. We could look through the pathways by which that variable is derived and sent to the operator. Perhaps there are differences between JEDI and GSI. In JEDI there is no variable change on humidity, it's from restart to operator. But perhaps in GSI it is derived? |
I suppose specific humidity is a variable with small scales and perhaps we have to accept this degree of difference in the GeoVaLs as the interpolation returns different things, neither right or wrong. If the bending angle calculation has a high degree of sensitivity to humidity then we cannot expect similar results to GSI. Have we looked at aircraft humidities yet? |
@danholdaway Thank you so much for conducting the experiments and looking into the differences. Have you done an experiment with only temperature from JEDI? I'm on travel this week to the ROMEX workshop, I'll have more time in next week. |
Yes, that was experiment 'b': |
If you want some other combination of variable let me know and I can run it. |
@danholdaway Thank you! I agree with you, it appears that specific humidity is causing a much larger difference than other variables. |
Picking up on @danholdaway ' s comment
specific humidity and water vapor mixing ratio are similar but different. Could a conversion be occurring somewhere? Could code be assuming one representation when, in fact, the other representation is used? |
@ADCollard a bit more digging... With the help of @DavidNew-NOAA I've compared cubed sphere restarts, cubed sphere history and Gaussian history. There is essentially no difference between the specific humidity in the cube sphere restart and history. The below shows layer 100, tile 2 of the cube. Differences are no more than ~1.0e-4%. Then I tried interpolating David's cube sphere output to Gaussian using the JEDI interpolation (not the interpolation used to get GeoVaLs but something decent from Atlas). This might show us if there is a high degree of sensitivity to the interpolation for sphum. The plots show the difference (%) in temperature and specific humidity at level 100. I guess there isn't too much surprise here. You see some grid imprinting because of small differences in lat/lon probably. The differences are bigger for specific humidity, presumably because of the sharper horizontal gradients. You might argue that differences of 0.3% are quite large but the character of the differences is quite reasonable and aligned with terrain and cube artifacts for the most part. In this case I think you just have to say "it is what it is". With the help of @emilyhcliu the other week I tracked down the Gaussian history that was used by GSI for the original runs that go into @XuanliLi-NOAA's evaluation. Then I did the same thing and interpolated the CS restarts to Gaussian. This time however the differences are much larger than we see for the case David just made. And especially the differences for specific humidity are much larger at ~50%. David's case is C96 and Xuanli's case is C768. Here's that specific humidity plot again but with the colorbars limited to 10%. What I think stands out is that the character of the differences is altered and the grid imprinting is gone. The differences are still somewhat aligned with terrain but there is a clear bias with most of the difference being red (gauss > cube). So perhaps at the time these cycles were made that went into the UFO validation there was some issue or inconsistency between restarts and histories? If we want to delve further into this then perhaps the next thing to try is to make a new cycle where we can first check that the cubes are consistent with the Gaussians? I don't think we can infer too much about h(x) differences when there is this degree of difference in the background that each system receives. It seems that it's possible to have backgrounds closer to each other passed to the respective systems, as with the run David made. @RussTreadon-NOAA could be piggy back off of one of your experiments perhaps? I think we'd just need to turn on the ncdiags from GSI but we could discuss next week. |
Based on the percent differences between the |
@XuanliLi-NOAA is this made using the new 2024-02-19 12z run? |
No, this is still the old date 2021-08-01. I'm trying to make sure things run smoothly with yamls and bufr2ioda for separate satellite, and I'll do the same for the new date when the files are available. |
GNSSRO API updates:
Updated the pccf flag to use the profile pccf for CDAAC RO data
Updated the qfro flag to use the profile qfro for EUMETSAT RO data
Updated the satelliteAscending flag: convert the 3rd bit of qfro to satelliteAscending flag
Updated some information in the json file
Added QC filters in config gnssro yaml.
The text was updated successfully, but these errors were encountered: