Equalise equivalent assets in dispatch - #1477
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1477 +/- ##
==========================================
+ Coverage 89.91% 90.04% +0.12%
==========================================
Files 60 60
Lines 8556 8597 +41
Branches 8556 8597 +41
==========================================
+ Hits 7693 7741 +48
+ Misses 543 537 -6
+ Partials 320 319 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
0bd50cf to
0dc2c19
Compare
There was a problem hiding this comment.
Pull request overview
This PR extends the dispatch optimisation model to prevent arbitrary selection among equivalent assets by constraining assets with the same (region, process) to have equal utilisation in each time slice, and documents the new constraint in the dispatch optimisation docs.
Changes:
- Add “equal utilisation” constraints across fixed-capacity assets sharing the same process and region for every time slice.
- Exclude flexible-capacity assets from these constraints (since their maximum activity depends on a decision variable).
- Document the equal-utilisation concept and equations in the dispatch optimisation documentation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/simulation/optimisation/constraints.rs | Adds equal-utilisation constraint rows tying activity variables across equivalent assets per time slice. |
| docs/model/dispatch_optimisation.md | Documents the equal-process-utilisation constraint and utilisation definition used by dispatch. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@ahawkes This seems to work well (see description above for details), but we need to decide what to do about process parameters/availabilities potentially varying by commission year. What do you think we should do? |
|
I think we should not allow process parameters to vary by commission year. If user want such variation they can create a new process for it. Suggest we make this change. Two notes worth thinking about for the future:
|
This is fine, but just so you're aware this is not a small change in terms of the code (unless we're happy to leave a load of dead code littering the codebase, which I wouldn't advise unless we might want to restore this later). Would ultimately simplify things though. Would you also want to remove the ability for process parameters to vary by region? (Not needed for this issue, but if we did want to change this as well it would be worth doing at the same time)
As it stands, availabilities can vary by year, but these always apply to the commission year of the asset. What you're saying is that we should still allow availabilities to vary by year, but assets should always use parameters for the current year, regardless of commission year? Right?
Correct. |
|
Right. Maybe we hold off on this then? How much does it undermine the solution?
Users can still make new processes with one parameter changed…
…________________________________
From: Tom Bland ***@***.***>
Sent: Tuesday, 11 August 2026 18:12:53
To: EnergySystemsModellingLab/MUSE2 ***@***.***>
Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***>
Subject: Re: [EnergySystemsModellingLab/MUSE2] Equalise equivalent assets in dispatch (PR #1477)
CAUTION: This message came from outside Imperial. Do not click links or open attachments unless you recognise the sender and were expecting this email.
[https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1477)<#1477 (comment)>
I think we should not allow process parameters to vary by commission year. If user want such variation they can create a new process for it. Suggest we make this change.
This is fine, but just so you're aware this is not a small change in terms of the code (unless we're happy to leave a load of dead code littering the codebase, which I wouldn't advise unless we might want to restore this later).
Would you also want to remove the ability for process parameters to vary by region? (Not needed for this issue, but if we did want to change this as well it would be worth doing at the same time)
Two notes worth thinking about for the future:
1. availabilities could change over asset lifetimes - particularly true for wind/solar where climate change might impact availability in future.
As it stands, availabilities can vary by year, but these always apply to the commission year of the asset. What you're saying is that we should still allow availabilities to vary by year, but assets should always use parameters for the current year, regardless of commission year? Right?
1. if a user creates an almost-identical new process, and e.g. only changes a parameter that doesn't influence dispatch, then from dispatch perspective the two processes are identical and we might end up with the same/similar problem?
Correct
—
Reply to this email directly, view it on GitHub<#1477?email_source=notifications&email_token=AC37JLIW3DZOI2WAWE45GHL5JMZXLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVGUYDINJUGU22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5255045455>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLKI4A3WFWX6HWAOAM35JMZXLAVCNFSNUABFKJSXA33TNF2G64TZHM3TSMBYGA4TIOJTHNEXG43VMU5TKMBZGE3DOOJYGM32C5QC>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
If we kept the current ability to let process parameters vary by year, then we could group any assets from the same process/region that have equal activity coefficients. If, in addition, we change availability limits so that they represent the current year rather than the commission year of the asset, then there's no issue about conflicts there. |
|
OK. The first bit sounds good, I think. The availability point is more complicated. For some processes this can vary per MSY (wind, solar). But for others like a nuclear power station it is fixed by the commission year. In general models like this fix all process parameters to commission year values. Can we not just group assets that have the same process/region and activity coefficient AND time-sliced availability? Or is that too many checks to perform?
…________________________________
From: Tom Bland ***@***.***>
Sent: 12 August 2026 14:37
To: EnergySystemsModellingLab/MUSE2 ***@***.***>
Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***>
Subject: Re: [EnergySystemsModellingLab/MUSE2] Equalise equivalent assets in dispatch (PR #1477)
CAUTION: This message came from outside Imperial. Do not click links or open attachments unless you recognise the sender and were expecting this email.
[https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1477)<#1477 (comment)>
Right. Maybe we hold off on this then? How much does it undermine the solution? Users can still make new processes with one parameter changed…
If we kept the current ability to let process parameters vary by year, then we could group any assets from the same process/region that have equal activity coefficients. If, in addition, we change availability limits so that they represent the current year rather than the commission year of the asset, then there's no issue about conflicts there.
—
Reply to this email directly, view it on GitHub<#1477?email_source=notifications&email_token=AC37JLLPPJQ654RECLXLYWL5JRXIVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRWG42TKOBUG432M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5267558477>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLN6F5U53TEHJ3AVLZT5JRXIVAVCNFSNUABFKJSXA33TNF2G64TZHM3TSMBYGA4TIOJTHNEXG43VMU5TKMBZGE3DOOJYGM32C5QC>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Could do. Or could redefine what we're equalising so it takes availability limits into account. So, for example, if you had two assets, one with an upper availability limit of 1.0 and the other with 0.5, rather than equalising their utilisation (e.g. 50 activity for both), you'd equalise their utilisation relative to their availability limits (i.e. 66.6 and 33.3). Might work - would have to try. |
|
I guess availability could be defined at time slice level, seasonal level and/or annual level. Could get complicated right?
I’m not that keen on the extensive change to code you mentioned, but I think ultimately the likely best route is that process parameters are fixed for each process. That should include availabilities. That way we know for sure when processes are identical, and results clearer for users as they know the underlying parameters for each process without needing to refer to the commission year.
The extra layer we probably want is to group assets that have the same activity coefficient as well. So if a user changes a parameter that doesn’t influence dispatch, the assets still get grouped and utilisation distributed. But would only be reliable where availabilities are identical, I think.
…________________________________
From: Tom Bland ***@***.***>
Sent: Thursday, 13 August 2026 11:52:28
To: EnergySystemsModellingLab/MUSE2 ***@***.***>
Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***>
Subject: Re: [EnergySystemsModellingLab/MUSE2] Equalise equivalent assets in dispatch (PR #1477)
CAUTION: This message came from outside Imperial. Do not click links or open attachments unless you recognise the sender and were expecting this email.
[https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1477)<#1477 (comment)>
OK. The first bit sounds good, I think. The availability point is more complicated. For some processes this can vary per MSY (wind, solar). But for others like a nuclear power station it is fixed by the commission year. In general models like this fix all process parameters to commission year values. Can we not just group assets that have the same process/region and activity coefficient AND time-sliced availability? Or is that too many checks to perform?
Could do. Or could redefine what we're equalising so it takes availability limits into account. So, for example, if you had two assets, one with an upper availability limit of 1.0 and the other with 0.5, rather than equalising their utilisation (e.g. 50 activity for both), you'd equalise their utilisation relative to their activity limits (i.e. 66.6 and 33.3). Might work - would have to try.
—
Reply to this email directly, view it on GitHub<#1477?email_source=notifications&email_token=AC37JLLQJNK3SI32JBSIEXT5JV6UZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRXHAYTKMJTHA3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5278151386>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLOWJHHUKDKSWIRX6CT5JV6UZAVCNFSNUABFKJSXA33TNF2G64TZHM3TSMBYGA4TIOJTHNEXG43VMU5TKMBZGE3DOOJYGM32C5QC>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This is true... yeah may be too complicated
It's not impossible and would ultimately make the code simpler. I still think we should be absolutely sure this is what we want before proceeding.
Yes, only reliable when availabilities and identical, and difficult to define "identical" when availabilities can be defined at different levels (unless you're really strict about it). You'd also have to check input/output commodities and flow coefficients to be sure that you're grouping equivalent processes. Quite fiddly. |
|
I think for now the easiest approach is just to check availability limits, flows (coefficients and costs) and variable operating costs, and group assets for which all of these are identical |
|
I think we should go ahead with this - parameters cannot change over different commission years. So, for example, if there’s just one process of a particular type that’s the same over the whole time horizon they always get aggregated together in dispatch.
And leave an open issue describing the idea to aggregate further “identical” assets, based on having identical properties in dispatch (with all those fiddly checks).
…________________________________
From: Tom Bland ***@***.***>
Sent: Thursday, 13 August 2026 14:31:37
To: EnergySystemsModellingLab/MUSE2 ***@***.***>
Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***>
Subject: Re: [EnergySystemsModellingLab/MUSE2] Equalise equivalent assets in dispatch (PR #1477)
CAUTION: This message came from outside Imperial. Do not click links or open attachments unless you recognise the sender and were expecting this email.
[https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1477)<#1477 (comment)>
I guess availability could be defined at time slice level, seasonal level and/or annual level. Could get complicated right?
This is true... yeah may be too complicated
I’m not that keen on the extensive change to code you mentioned, but I think ultimately the likely best route is that process parameters are fixed for each process. That should include availabilities. That way we know for sure when processes are identical, and results clearer for users as they know the underlying parameters for each process without needing to refer to the commission year.
It's not impossible and would ultimately make the code simpler. I still think we should be absolutely sure this is what we want before proceeding.
The extra layer we probably want is to group assets that have the same activity coefficient as well. So if a user changes a parameter that doesn’t influence dispatch, the assets still get grouped and utilisation distributed. But would only be reliable where availabilities are identical, I think.
Yes, only reliable when availabilities and identical, and difficult to define "identical" when availabilities can be defined at different levels (unless you're really strict about it). You'd also have to check input/output commodities and flow coefficients to be sure that you're grouping equivalent processes. Quite fiddly.
—
Reply to this email directly, view it on GitHub<#1477?email_source=notifications&email_token=AC37JLOUO2CBONPZGJXUOTL5JWRJTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRXHE4DGNBSG4ZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5279834272>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLOF23UHOUIOUPD5KCD5JWRJTAVCNFSNUABFKJSXA33TNF2G64TZHM3TSMBYGA4TIOJTHNEXG43VMU5TKMBZGE3DOOJYGM32C5QC>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This reverts commit 06d87e3.
Description
Following on from #1478, this PR constrains equivalent assets to have equal utilisation in every timeslice, to prevent it from arbitrarily utilising one asset over another. Equivalent assets are defined as assets of the same process in the same region.
There's a slight issue here that, since we allow process parameters and availability constraints to vary by commission year, assets of the same process/region, but with different commission years, may in fact not be equivalent. If costs are different, these constraints may result in a higher overall system cost. If availability constraints are different, these constraints may render the problem infeasible (although that's probably quite unlikely). We've thought about removing the ability of process costs/availabilities to vary by year, or otherwise being more strict in the way we do the grouping. We need to come up with a decision here before we can proceed with this. EDIT: the plan (see below) is to disallow process parameters/flows/limits from varying by year. Nothing needs to change in this PR, it will just have a slight pitfall until this change is made. We still might want to equalise different processes that are effectively the same for the purposes of dispatch, which we might be able to do by individually checking the relevant parameters (see 06d87e3 for a rough idea). That's way in the future though.
Fixes #1174. Hard to be absolutely sure, but the problem is now much more constrained so it's less likely that there's a space of equally good solutions for the solver to choose between. One positive sign is that the results are no longer impacted by updating highs (#1471), which was not the case before.
Fixes #1399. I've confirmed this using the example models in the issue.
You can see in
debug_solver.csvthat this has no impact on the objective value (look at the rows for 2020), until the point where the simulations diverge, in which case it's not comparable.Screenshot from documentation
Performance discussion
The number of constraints added to the optimisation depends on the structure/state of the model (i.e. how many equivalent assets exist). For each group of n equivalent assets, this adds (n - 1) * n_timeslices constraints. This will be at worst (n_assets - 1) * n_timeslices if all assets are equivalent. No extra variables are added. For the example models the performance hit is on the order of 0-5%. Similarly, for
simple_modifiedthe performance impact is negligible.Type of change
Key checklist
$ cargo test$ cargo docpresent in the previous release
Further checks