KeyError: 'P_batt'

[purcell-lab]

Running 0.1.37 and feels like we are getting close :-).

When I enable the battery for the solution space dayahead doesn't seem to finish, running for over 10 minutes before I called again:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
 * Serving Flask app 'app_server' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on all addresses (0.0.0.0)
   WARNING: This is a development server. Do not use it in a production deployment.
 * Running on http://127.0.0.1:5000
 * Running on http://172.30.33.4:5000 (Press CTRL+C to quit)
[2022-04-28 13:27:11,810] WARNING in optimization: Failed LP solve with PULP_CBC_CMD solver, falling back to default Pulp
[2022-04-28 13:27:11,866] WARNING in optimization: Failed LP solve with default Pulp solver, falling back to GLPK_CMD
192.168.86.50 - - [28/Apr/2022 13:38:18] "GET / HTTP/1.1" 200 -
192.168.86.50 - - [28/Apr/2022 13:38:18] "GET /static/style.css HTTP/1.1" 304 -
[2022-04-28 13:45:39,692] WARNING in optimization: Failed LP solve with PULP_CBC_CMD solver, falling back to default Pulp
[2022-04-28 13:45:39,742] WARNING in optimization: Failed LP solve with default Pulp solver, falling back to GLPK_CMD

Then the next time publish runs it fails:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
 * Serving Flask app 'app_server' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on all addresses (0.0.0.0)
   WARNING: This is a development server. Do not use it in a production deployment.
 * Running on http://127.0.0.1:5000
 * Running on http://172.30.33.4:5000 (Press CTRL+C to quit)
192.168.86.50 - - [28/Apr/2022 13:15:43] "GET / HTTP/1.1" 200 -
192.168.86.50 - - [28/Apr/2022 13:15:44] "GET /static/style.css HTTP/1.1" 304 -
[2022-04-28 13:16:10,105] WARNING in optimization: Failed LP solve with PULP_CBC_CMD solver, falling back to default Pulp
[2022-04-28 13:16:10,160] WARNING in optimization: Failed LP solve with default Pulp solver, falling back to GLPK_CMD
[2022-04-28 13:20:17,487] ERROR in app: Exception on /action/publish-data [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/indexes/base.py", line 3621, in get_loc
    return self._engine.get_loc(casted_key)
  File "pandas/_libs/index.pyx", line 136, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 163, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 5198, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 5206, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'P_batt'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2077, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1525, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1523, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1509, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/usr/src/app_server.py", line 191, in action_call
    _ = publish_data(input_data_dict, app.logger)
  File "/usr/local/lib/python3.9/dist-packages/emhass/command_line.py", line 182, in publish_data
    input_data_dict['rh'].post_data(opt_res_dayahead['P_batt'], idx_closest,
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/frame.py", line 3505, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/usr/local/lib/python3.9/dist-packages/pandas/core/indexes/base.py", line 3623, in get_loc
    raise KeyError(key) from err
KeyError: 'P_batt'
172.30.32.1 - - [28/Apr/2022 13:20:17] "POST /action/publish-data HTTP/1.1" 500 -

web_ui_url: 0.0.0.0
hass_url: empty
long_lived_token: empty
costfun: profit
optimization_time_step: 30
historic_days_to_retrieve: 2
sensor_power_photovoltaics: sensor.apf_generation_entity
sensor_power_load_no_var_loads: sensor.power_load_no_var_loads
number_of_deferrable_loads: 2
nominal_power_of_deferrable_loads: 5000,1500
operating_hours_of_each_deferrable_load: 5,8
peak_hours_periods_start_hours: 02:54,17:24
peak_hours_periods_end_hours: 15:24,20:24
load_peak_hours_cost: 0.1907
load_offpeak_hours_cost: 0.1419
photovoltaic_production_sell_price: 0.065
maximum_power_from_grid: 30000
pv_module_model: CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M
pv_inverter_model: Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_
surface_tilt: 30
surface_azimuth: 205
modules_per_string: 16
strings_per_inverter: 1
set_use_battery: true
battery_discharge_power_max: 5000
battery_charge_power_max: 5000
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 13500
battery_minimum_state_of_charge: 0.05
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.2

[davidusb-geek]

This may happen when the LP becomes too big for the current machine/solver. Adding a battery may cause this. When I tested the inclusion of the battery the LP solver ran well with 30min time steps though.
What you may try is to set a higher time step, ex: 60min.
The other solution is to shorten the optimization horizon, but as for now this is hard-coded to 24h. I may change this in the near future to let the user play with different horizons. The issue with this is that we may lose the one-day energy optimization approach.

[davidusb-geek]

Hi, did you managed to solve this issue? Did you use a higher time step to 60min?

[purcell-lab]

Hi, did you managed to solve this issue? Did you use a higher time step to 60min?

I had to simplify the complexity of the problem space. I am wondering if falling back to GLPK_CMD isn’t as powerful solver? I find a working solver will take between 6-8 seconds, whereas an unworking solver just continues to run without stopping with CPU load showing in the add-on window.

I reduced the deferable loads from 4 to 2 and reduced their operating windows.

I suspect the KeyError: 'P_batt' occurs if the publish-data routine is called before the dayahead optimisation is called.

In my case I have an automation/ cron job calling publish-data every five minutes, but had just enabled the battery setting, but was unable to complete the optimisation.

Perhaps some documentation around what a KeyError: P_batt means, or maybe some error checking in the publish-data routine would be the fix for this issue.

[davidusb-geek]

Hi, great thanks for the information.
Yes, if that key is not found it means that there was a problem with the optimization. I've just improved the error log to a more clear message:

logger.error("P_batt was not found in results DataFrame. Optimization task may need to be relaunched or it did not converged to a solution.")

I also added some code to check the existence of correct keys before data publish.
Yes falling back to GLPK may lead to other performance problems. The GLPK solver is great because is free and sufficient for most LP problems. The base CBC solver from Pulp should perform better. However for some reason it is not recognized by Pulp on your aarch64 architecture. We may need to debug this better, but that is another issue. Closing this by now.