Thermal model updates: feasibility & unit tests#374
Thermal model updates: feasibility & unit tests#374werdnum wants to merge 3 commits intodavidusb-geek:masterfrom
Conversation
1. Add option to operate on a penalty basis instead of a constraint basis. This means that we will provide a suboptimal solution rather than fail out and produce nonsense. 2. Rework overshoot constraint such that instead of saying "the temperature shall not exceed this value", we are now saying "if the temperature goes past the overshoot point, the load must be off the previous timestep". In other words, we can overshoot, but if we do, it can't be because of us.
…milar are not specified for all deferred loads (treat them as the default)
|
Hi @werdnum, I finally gathered some small spare time to look at this. It seems like a very nice contribution, this may help with unexplainable infeasible results we get some time. I should probably think about moving to this type of reasoning and implementation: penalizing instead of constraining. On downside of this is that if you ask the "imposible" to the algorithm then it will converge but the result may possible have no real physical meaning. What about this PR, it is in a Draft version? Do you think that you could package this into a meargeable PR? |
|
|
Any updates on dropping the draft status? I'd love this, since I'm using the thermal model to control my heat pump, which is connected to a solar boiler. The temperatures will, in summer time, for sure rise beyond the overshoot temperature, without running the heat pump itself. This currently will mean my model will be infeasible very often. |
|
@sourcery-ai review |
|
Hi @GeoDerp! 👋 Only authors and team members can run @sourcery-ai commands on public repos. |
|
@sourcery-ai review |
Reviewer's Guide by SourceryThis pull request introduces significant updates to the thermal model, including the option to use penalties instead of constraints, reworked overshoot temperature handling, and comprehensive unit tests. The test forecast setup was also refactored for better maintainability. No diagrams generated as the changes look simple and do not need a visual representation. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @werdnum - I've reviewed your changes - here's some feedback:
Overall Comments:
- The new tests look good, but it's a bit hard to understand what they're testing without more context.
- Consider adding a docstring to the new
run_test_forecastmethod to explain its purpose and parameters.
Here's what I looked at during the review
- 🟡 General issues: 2 issues found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| for i in set_I}) | ||
|
|
||
| elif "def_load_config" in self.optim_conf.keys(): | ||
| elif "def_load_config" in self.optim_conf.keys() and len(self.optim_conf["def_load_config"]) > k: |
There was a problem hiding this comment.
suggestion (bug_risk): Improved safety check for def_load_config indexing.
The additional check on the length of def_load_config prevents out-of-range errors. Verify that this logic aligns with your intended configuration behavior for deferrable loads.
Suggested implementation:
# Improved safety check for def_load_config indexing to prevent out-of-range errors.
elif len(self.optim_conf.get("def_load_config", [])) > k:This change ensures that if "def_load_config" is not present (or is not a list), the default empty list is used so that the length check reliably prevents indexing errors. Be sure that this behavior aligns with your intended configuration handling for deferrable loads.
| }) | ||
| opt_model.constraints = constraints | ||
|
|
||
| print(repr(opt_model)) |
There was a problem hiding this comment.
suggestion: Remove or guard debug print statements from production code.
The print(repr(opt_model)) aids debugging during development, but it might be better to remove or conditionally execute it (e.g., under a debug flag) in production.
|
It has been a long time since this PR was open, it is now stale. |
4 participants
Three significant changes:
Summary by Sourcery
Enhance thermal management in optimization model by introducing more flexible temperature constraint handling and comprehensive unit tests
New Features:
Enhancements:
Tests: