Issue135 forecast uncertainty 2 #693
Conversation
ErrorEmulator.py: function to generate an error with an AR model in the prediction horizon. SimulateError.ipynb: notebook to simulate the error for different uncertainty scenarios.
The predict_error method is imported in forecaster.py.
The arguments required by "predict_error" are propagated in get_forecast: F0, K0, F, K, mu. The hp is already defined (horizon). Default values are included for these parameters for the deterministic scenario.
predict_error is updated to predict_error_AR to specify the error model
…into issue135_forecastUncertainty # Conflicts: # forecast/forecaster.py
…nario, and prevent the weather forecast uncertainty from being overwritten in get_forecast after setting it in the scenario.
…n and introduced two new tests: test_forecast_temperature_are_within_range and test_forecast_solar_radiation_are_positive for improved criteria checking.
Issue135 forecast uncertainty
…o issue135_forecastUncertainty merge laura's revise
…_forecastUncertainty_2
|
@HWalnum Here's the PR for adding weather forecast uncertainty. If you can test out, that'd be great. Note, I'm realizing the README doesn't say, but the values that the temp and radiation uncertainty specs in the /scenario API can take are 'low', 'medium', or 'high'. We need to add this information, and also to the user guide. |
|
@dhblum I have done a local test of the forecast uncertainty module. I have not done a review of the implementation. Did you want that as well? You have probably done this already... In general, it seems to work well. I tested it on a "private" testcase where we have earlier have compared perfect forecast vs an actual weather forecast. Looking at the influence on the performance of the controller (change in mpc objective achievement), the "high" scenario (I tested only with the same scenario for both parameters) gets the most similar results to the "actual weather forecast" case. Looking at the error variance, the "low" scenario for temperature looks more similar to the actual forecast, while the high looks more similar for solar radiation. That said, that is only one case, so I have no objections to the applied distributions. Above, you mention a user manual. I could not find that. Is it in the repo? Lastly, on a separate note. I think it is worth mentioning in the main readme, that when one do changes in the local version of BOPTEST, one needs to add a "--build" flag to the docker compose up statement. |
|
Thanks so much @HWalnum for this nice testing, even using an MPC controller and comparing to previous work you've done. The user guide is actually still only on the website branch gh-pages-custom, I update it with each release. Noted on the forecast readme. And also on the --build command for rebuilding the images if wanting to update with changes, I could add a note to the main readme. Regarding the parameters for the uncertainty model, they are based on the recently published paper. @laura-zabala I'm actually going back and looking at the parameters of models, see the table below. The GHI parameters are from the paper directly, and are relatively easy to see a clear "low", "medium", "high" scenario from each city. The temperature aren't as clear, some have lower mu with higher sigma, and vice versa. So I understand its tougher to choose a low, medium, and high. But can you confirm that the current chosen parameters in the temperature model are based on the latest published parameters? I think it would be good to add a brief note in the design doc description rationale for how the parameters were selected. Temperature AR1 Parameters
|
This is for #135. A test PR instead of #482 to include changes from Wanfu.