Allow for possibility to end with full NWP weight at end of blending

[RubenImhoff]

This PR fixes #481.

I have added a first, draft, approach to move to full NWP weights at the end of timesteps, if requested by the user. The method adds an additional input parameter for the steps.blending.forecast function:
timestep_start_full_nwp_weight: int, optional:
The timestep, which should be smaller than timesteps, at which a linear
transition takes place from the calculated weights to full NWP weight
(and zero extrapolation and noise weight) to ensure the blending
procedure becomes equal to the NWP forecast(s) at the last timestep
of the blending procedure. If not provided, the blending stick to the
theoretical weights provided by the chosen weights_method for a given
lead time and skill of each blending component.

If a value is set for timestep_start_full_nwp_weight, the blending weights will linearly move from the weights at timestep timestep_start_full_nwp_weight to full weight (1.0) for the NWP component and zero (0.0) weight for the extrapolation and noise cascade components at the final timestep of the blending procedure.

I have given it a first test with the gallery example data from Australia. We only have three hours of NWP sample data here, so timestep_start_full_nwp_weight is set at 12 (2 hour lead time) and timesteps is set at 18 (3 hours in total).

Testing this with the BPS weights, give the following weights with (a) indicating the current setup and (b) indicating the setup where timestep_start_full_nwp_weight is applied:

The forecast will then change from:
[original]

to:
[adjusted]

[RubenImhoff]

For the SPN weights, the same setup results in:

[Original test]

[Adjusted setup]

[RubenImhoff]

Tests fail on the T-dating functionality, for some reason, but locally all tests do succeed. I am not sure why..

[RubenImhoff]

Something still goes wrong with the tests in the T-dating functionality: "FAILED ../tests/test_tracking_tdating.py::test_tracking_tdating_dating_multistep[mch-6-True] - ValueError: Must have equal len keys and value when setting with an iterable". @dnerini, do you have any idea what causes this?

[dnerini]

Something still goes wrong with the tests in the T-dating functionality: "FAILED ../tests/test_tracking_tdating.py::test_tracking_tdating_dating_multistep[mch-6-True] - ValueError: Must have equal len keys and value when setting with an iterable". @dnerini, do you have any idea what causes this?

this seems to be an issue appearing with a recent version of pandas. I'm pushing a fix in #539, can you please have a look?

[codecov]

Codecov Report

❌ Patch coverage is 96.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.89%. Comparing base (e32001c) to head (9e4ca1b).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
pysteps/blending/steps.py	96.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #536      +/-   ##
==========================================
+ Coverage   83.85%   83.89%   +0.03%     
==========================================
  Files         168      168              
  Lines       14634    14678      +44     
==========================================
+ Hits        12272    12314      +42     
- Misses       2362     2364       +2     

Flag	Coverage Δ
unit_tests	83.89% <96.00%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[RubenImhoff]

Everything seems to work now, thanks @dnerini!