Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Thermal model updates: feasibility & unit tests #374

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Thermal model updates: feasibility & unit tests #374

wants to merge 3 commits into from

Conversation

werdnum
Copy link
Contributor

@werdnum werdnum commented Nov 13, 2024

Three significant changes:

  1. Add an option (to become the default?) to use penalties rather than constraints for thermal conditions. This will replace a bunch of hacks I'm using to avoid trying to ask for something impossible from the solver.
  2. Rework overshoot temperature - instead of "never exceed this temperature", we want "if we do exceed this temperature, it shouldn't be our fault" - implemented as "load must be off if we overshoot"
  3. Added relatively comprehensive unit tests to cover the above behaviours plus more.

@werdnum
Updates for thermal management to address feasibility issues:
fccd9ed 
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.
@werdnum
Fixes for cases where the def_start_timestep, def_end_timestep and si…
bcc462b 
…milar are not specified for all deferred loads (treat them as the default)
@werdnum
Unit tests for thermal management
1ff13e1
@davidusb-geek
Copy link
Owner

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@werdnum @davidusb-geek