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.

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

Set option to force minimum fraction of load served by ASHP if purchased #455

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

zolanaj
Copy link
Collaborator

@zolanaj zolanaj commented Nov 20, 2024

Added

  • Added new attribute `` to ASHPSpaceHeater and ASHPWaterHeater technologies. When this is populated, this imposes a constraint on the minimum fraction of load served by the ASHP system in every period, if the system is purchased.

@zolanaj zolanaj requested a review from Bill-Becker November 20, 2024 22:37
@zolanaj
Copy link
Collaborator Author

zolanaj commented Nov 20, 2024

@Bill-Becker just a note: this may be a replacement for min_peak_load_capacity_fraction that allows the dispatch to be more realistic for the system (it would force a minimum allowable system size, and does so in the current implementation). Setting this to 1 is equivalent to force_into_system = true if we also force purchase (otherwise, it's an "all or nothing" decision).

Failing tests are currently coming from a PVWatts timeout.

@Bill-Becker
Copy link
Collaborator

@zolanaj so if we have a scenario that has a peak load of say 100 ton, and we say min service fraction is 50%, then REopt will size ASHP to 50 ton (at least). But if the "typical load" is more like 50 ton, this still allows the ASHP to only serve 50% of the 50 ton, or 25 tons for that typical load?

@zolanaj
Copy link
Collaborator Author

zolanaj commented Nov 20, 2024

@zolanaj so if we have a scenario that has a peak load of say 100 ton, and we say min service fraction is 50%, then REopt will size ASHP to 50 ton (at least). But if the "typical load" is more like 50 ton, this still allows the ASHP to only serve 50% of the 50 ton, or 25 tons for that typical load?

@Bill-Becker Slightly rephrasing this: 5f the peak load is 100 ton and every other hour the load is 50 ton, then if purchased, the system would produce a minimum of 50 tons in the peak period and 25 tons in every other period.

I'm considering this "option A" and working on a separate option that will serve as much of the load as possible if the system is purchased ("option B" but not in order of preference - just the order of what I'm attempting.) I think that option B is more in line with the ask but this was the easier implementation when I drew it up.

@Bill-Becker
Copy link
Collaborator

@zolanaj so if we have a scenario that has a peak load of say 100 ton, and we say min service fraction is 50%, then REopt will size ASHP to 50 ton (at least). But if the "typical load" is more like 50 ton, this still allows the ASHP to only serve 50% of the 50 ton, or 25 tons for that typical load?

@Bill-Becker Slightly rephrasing this: 5f the peak load is 100 ton and every other hour the load is 50 ton, then if purchased, the system would produce a minimum of 50 tons in the peak period and 25 tons in every other period.

I'm considering this "option A" and working on a separate option that will serve as much of the load as possible if the system is purchased ("option B" but not in order of preference - just the order of what I'm attempting.) I think that option B is more in line with the ask but this was the easier implementation when I drew it up.

Ok, yeah that's what I thought - this would work pretty well when the peak-to-typical/avg load ratio is relatively low (<1.5), but I'm concerned this will still lead to a lot of the same kind of "herky jerky" dispatch for higher ratios that we're seeing now because REopt will just do the minimum of what's required if it's not economic with the temp-dependent COP and TOU/demand pricing.

@Bill-Becker
Copy link
Collaborator

@zolanaj do we think the new functionality that you developed would replace this, or would this be another option? I personally think we just need what you recently developed with forced dispatch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants