Document PB2NC's handling of quality markers

[JohnHalleyGotway]

Describe the Task

This is a small documentation-only task to clarify/document PB2NC's handling of quality markers for derived variables, like CAPE. Also document if/how quality markers apply to the derivation of time summaries. These questions arose via GitHub discussions and should be clarified in the documentation.

Time Estimate

2 hours

Sub-Issues

Consider breaking the task down into sub-issues.
None needed.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required: @JohnHalleyGotway
• Select scientist(s) or no scientist required: No scientist needed

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy
  No impacts.

Task Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[JohnHalleyGotway]

I've realized/documented the fact that time summaries are always written by PB2NC with a quality flag of NA. For other derived obs, like CAPE, DPT, and so on, it's computed as the maximum of the quality marks that went into the derivation.

So the question is...

• Should we leave the functionality as is and be satisfied that we documented it?
• Or should we modify the library code used to compute time summaries, check to see if the all the quality "strings" actually contain integers, and if so, report the maximum of those integers?

Per @TaraJensen, we should investigate the second option. In BUFR, lower integers are better. Technically, someone could run ascii2nc to compute time summaries with integer qm flags where HIGHER is better.

So attempt to only enable this for PB2NC, not the other point pre-processing tools.

[JohnHalleyGotway]

@TaraJensen I investigated updating the handling of quality flag values for time summaries and have decided that it would constitute too large of a change to be introduced during the MET 11.0.0 pre-release cycle.

I do recommend that we make this change, but I think we should do it carefully.

MET supports the computation of several types of time summaries (min, max, range, mean, stdev, median, P##, sum). For the min, max, median, and perhaps P## options, we should use the quality mark of the actual corresponding observation. For the range, we should report the max quality mark of the min/max value. For the mean, stdev, and sum, we should report the max quality mark for all observations in the time window.

I wrote up issue #2363 to describe these proposed changes.