Skip to content
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

Modify marine PS fix - check PMO quality before substituting for POB #154

Merged
merged 5 commits into from
Sep 24, 2024

Conversation

gmao-msienkie
Copy link
Contributor

When I was working on modifying some JEDI code to convert prepbufr to IODA I noticed the prepbufr files have a flag PMIN which indicates whether the mean sea level pressure (PMO) was from the marine observation or if it was a derived value.
The data we use from the GDAS does not have any derived/calculated sea level pressures - the DOPMSL flag is false in the prepbufr processing. However I think we would only want the observed pressures used for the substitution.
While I was thinking about checking the PMIN value I also realized that I was not checking the quality flag for PMO (i.e. PMQ) to see if the PMO observation was considered good. I scanned through a few months of gdas.prepbufr files and saw that all of the cases where the PMQ mark was bad (PMQ=15) were also cases where PQM also indicated a bad pressure observation. That means we have not been harmed (yet) by skipping this check.
For the sake of completeness I have added code to check PMQ and PMIN and will not change the pressure value if the mean sea level pressure is bad or is derived rather than measured. I am currently running some tests to see the impact of the change on the assimilation. I think it would not be completly zero-diff since we'll skip modifying POB when PMO is bad. However since these will be bad POB obs that are not used in the assimilation it should not change the analysis results.

@gmao-msienkie gmao-msienkie requested a review from a team as a code owner November 14, 2023 20:09
Copy link

Label error. Requires at least 1 of: 0 diff, 0 diff trivial, Non 0-diff, 0 diff structural, 0-diff trivial, Not 0-diff, 0-diff, automatic, 0-diff uncoupled. Found:

@gmao-msienkie gmao-msienkie added the Non 0-diff The changes in this pull request are non-zero-diff label Nov 14, 2023
… for 256

levels when reading in PMIN but SFCSHP data has only one level (as defined
in the bufr table)
@gmao-msienkie
Copy link
Contributor Author

I'm not sure if I should maybe label this zero diff. I ran a pair of static analysis jobs, one with the x0049 GSIsa.x and one with a GSIsa.x with the modifications in this tag. When comparing the anasa_stats.log files there were six more kx=180 obs that were rejected (presumably not corrected in the new tag because of the PMQ) and six less kx=180 obs monitored and corresponding changes in the stats for kx=180 mon and rej. Presumably these are the same obs that had bad quality marks coming in and were rejected by the gross check because they had not been corrected as in x0049. Everything else in the stats log was identical to all decimal places so I don't think I need to compare analysis fields or obs. Zeroish diff?

@gmao-msienkie
Copy link
Contributor Author

@rtodling hopefully this can go in to a new tag soon (x0050?)
As far as I can tell the extra checking did not make a difference in the results but I think we still should screen the obs in case our input stream changed to include derived values for MSLP.

@gmao-msienkie
Copy link
Contributor Author

@rtodling still hoping to get these changes in the next tag whatever it is.

Copy link
Contributor

@rtodling rtodling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you Meta.

@rtodling rtodling merged commit b6dd4bd into develop Sep 24, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non 0-diff The changes in this pull request are non-zero-diff
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants