BOPTEST crashes when forecast outside simulation year is requested

[haraldwalnum]

When performing simulations up to 1 year, the model crashes when the requested forecast exceeds the one year data in the resource files. I guess this is due to pandas failing when asked for data outside the index. I see some possible solutions to this:

1. Continue by reading data from the top of the dataframe when the bottom is reached. However, this might results in big discontinuities for some of the weather data.
2. Keep the last value constant. This should be a stable solution, but not realistic. At least for longer simulation periods, the impact should be small
3. Repeating data for the last day of the year. There could still be some discontinuities but less than for solution 1.

[EttoreZ]

@haraldwalnum I also found the same issue. In theory the IBPSA library does what suggested in step 1., if typical weather data is used the discontinuity shouldn't be too big, but it could still meddle with the controller. I guess an idea could be use point 1. I also report the error log that I obtain:

_File "/home/developer/.local/lib/python2.7/site-packages/flask/app.py", line 1950, in full_dispatch_request rv = self.dispatch_request() File "/home/developer/.local/lib/python2.7/site-packages/flask/app.py", line 1936, in dispatch_request return self.view_functionsrule.endpoint File "/home/developer/.local/lib/python2.7/site-packages/flask_restful/init.py", line 468, in wrapper resp = resource(*args, kwargs) File "/home/developer/.local/lib/python2.7/site-packages/flask/views.py", line 89, in view return self.dispatch_request(*args, *kwargs) File "/home/developer/.local/lib/python2.7/site-packages/flask_restful/init.py", line 583, in dispatch_request resp = meth(args, kwargs) File "restapi.py", line 142, in get forecast = case.get_forecast() File "/home/developer/testcase.py", line 427, in get_forecast interval=self.interval) File "/home/developer/forecast/forecaster.py", line 75, in get_forecast plot=plot) File "/home/developer/data/data_manager.py", line 317, in get_data data_slice_reindexed.loc[:,key] = f(index) File "/usr/lib/python2.7/dist-packages/scipy/interpolate/polyint.py", line 79, in call y = self._evaluate(x) File "/usr/lib/python2.7/dist-packages/scipy/interpolate/interpolate.py", line 610, in _evaluate below_bounds, above_bounds = self._check_bounds(x_new) File "/usr/lib/python2.7/dist-packages/scipy/interpolate/interpolate.py", line 642, in _check_bounds raise ValueError("A value in x_new is above the interpolation " ValueError: A value in xnew is above the interpolation range.

[MaPaKo]

@dhblum Question for the developers: Would you consider implementing a solution? Since a simulation can be run beyond the end of a year, it would only make sense if the forecast could do the same.

I work with MPC using weather forecasts. I want to simulate one heating season (e.g. September to March). This is currently not possible with Boptest as it comes for the aforementioned reason.

[dhblum]

@EttoreZ To clarify, were you saying in your comment before that if a simulation using the IBPSA Weather Boundary Condition Reader goes beyond one year (e.g. beyond 31536000 seconds), then the weather data just starts from the top again?

[EttoreZ]

@dhblum Yes if the weather data file is at least one year long. I report below an extract from the weather reader model IBPSA.BoundaryConditions.WeatherData.ReaderTMY3

"Length of weather data and simulation period If weather data span a year, which is the default for TMY3 data, or multiple years, then this model can be used for simulations that span multiple years. The simulation start time needs to be set to the clock time of the respective start time. For example, to start at January 2 at 10am, set start time to t=(24+10)*3600 seconds. For this computation, the used date and time (here January 2, 10 am) must be expressed in the same time zone as the one that is used to define the TMY3 file. This is usually the local (winter) time zone. The parameter timZon represents the TMY3 file time zone, expressed in seconds compared to UTC. Moreover, weather data need not span a whole year, or it can span across New Year. In this case, the simulation cannot exceed the time of the weather data file. Otherwise, the simulation stops with an error. As weather data have one entry at the start of the time interval, the end time of the weather data file is computed as the last time entry plus the average time increment of the file. For example, an hourly weather data file has 8760 entries, starting on January 1 at 0:00. The last entry in the file will be for December 31 at 23:00. As the time increment is 1 hour, the model assumes the weather file to end at December 31 at 23:00 plus 1 hour, e.g., at January 1 at 0:00. "

[dhblum]

Great, thanks @EttoreZ. Then I recommend we we do the same with forecasts. I suggest we implement a solution in Data_Manager.get_data() that allows for periodic extrapolation of data, which matches the behavior of the IBPSA Weather Reader. Note that is the function called by the Forecaster. Maybe there should be flag in .get_data() to enable this which can be set true or false (and set to true in the Forecaster). This will need unit test(s) as well to validate expected behavior.

[EttoreZ]

I started to implement a solution for this issue and it seems to work. However, there are two points that should be brought to attention:

1. I opened an issue on the IBPSA modelica respository, due to a bug #1716, related to the calculation of the diffuse radiation when simulating beyond one year. This leads the KPI calculation to be inconsistent when simulating the same day at year 0 or at year n.
2. At the boundary between current and new year of simulation the boundary conditions are discontinuos, as an example see TDryBul ( blue line) in the figure below. In Modelica tools this generates an event where at time 0 coming from "the left" the value will be equivalent to the one at the end of the .csv file, while coming from "the right" the value will be the one at the beginning of the .csv file. BOPTEST cannot handle time events and uses a constant time step to report forecasts, therefore an approximation has to be made for the value at t=0. A possible suggestion is shown in the figure below (dashed red and black lines), where the value at the zero point becomes the average between the value at time 0 in the .csv and the value at end of the year.

Added edit after @dhblum comments to avoid ambiguities.

[dhblum]

Thank you @EttoreZ for bringing these things to attention. One thing I'd just like to clarify is that BOPTEST simulation can handle time events. The issue I see is in how we report forecasts to users across this boundary, which are reported for a fixed timestep and should only have one value I think for t=0.

[dhblum]

Closed by https://github.com/ibpsa/project1-boptest/pull/599.