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

Improve robustness of wind field estimation #174

Merged
merged 16 commits into from
Jan 30, 2024

Conversation

thomas-fred
Copy link
Contributor

@thomas-fred thomas-fred commented Jan 30, 2024

  • Deduplicate synthetic storm tracks using track_id and timestep
  • Deduplicate storm tracks prior to labelling with DatetimeIndex
  • Check storm tracks have consecutive and monotonically increasing timestep
  • Increase country-storm search buffer from 2 to 3 degrees
  • Filter storm tracks so we keep track sections from 'first arrival to last departure' rather than simply those intersecting a buffer
  • Limit interpolation to 6 hours between track timesteps. Otherwise return zero wind speeds for timestep.
  • Check wind field estimation parameters are physical
  • Refactor wind estimation so advective and rotational components are calculated more closely in code (eases re-use of evaluation grid)
  • Taper advective winds as function of absolute distance from storm eye -- advective field decays to nothing at radius 1,000km.
  • Improve wind field plotting
  • Update tests

The estimated wind field for each time step is a vector sum of two
components, the advective field due to the translational motion of the
storm and the rotational field. The rotational field intensity is a
function of radius from storm eye. Previously, the advective field
had no spatial dependence. This meant the entire spatial domain had some
sort of background wind field (typically(!) a few m/s). In the event of
a fast moving storm (say a decayed cyclone transitting the NA, this
speed may be quite significant. For large domains like the USA, this
could mean not insignificant background wind speeds many thousands of
miles from the storm. I have decided that preventing this is worth the
necessary assumptions and extra complexity.

We now take the advective wind vector and multiply it by some reduction
factor. This factor is the distance to storm eye, normalised by the
radius to maximum winds, then tapered to 0 using a hyperbolic tangent
function.
Previously, we used distance normalised by radius to maximum winds.
Now, fade to 0 at 1,000km radius. Prevents a storm erroneously
influencing the other side of a continent.
@thomas-fred thomas-fred merged commit 62cbfe5 into main Jan 30, 2024
1 check passed
@tomalrussell tomalrussell deleted the feature/taper_advective_winds branch January 31, 2024 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant