-
Notifications
You must be signed in to change notification settings - Fork 9
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
NAM precipitation #3096
NAM precipitation #3096
Conversation
Calculate cumulative precip
Fix 00 and 12 hour accumulation interval
Calculate cumulative precip
Fix 00 and 12 hour accumulation interval
…nto task/nam-precip/3082
api/pyproject.toml
Outdated
@@ -58,7 +58,7 @@ rope = "^1" | |||
jsonpickle = "^3.0.0" | |||
pytest-watch = "^4.2.0" | |||
pytest-testmon = "^2.0.0" | |||
ruff = "^0.0.286" | |||
ruff = "^0.0.287" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is weird, main is already using ruff @ 0.0.287
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely due to a merge from main instead of rebasing. Same for poetry.lock and package.json, yarn.lock and CriticalHoursCell.
# Iterate through all the predictions. | ||
prev_prediction = None | ||
|
||
# 00 and 12 hour model runs accumulate precipitation in 12 hour intervals, 06 and 18 hour accumlate in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, just wondering if we want to add some tests since due to the complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm...I'll see if I can factor all this code out into a utility function that we can test. Unless you have another thought for how we might test?
Codecov Report
@@ Coverage Diff @@
## main #3096 +/- ##
==========================================
+ Coverage 84.73% 84.74% +0.01%
==========================================
Files 300 300
Lines 10118 10133 +15
Branches 591 591
==========================================
+ Hits 8573 8587 +14
- Misses 1383 1384 +1
Partials 162 162
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more 📢 Have feedback on the report? Share it here. |
api/app/jobs/model_data.md
Outdated
|
||
### To 12:00 PST (13:00 PDT) | ||
|
||
Fire weather forecasters in the BC Wildfire Service create daily "noon forecasts", where 'noon' refers to 12:00 PST, but during the fire weather season, most of BC is on Daylight Savings Time, so 12:00 PST = 13:00 PDT = 20:00 UTC. As explained above in the [NOAA section](#noaa), there is no model data specifically for 20:00 UTC, so instead we fetch the data for 18:00 and 21:00 UTC, and then perform additional linear interpolation (on top of the interpolation done for weather station locations) to predict weather behaviour for 20:00 UTC. This means that the modelled weather values for 21:00 UTC are weighted twice as heavily as those for 18:00 UTC, since the former is twice as close to our target time of 20:00. | ||
|
||
This time-based linear interpolation is done as part of the data analysis process performed when the model data is retrieved from our third-party sources. See `process_grib.py` | ||
|
||
### Calculating predicted 24 hour precipitation | ||
|
||
For any given date, Morecast 2 displays the precipitation predicted to fall in the 24 hours previous to that date. For example, for August 30, 2023, the predicted precip covers a time period from August 29, 2023 20:00 UTC to August 30, 2023 20:00 UTC. The first 24 hours of a numerical weather model run present a challenge because there is no way to calculate the predicted 24 hour precip purely from the model run data. Consider a HRDPS model run on August 30 at 12:00 UTC. Morecast 2 needs to display the predicted precipitation for August 30 at 20:00, but at that point we only have 8 hours of accumulated precipitation (from 12:00 to 20:00) from our model run, we are potentially missing precipitation that could have fallen from Aug 29 20:00 to August 30 12:00 which means we're missing 16 hours of data. To work around this, we pull actual rainfall values for that 16 hour period from our hourly_actuals table which scrapes observed values fromthe WF1 API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this part happen? Pulling WF1 data from hourly_actuals
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a cron job that runs the .../api/app/jobs/hourly_actuals.py script to scrape values reported by weather stations via the WF1 API.
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Test Links:
Landing Page
MoreCast 2.0
Percentile Calculator
MoreCast
C-Haines
FireBat
FireBat bookmark
Auto Spatial Advisory (ASA)
HFI Calculator