Capacity requirement calculation might be incorrect for seasonally and annually-balanced commodities

[ahawkes]

Describe the bug

Possible bug - just checking

Where a commodity is seasonally or annually-balanced, is capacity required (for investment appraisal, from dispatch) calculated at the time slice level or at the season/annual level? I ask because calculating capacity needed based on the peak demand across daynight time slices would be wrong for an asset outputing a commodity that has seasonal or annual commodity balance. This is because dispatch does not care about which time slice is used (so could put lots of demand in a time slice in cases of overcapacity) if they all cost the same.

To Reproduce

I'm not sure this is actually what is happening. So this is more a request to check the code.

Expected behavior

Capacity requirement should be set to the seasonal capacity need when the primary output commodity is balanced at the seasonal level. Likewise annual.

Capacity needed = sum(demand over relevant time slices)/sum(time slice durations over relevant time slices)

[tsmbland]

Where a commodity is seasonally or annually-balanced, is capacity required (for investment appraisal, from dispatch) calculated at the time slice level or at the season/annual level? I ask because calculating capacity needed based on the peak demand across daynight time slices would be wrong for an asset outputing a commodity that has seasonal or annual commodity balance. This is because dispatch does not care about which time slice is used (so could put lots of demand in a time slice in cases of overcapacity) if they all cost the same.

When it comes to investments, we allow the possibility that all demand for the season gets served by a single timeslice. We calculate the maximum capacity as the max over t of (total demand for the season / max supply per capacity in timeslice t), where the denominator depends on timeslice lengths and availability limits.

This is just a maximum capacity though, it will only invest this much if there's a cost-saving benefit of allocating all supply to one timeslice (according to the objective), versus spreading supply evenly across the season which would require less capacity. I think this is important as, if input commodities vary in price within the season, it may be a genuine cost saving strategy to invest in more capacity to make maximum use of timeslices when input commodities are cheap, even if this means having unused capacity at other times.

I think there are problems elsewhere that might be resulting in over-investment, and I think in this case by the time you get to dispatch you may end up having lots of demand/supply in one timeslice even if prices are the same, but I don't think the calculations here to do with candidate capacities are a root cause of the problem.

[ahawkes]

OK, thanks for the clarification.

…

________________________________ From: Tom Bland ***@***.***> Sent: 13 March 2026 15:39 To: EnergySystemsModellingLab/MUSE2 ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Author ***@***.***> Subject: Re: [EnergySystemsModellingLab/MUSE2] Capacity requirement calculation might be incorrect for seasonally and annually-balanced commodities (Issue #1203) 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#1203)<#1203 (comment)> Where a commodity is seasonally or annually-balanced, is capacity required (for investment appraisal, from dispatch) calculated at the time slice level or at the season/annual level? I ask because calculating capacity needed based on the peak demand across daynight time slices would be wrong for an asset outputing a commodity that has seasonal or annual commodity balance. This is because dispatch does not care about which time slice is used (so could put lots of demand in a time slice in cases of overcapacity) if they all cost the same. When it comes to investments, we allow the possibility that all demand for the season gets served by a single timeslice. We calculate the maximum capacity as the max over t of (total demand for the season / max supply per capacity in timeslice t), where the denominator depends on timeslice lengths and availability limits. This is just a maximum capacity though, it will only invest this much if there's a cost-saving benefit of allocating all supply to one timeslice (according to the objective), versus spreading supply evenly across the season which would require less capacity. I think this is important as, if input commodities vary in price within the season, it may be a genuine cost saving strategy to invest in more capacity to make maximum use of timeslices when input commodities are cheap, even if this means having unused capacity at other times. I think there are problems elsewhere that might be resulting in over-investment, and I think in this case by the time you get to dispatch you may end up having lots of demand/supply in one timeslice even if prices are the same, but I don't think the calculations here to do with candidate capacities are a root cause of the problem. — Reply to this email directly, view it on GitHub<#1203 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLPPFH4YK7372H6KKLL4QQTUPAVCNFSM6AAAAACWRCFIBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJWGA3TQOJVGM>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ahawkes]

@tsmbland But the current approach for LCOX pushes capacity to its extreme (due to great benefit of avoiding VoLL), so might end up with this maximum capacity anyway. And with the suggested revision to LCOX tool in #1199 , we would need to choose a capacity. And NPV tools never chose a capacity from the optimisation.

So, maybe better to bound capacity at the amount required by the demand profile? (i.e. season demand divided by season duration, for the seasonally-balanced case)?