Modify KX calculation for OMPS ozone (NPP, N20, N21) #336
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
to +5 for ozone types only. This will fix a KX conflict for N21 OMPS
gmao-msienkie
added
the
0 diff
Spire and PlanetIQ currently assimilated GeoOptics may be available later Sentinel-6A, GRACE-C, GRACE-D available but not assimilated
|
Added some missing entries to kx_register.tbl and conv_kx.readme for GPSRO - GeoOptics, PlanetIQ, Spire. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The KX assignment for ozone types consists of finding a base value for the instrument type in the sats/isats lookup tables in 'odsmeta.h' and then adding an offset based on the satellite platform hosting the instrument.
Kris Wargan asked me about how to find the KX values for OMPS-NM (ompsnmeff) on n20 and n21 and OMPS-LP (ompslpnc) on n21. We don't have any data from either so this is just to have them in R21C for future use.
The base value for 'ompslpnc' is 337, which is also the KX value assigned to NPP since the current offset value for NPP is zero. The KX for ompslpnc_n21 would be 358, which conflicts with NOAA-8 SSU. This is not desirable but would probably be OK since the instruments provide different kinds of observations (radiance vs retrieved ozone).
However there is a real problem with 'ompsnmeff'. The base value is 428 - so the base+offset for ompsnmeff_n21 is 449. This is a real problem since kx=449 is currently used for OMPS ozone measurements.
My proposed fix for this, and it is kind of a kludge, is to modify the offset value for NPP for ozone only, so that we can adjust the base values for the 'omps' types in the isats lookup table so that the calculated KX for N20 and N21 do not conflict with already existing types. The offset value for NPP for radiance types remains as zero since we have already been using N20 ATMS and CrIS and do not want to change the KX values for those instruments.
With the offset value for ozone NPP modified to 5 and editing the isats table to subtract 5 from all the values for OMPS data types we end up with KX=443 and 444 for ompsnmeff N20 and N21, and kx=353 for ompslpnc N21. All of the NPP KX values for ozone will remain the same as before.
This could be confusing but the ODS KX generation is already confusing so what's one more special case? ;-)
I have another branch with these changes 'feature/msienkie/5.29odskxOMPSn21' that is based on the GEOSadas 5.29.4 code that I used to duplicate GEOSIT when testing the SLP fix. It might be easier to merge that version into the GEOSIT branch especially since there have been additional changes in the odsmeta.h since that branch was created.
I have tested this change in the 'feature/msienkie/5.29odskxOMPSn21' branch by converting GEOSIT diag files to ODS and observing that there was no change in the KX values for NPP or radiance N20 types.
I am labeling this zero diff since the new OMPS data in question does not exist yet - this is just for providing for future changes in the data stream.