Add a price option that accounts for capital costs

[tsmbland]

We currently only allow prices to be set using the "shadow prices" strategy, which is based on the process with the highest marginal cost. We also have a "scarcity adjusted" strategy, hidden behind the "please_allow_broken_results" option, which we haven't used much although I believe there are some problems with this.

We're missing an option that takes into account capital costs (/fixed costs). I'm not really sure the best way to do this.

We could take an approach similar to MUSE1 where the capital/fixed costs of all the active processes are weighted based on their contribution to total supply, then summed. Then maybe add this to the shadow price? Not sure that's a good approach. Perhaps we're actually more interested in the single producer with the overall highest costs?

@ahawkes do you have a plan for this?

[ahawkes]

I have some thoughts, though not definitive: * Add a "full-cost-pricing" option. Maybe could be calculated something like: * Calculate AFC price component, which should be AFC (fixed opex plus annualised capex) divided by the commodity output for the year (from previous MSY dispatch, for that asset). Handle cases where asset output is zero or epsilon small. * Add this on to the marginal price of production for that process for each time slice, calculated using previous MSY prices of inputs/outputs, variable opex, other process parameters, etc. Only if asset is active in the time slice. I think perhaps this price calc should be as per LCOX where we exclude the commodity of interest? * Of all the assets that can serve a commodity demand, the one that is most expensive sets the price (could be different assets in different time slices) What do you think? In general this type of pricing makes more sense when a commodity can be stored, so for seasonal and annual balance commodities. Though we could let the user decide.

…

________________________________ From: Tom Bland ***@***.***> Sent: 21 November 2025 14:27 To: EnergySystemsModellingLab/MUSE2 ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***> Subject: [EnergySystemsModellingLab/MUSE2] Add a price option that accounts for capital costs (Issue #1009) [https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland created an issue (EnergySystemsModellingLab/MUSE2#1009)<#1009> We currently only allow prices to be set using the "shadow prices" strategy, which is based on the process with the highest marginal cost. We also have a "scarcity adjusted" strategy, hidden behind the "please_allow_broken_results" option, which we haven't used much although I believe there are some problems with this. We're missing an option that takes into account capital costs (/fixed costs). I'm not really sure the best way to do this. We could take an approach similar to MUSE1 where the capital/fixed costs of all the active processes are weighted based on their contribution to total supply, then summed. Then maybe add this to the shadow price? Not sure that's a good approach. Perhaps we're actually more interested in the single producer with the overall highest costs? @ahawkes<https://github.com/ahawkes> do you have a plan for this? — Reply to this email directly, view it on GitHub<#1009>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLJTYUU7UUMKWH6N5OD354OLXAVCNFSM6AAAAACM2B4K2SVHI2DSMVQWIX3LMV43ASLTON2WKOZTGY2TCOBZGMZDSOA>. You are receiving this because you were mentioned.

[tsmbland]

Seems worth a try. Two more questions:

• How would we do this in the first year, where we don't have previous MSY prices to look at?
• Do you anticipate using a different price strategy for different commodities? E.g. via a column in the commodities.csv input file. Currently we just have a single option for all commodities in the model.toml file.

[ahawkes]

1. For first year, we run dispatch to get prices, and then run investment for the following MSY? So this would be the same - get shadow prices, do our full-cost prices calcs, and then run investment for the following MSY using those. 2. Ultimately I think price formation should be per-commodity. Is it much more difficult to do this?

…

________________________________ From: Tom Bland ***@***.***> Sent: 24 November 2025 09:15 To: EnergySystemsModellingLab/MUSE2 ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***> Subject: Re: [EnergySystemsModellingLab/MUSE2] Add a price option that accounts for capital costs (Issue #1009) [https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1009)<#1009 (comment)> Seems worth a try. Two more questions: * How would we do this in the first year, where we don't have previous MSY prices to look at? * Do you anticipate using a different price strategy for different commodities? E.g. via a column in the commodities.csv input file. Currently we just have a single option for all commodities in the model.toml file. — Reply to this email directly, view it on GitHub<#1009 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLOHTK7ONEOA4HG5CQL36LEDVAVCNFSM6AAAAACM2B4K2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRZGY4DINZSGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tsmbland]

For first year, we run dispatch to get prices, and then run investment for the following MSY? So this would be the same - get shadow prices, do our full-cost prices calcs, and then run investment for the following MSY using those.

Ok, I think I misunderstood. When you say "Add this on to the marginal price of production for that process for each time slice, calculated using previous MSY prices of inputs/outputs", do you mean "calculated using the current MSY shadow prices"?

So essentially each year, we calculate the shadow prices, calculate marginal costs for each asset using these (these will already factor in variable opex, flow costs, levies), then add the AFC component, then take the max over all assets. That's the price for this year, then we use these values for investments the following year.

Is that right?

[ahawkes]

Yes I meant MSY shadow prices. But need to keep the conceptual separation between commodity price and levies etc. So we calculate the cost of producing the CoI by considering the shadow prices of the commodities consumed/produced (except the CoI), and variable opex, levies, flow costs, etc. i.e. we do not assume shadow prices already factor in variable opex, etc.

…

________________________________ From: Tom Bland ***@***.***> Sent: 24 November 2025 11:49 To: EnergySystemsModellingLab/MUSE2 ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***> Subject: Re: [EnergySystemsModellingLab/MUSE2] Add a price option that accounts for capital costs (Issue #1009) [https://avatars.githubusercontent.com/u/23723407?s=20&v=4]tsmbland left a comment (EnergySystemsModellingLab/MUSE2#1009)<#1009 (comment)> 1. For first year, we run dispatch to get prices, and then run investment for the following MSY? So this would be the same - get shadow prices, do our full-cost prices calcs, and then run investment for the following MSY using those. Ok, I think I misunderstood. When you say "Add this on to the marginal price of production for that process for each time slice, calculated using previous MSY prices of inputs/outputs", do you mean "calculated using the previous MSY shadow prices"? So essentially each year, we calculate the shadow prices, calculate marginal costs for each asset using these (these will already factor in variable opex, flow costs, levies), then add the AFC component, then take the max over all assets, then use these values for investments the following year. Is that right? — Reply to this email directly, view it on GitHub<#1009 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLOELNNU35SKPIRVHAD36LWGLAVCNFSM6AAAAACM2B4K2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZQGQYTENRWGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tsmbland]

@ahawkes I've given this a go like you've suggested (#1021) and I think it mostly works, but I have some questions:

• In some cases there might be no assets producing a particular commodity in a particular timeslice. We've got around this before for the shadow pricing method by adding candidate assets with a tiny capacity, which seems to work. For the new "full cost" method, should we still consider these hypothetical candidate assets, or limit the calculation to real assets with larger capacity (I guess it's possible to get a number out even though capacity is 0.00001, but not sure whether it makes sense). If not, should we revert to the shadow price for these missing prices?

• How do we deal with processes with multiple outputs? The way I've currently done it you end up incorporating the full AFC into the price of all output commodities, which isn't ideal (note a similar problem in MUSE1 Error when calculating commodity prices for technologies with multiple outputs MUSE_OS#551). It can't just be a simple matter of distributing these costs based on the output coefficients, because these could very well be in different units (e.g. kg for one output and PJ for another). Two potential solutions:

  • only include the AFC component in the price of the primary output
  • otherwise, we'll need some extra parameter somewhere to explicitly define how to distribute these costs between the outputs

[ahawkes]

@ahawkes I've given this a go like you've suggested (#1021) and I think it mostly works, but I have some questions:

• In some cases there might be no assets producing a particular commodity in a particular timeslice. We've got around this before for the shadow pricing method by adding candidate assets with a tiny capacity, which seems to work. For the new "full cost" method, should we still consider these hypothetical candidate assets, or limit the calculation to real assets with larger capacity (I guess it's possible to get a number out even though capacity is 0.00001, but not sure whether it makes sense). If not, should we revert to the shadow price for these missing prices?

Yes we need prices for these missing commodities. And we need it to include fixed costs like other assets. Suggest we use same method as other assets. If the numbers that come out of this are not sensible due to the very small capacity, we could assume dispatach of a unit of capacity is its maximum (which may vary by timeslice). Let me know if you spot any issues with this approach.

• How do we deal with processes with multiple outputs? The way I've currently done it you end up incorporating the full AFC into the price of all output commodities, which isn't ideal (note a similar problem in MUSE1 Error when calculating commodity prices for technologies with multiple outputs MUSE_OS#551). It can't just be a simple matter of distributing these costs based on the output coefficients, because these could very well be in different units (e.g. kg for one output and PJ for another). Two potential solutions:

  • only include the AFC component in the price of the primary output
  • otherwise, we'll need some extra parameter somewhere to explicitly define how to distribute these costs between the outputs

Yeah, tricky. I think we have to distribute AFC somehow. It would be rare - though possible - to have two SED outputs with different units. I think we distribute the AFC between SED outputs based on output coefficients for now. And document it - noting that the assumption is that they have the same units?

I thought of another issue here. I think it also exists in MUSE1? Where there's an investment, but then in a later MSY the asset is not used or used very little, the AFC component becomes really large, as denominator is small. Any thoughts on this?

[tsmbland]

@ahawkes Thanks!

@ahawkes I've given this a go like you've suggested (#1021) and I think it mostly works, but I have some questions:

• In some cases there might be no assets producing a particular commodity in a particular timeslice. We've got around this before for the shadow pricing method by adding candidate assets with a tiny capacity, which seems to work. For the new "full cost" method, should we still consider these hypothetical candidate assets, or limit the calculation to real assets with larger capacity (I guess it's possible to get a number out even though capacity is 0.00001, but not sure whether it makes sense). If not, should we revert to the shadow price for these missing prices?

Yes we need prices for these missing commodities. And we need it to include fixed costs like other assets. Suggest we use same method as other assets. If the numbers that come out of this are not sensible due to the very small capacity, we could assume dispatach of a unit of capacity is its maximum (which may vary by timeslice). Let me know if you spot any issues with this approach.

Ok, I think this is reasonable.

To clarify, are we always considering candidates or only when there are no actual assets to serve the commodity? E.g if the most expensive operational asset has a full cost of X, but there's a candidate with a higher full cost of Y, which do we use for the commodity price?

• How do we deal with processes with multiple outputs? The way I've currently done it you end up incorporating the full AFC into the price of all output commodities, which isn't ideal (note a similar problem in MUSE1 Error when calculating commodity prices for technologies with multiple outputs MUSE_OS#551). It can't just be a simple matter of distributing these costs based on the output coefficients, because these could very well be in different units (e.g. kg for one output and PJ for another). Two potential solutions:

  • only include the AFC component in the price of the primary output
  • otherwise, we'll need some extra parameter somewhere to explicitly define how to distribute these costs between the outputs

Yeah, tricky. I think we have to distribute AFC somehow. It would be rare - though possible - to have two SED outputs with different units. I think we distribute the AFC between SED outputs based on output coefficients for now. And document it - noting that the assumption is that they have the same units?

Do you think it's worth including a "units" column in the "commodities.csv" file so we can check and enforce this? We would be clear in the documentation that this is not used for internal conversions, only to check consistency. In any case I think it's not a bad thing to force the user to keep a record of the units they're using.

I'm also wondering what happens if the commodity outputs from an asset have different strategies? E.g. commodity A uses the "shadow pricing" strategy and commodity B uses the "full cost" strategy. In this case would we apply the full capital costs/fixed operating costs to commodity B? What about variable operating costs, input levies, flow costs? Or perhaps we should force them to use the same strategy?

Also, if there's an output levy on one commodity, do we apply the entire levy to the full cost of that commodity, or do we share this between all output commodities?

I thought of another issue here. I think it also exists in MUSE1? Where there's an investment, but then in a later MSY the asset is not used or used very little, the AFC component becomes really large, as denominator is small. Any thoughts on this?

There's a potential saving grace here that unused assets are likely to be decommissioned early. However, this won't always be the case. We've now got a "mothballing" feature so assets could stick around unused for a while - what should we do in this case? We could maybe exclude mothballed assets from the price calculation? Once we've introduced partial mothballing/decommissioning for divisible assets, then maybe the problem won't be so bad...?

One other problem - it's only possible to calculate AFC per unit output if there's some activity throughout the year (otherwise it would be infinite). I'm currently just excluding assets with zero activity from the calculation, but it does mean that it's possible that some commodities won't get a price - in particular if there's no demand for that commodity, so all assets (existing and candidate) have no activity. At the moment these commodities just won't get prices and the code will break if it needs these prices. Not ideal - can you think of a better backup option?

---

Finally, as I go through the example models testing out these approaches, are there any particular commodities I should focus on for the "full cost" method?