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 theobs_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.