Skip to content

Conversation

@tsmbland
Copy link
Collaborator

@tsmbland tsmbland commented Dec 13, 2024

Description

See first two points in this comment. We want objectives to use the investment year commodity prices, and only these prices, when calculating current and future costs.

It's not obvious unless you enter debug mode, but prices has a "year" dimension where the first year is the current year and the second year is the investment year (previously the third year would have been the forecast year, if applicable, but I've accidentally broken this, see #603). I'm not entirely happy about selecting based on the index, but it's the best I can do for now without larger refactoring.

This is prep work for #556, where all the costs functions have been changed to only accept prices for a single year (which will be broadcast into the future - no interpolation)

@ahawkes Can you confirm that this is correct. i.e. when calculating costs over the lifetime of a technology (e.g. LCOE), we want to always assume flat-forward prices from the investment year - correct?

@tsmbland tsmbland requested a review from dalonsoa December 13, 2024 17:07
@tsmbland tsmbland marked this pull request as ready for review December 13, 2024 17:10
Copy link
Collaborator

@dalonsoa dalonsoa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it is a very simple change, that makes the results correct, so even if not ideal, it seems cost effective.

Base automatically changed from consumption to main December 17, 2024 10:43
@tsmbland tsmbland merged commit 339ea03 into main Dec 17, 2024
13 of 14 checks passed
@tsmbland tsmbland deleted the objective_prices branch December 17, 2024 10:45
@tsmbland tsmbland mentioned this pull request Dec 17, 2024
8 tasks
@ahawkes
Copy link
Collaborator

ahawkes commented Jan 9, 2025

Yes this seems correct. (Well, not correct, but consistent). A better approach would be to have investment in the current year, rather than in the next period. But I think that change could be too complicated and is perhaps better left to MUSE 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants