Closed purcell-lab closed 2 years ago
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.
Hi, did you managed to solve this issue? Did you use a higher time step to 60min?
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.
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.
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:
Then the next time publish runs it fails: