dtcenter/MET

Refine PB2NC warning messages about changing Bufr center times

Closed this issue · 0 comments

Describe the Enhancement

This issue is based on the dtcenter/METplus#2642 discussion from @malloryprow. When processing input PrepBUFR and Bufr messages, PB2NC expects the center time of those messages to remain constant. That constant center time, along with the obs_window dictionary from the configuration file, defines the matching observation time window. If the center time does not remain constant, PB2NC prints the following type of warning messages:

WARNING: process_pbfile() -> The observation time should remain the same for all Bufr messages
WARNING: process_pbfile() ->    80151 messages with different reference time (20240102_000000):
WARNING: process_pbfile() -> 	- 20240102_010000
WARNING: process_pbfile() -> 	- 20240102_030000
... and so on

This issue is to revise that logic as described below:

  • PB2NC already supports the -valid_beg and -valid_end command line options to manually define the matching time window and override the obs_window config file setting.
  • PB2NC should continue to check for the center time not remaining constant.
  • If it does not change, DO NOT PRINT a warning message.
  • If it does change, but the -valid_beg and -valid_end command line options have been used to manually define the time window, DO NOT PRINT a warning message.
  • If it does change, but obs_window from the config file was used, DO PRINT a warning message instructing the user to specify the matching time window using the -valid_beg and -valid_end command line options.
  • These command line options can be set via METplus using PB2NC_VALID_BEG and PB2NC_VALID_END.

Test this change to warning messages using the 3 sample files provided by @malloryprow and @BinbinZhou-NOAA in seneca:/d1/projects/METplus/discussions/2642/from_mallory.

Time Estimate

1 day?

Sub-Issues

Consider breaking the enhancement 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
  • Select scientist(s) or no scientist required

Labels

  • Review default alert labels
  • Select component(s)
  • Select priority
  • Select requestor(s)

Milestone and Projects

  • Select Milestone as a MET-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
  • For a MET-X.Y.Z version, select the MET-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

Enhancement 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 Development issue
    Select: Milestone as the next official version
    Select: MET-X.Y.Z Development project for development toward the next official release
  • Iterate until the reviewer(s) accept and merge your changes.
  • Delete your fork or branch.
  • Close this issue.