[BUG] LOCE calculation is incorrect when more than one time slice is present

[ahawkes]

Describe the bug

A clear and concise description of what the bug is, including error messages.

Email from Sara G: "to calculate the lcoe, all the costs are calculated and then allocated to the timeslices. Installation-related capital, fixed, and variable costs are therefore distributed over the timeslices. The costs are summed up and then divided over the energy produced by timeslice. When there is zero production in a timeslice, to avoid zero division in the algorithm, a very small epsilon amount is used. This can cause the big number in the output."

This is an error because a zero output in a time slice is a common situation. E.g. solar power at night.

The "big number" result should only happen when total output over the whole year approaches zero.

To Reproduce

Steps to reproduce the behavior. Attache any input file that might be required.

Add a technology with zero output in a time slice. There needs to be more than one time slice.

Expected behavior

A clear and concise description of what you expected to happen.

The correct approach here is (I think - please feel free to pursue workable alterantives):

1. calculate variable cost (fuel, variable O&M, CO2, etc) in each time slice
2. calculate non-variable parts of cost (installation and fixed costs) and distribute across time slices in proportion to output. Note that if a time slice has zero output, none of these costs will be distributed to that time slice.
3. divide resulting value for each time slice by the output in that time slice (except where output is zero, to avoid a divide by zero error - if it's zero then set LCOE to zero for that time slice)

In the above we would also need to check what happens for cases where output is very very small but not zero - could be unstable.

Screenshots

If applicable, add screenshots to help explain your problem.

Context

Please, complete the following to better understand the system you are using to run MUSE.

• Operative system Windows 10 (probably all)
• MUSE version 1.1.0
• Installation method (eg. pipx, pip, development mode): All
• Python version (you can get this running python --version): n/a

[dalonsoa]

1. calculate variable cost (fuel, variable O&M, CO2, etc) in each time slice
2. calculate non-variable parts of cost (installation and fixed costs) and distribute across time slices in proportion to output. Note that if a time slice has zero output, none of these costs will be distributed to that time slice.
3. divide resulting value for each time slice by the output in that time slice (except where output is zero, to avoid a divide by zero error - if it's zero then set LCOE to zero for that time slice)

@ahawkes , I've tried to do this, but I'm afraid the result is not what you were expecting. If we set the LCOE for a particular timeslice to zero, the investing algorithm concludes it is super cheap to invest into that technology and will try to install it. Naturally, when calculating how much extra capacity needs to be installed to match the demand, the result is infinite as there is no production during that timeslice, hitting the following error:

muse.errors.GrowthOfCapacityTooConstrained: Error during the investment process. 
The capacity was not allowed to grow sufficiently in order to match the demand. 
Consider increating the MaxCapacityAddition and/or the MaxCapacityGrowth in the technodata.

The main problem I can see is that we are calculating the maximum capacity required to fulfill the demand on a timeslice basis, and then using NREL formula where the utilisation factor (or capacity factor, as they call it) is meant to be an average value over a whole year. An utilisation factor for such a granular timeslice does not makes sense in the light of this calculation, as far as I can tell.

Indeed, calculating the LCOE at the timeslice level seems odd. It is a magnitude used to measure the cost of a technology over its lifetime, so it is not surprising that if calculated at a short enough timescale levels, the results are nonesense.

I wonder if the LCOE should be timeslice independent and if we should be averaging the values (utilisation factor and production) over the whole year, using appropriate weightings based on the timeslices, in order to calculate the results.

What do you think, @ahawkes ?

[ahawkes]

@dalonsoa right - yes the time slice level LCOE is indeed nonsense (though see side-note on this below). LCOE is calculated over the lifetime of the asset. So if we look at a single year, we should figure out utilisation by (a) calculating the output of the technology over all time slices, (b) dividing this by the maximum annual output (which is determined by its capacity). So yes, I think your proposed solution is correct.

The side-note is this: I believe LCOE is (or can) be used to calculate time-sliced commodity prices. In this case, it does make sense to calculate LCOE at time slice level, but it has to be done using the method I set out above (which avoids divide by zero errors, and does not distribute non-variable costs to time slices that do not have output).

[dalonsoa]

OK, I'll implement the solution I suggest for now and see what we get.

About the side note, I'm not entirely sure what you mean. Keeping aside mathematical errors, which are avoided with your method, having an LCOE equal to zero in a time slice will be somewhat misleading to calculate commodity prices in that time slice. Thinking on solar energy, it is not the case that it costs nothing at night, is that there's no energy to buy!

[ahawkes]

Thanks. That's a good point, and could be an issue in some circumstances.

The price calculation is important to determine internal commodity prices, which are then used in calculation of investment-related LCOE (and other objectives) of assets that consume those commodities, and so-on. The issue you describe would only be an issue where no commodity is produced by any technology in a time slice - which is very unlikely in a standard systems model - but could be an issue if the framework is used in unexpected ways (which is entirely possible).

For asset investment LCOE calculation, the change proposed here will make the LCOE just a single value that depends on annual utilisation (so essentially its the same in every time slice).

For the commodity price calculation (which presumably happens elsewhere in MUSE), where the commodity price is assumed to be based on LCOE (I think there are options here, it's either LCOE-based or marginal price based, where marginal price is variable costs only), there are a few defensible ways to do this. One could (a) use the output-weighted average LCOE of every asset contributing in the time slice, or (b) use the highest LCOE of all assets contributing in a time slice. Then we come to your question - if all assets have zero output of the commodity in a time slice, what do we do? I think we would need to break that down into a few cases, (1) where all of the available assets (including all possible new assets) have an upper bound of output in that time slice of zero, then price should be infinite because there's simply no way to get that commodity in that time slice, and (2) where there are available assets that could produce the commodity in that time slice (but aren't doing so yet), it perhaps should the LCOE or marginal cost of the cheapest one (though this is debateable - actual price will depend on which asset is actually chosen). Anyway, it seems like this price issue is not the one you're dealing with in relation to this bug - rather you are looking at the asset investment - and have found a serious issue there. Should a new issue be raised for this price calculation problem?

[dalonsoa]

I think this should be doable. The LCOE used for investment is done in here, while the one used for calculating commodity prices is done in this other place, so it should be possible to implement the logic you indicate. It will be useful to do it in two separate issues, yes, so we have the chance to properly asses the code changes related to one of the changes.

Indeed, we should start with the second one, changing the commodity prices calculation so it uses a more robust logic when the utilization factor is zero for one or more timeslice, and then change the investment part. Otherwise, we might end up with the situation commented above of having preferred technologies to invest because of its low price in a timeslice that have no production in that timeslice.

Update: second issue is #288

[ahawkes]

Thanks Diego, Actually the investment part is a higher priority, as every model out there right now is making serious mistakes. The commodity price issue is important, but would only apply in outlier cases I think. Can we deal with the investment part ASAP, check it, and do a release to fix for users? Also can we check if any other investment objectives are calculated for each time slice when they should be annual? Note if there is a release there is knock on impact for @bland, ***@***.***> work - as presumably examples will change - with knock on updates needed for documentation and OU course. Hmmm, not sure what to do about that - as there will be further releases with further knock on changes. P.S. perhaps there’s also a further issue with investment in that one does not know dispatch when objectives are being calculated? Can you let me know what is assumed in this regard? Does it assume upper bound of output in each time slice when calculating utilisation, or does it somehow use actual dispatch (and if so, how is this known at the point objectives are calculated)? Note this is an issue that I think the approach in MUSE 2.0 will largely solve, but still we need a defensible approach in MUSE 1.x

…

________________________________ From: Diego Alonso Álvarez ***@***.***> Sent: Friday, May 3, 2024 10:56:26 AM To: EnergySystemsModellingLab/MUSE_OS ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***> Subject: Re: [EnergySystemsModellingLab/MUSE_OS] [BUG] LOCE calculation is incorrect when more than one time slice is present (Issue #246) This email from ***@***.*** originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address. I think this should be doable. The LCOE used for investment is done in here, while the one used for calculating commodity prices is done in this other place, so it should be possible to implement the logic you indicate. It will be useful to do it in two separate issues, yes, so we have the chance to properly asses the code changes related to one of the changes. Indeed, we should start with the second one, changing the commodity prices calculation so it uses a more robust logic when the utilization factor is zero for one or more timeslice, and then change the investment part. Otherwise, we might end up with the situation commented above of having preferred technologies to invest because of its low price in a timeslice that have no production in that timeslice. — Reply to this email directly, view it on GitHub<#246 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLNN4OT2NNDAKWBOC5LZAM7KVAVCNFSM6AAAAABD5VPHZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJSGQ4TMMBYGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>