EAC and negative costs

[tsmbland]

I've been looking into the EAC objective as it's relevant for one of the tutorials, and I've been getting some strange behaviour. Not sure if this counts as a bug per se, which is why I bring it up here rather than creating an issue, but I think it's worth flagging anyway.

Just taking a very simple example, here's what happens if I take the default model and switch the single agent objective from LCOE to EAC:

The black dashed line is the capacity that the system needs to satisfy heating demand in the peak timeslice. In the LCOE case, installed capacity nicely matches this line. However, in the EAC case the agent ends up massively overinvesting in heat technologies above what is needed to satisfy demand. The capacity seems to reach the limits imposed in technodata file (MaxCapacityAddition, MaxCapacityGrowth, TotalCapacityLimit). If you increase (e.g. double) these limits then you can get even more extreme behaviour:

I think this may have something to do with the fact that EAC is negative for the heating technologies (gasbioler and heatpump):

This is because EAC subtracts an (upper-bound) estimate of revenue, which in this case is very high due to the high initial cost of heat (100 $MUS). You then end up with the situation where the best way to 'minimise costs' in the investment algorithm is to invest as much as possible in technolgies with negative EAC. Mathematically this makes sense, but logically it's a bit nonsensical to invest in all this extra capacity which will just be sitting idle.

Part of the problem may lie in the EAC calculation, which seems to assume that technologies will be running at full capacity, which can give an inflated estimate for the revenue. In any case, as long as the EAC is negative it seems like you're bound to get this kind of behaviour where the agent invests as much as it possibly can, which doesn't seem realistic to me.

Not sure whether this is something worth thinking more about, or just something that users need to be aware of when using the EAC objective (or any other objective that can be negative). Perhaps this is something MUSE2 already plans to address?

Anyway, if anyone has any thoughts about this I'd be very interested to hear.

[tsmbland]

@dalonsoa

[dalonsoa]

I think your diagnosis of the meaningless simulation results makes sense. Now, I don't know if a negative EAC also makes sense and is an scenario that might actually happen. I don't know, maybe with heavily subsidised technologies or something like that is more profitable to install as much as you can.

@ahawkes , is this something that can actually happen or is there an error in the calculation and the EAC should be limited to positive values or something entirely different?

[ahawkes]

Hi there, thanks for this. Negative EAC would seem rather odd! I think it could only happen if commodity prices (of consumed commodities) was negative. And I struggle to imagine a scenario where that would happen. Can we dig into this?

…

________________________________ From: Diego Alonso Álvarez ***@***.***> Sent: Thursday, May 30, 2024 5:13:40 PM To: EnergySystemsModellingLab/MUSE_OS ***@***.***> Cc: Hawkes, Adam D ***@***.***>; Mention ***@***.***> Subject: Re: [EnergySystemsModellingLab/MUSE_OS] EAC and negative costs (Discussion #316) 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 your diagnosis of the meaningless simulation results makes sense. Now, I don't know if a negative EAC also makes sense and is an scenario that might actually happen. I don't know, maybe with heavily subsidised technologies or something like that is more profitable to install as much as you can. @ahawkes<https://github.com/ahawkes> , is this something that can actually happen or is there an error in the calculation and the EAC should be limited to positive values or something entirely different? — Reply to this email directly, view it on GitHub<#316 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC37JLKSFRLQFQMZAA4TWNLZE4XZJAVCNFSM6AAAAABIOZARLGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMMBWGU3DO>. You are receiving this because you were mentioned.Message ID: ***@***.***>