Skip to content

Allow tc_gen to match fcst/obs when forecast genesis times are prior to observed genesis times #1714

@DanielAdriaansen

Description

@DanielAdriaansen

Describe the Enhancement

During recent improvements to tc_gen (i.e. #1448, #1447, etc...) I failed to recognize that the code changes would prevent tc_gen from creating matched pairs of forecast and observed genesis events if the forecast valid time is before the observed genesis time. For computation of subseasonal-to-seasonal (S2S) TC metrics being able to match forecasts of early genesis (i.e. forecast genesis events that occurred prior to observed genesis events) is required. I imagine this could be useful in other NWP evaluation as well, such as if your model is biased early. Currently, if your model always forecasts genesis 6 hours early, tc_gen will create no matches and thus no hits.

I propose adding a new parameter to allow a user to add a time dimension to the already existing distance dimension for creating matched pairs of genesis. The parameter could be called genesis_match_window and would have a beg and an end. In theory, setting beg = 0 and end = 0 would produce identical results to current behavior, beg = 0 and end = >0 should also produce identical behavior, but setting beg = <0 to allow early genesis forecasts to be matched with observed genesis events would change the results (these comments are my hypotheses, we should test these conditions).

The new genesis_match_window would compliment the genesis_match_radius to allow a time and distance component to creating matched pairs. Note the dev_hit_window and dev_hit_radius will still exist to affect scoring within tc_gen.

Time Estimate

1 day

Sub-Issues

Consider breaking the enhancement down into sub-issues.
No sub-issues needed.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2791541

Define the Metadata

Assignee

  • Select engineer(s) or no engineer required
  • Select scientist(s) or no scientist required

Labels

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

Projects and Milestone

  • Review projects and select relevant Repository and Organization ones or add "alert:NEED PROJECT ASSIGNMENT" label
  • Select milestone to next major version milestone or "Future Versions"

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), Project(s), Milestone, and Linked issues
  • Iterate until the reviewer(s) accept and merge your changes.
  • Delete your fork or branch.
  • Close this issue.

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions