Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix odd tools.costs projections for technologies with first years in the future #169

Closed
measrainsey opened this issue Apr 11, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@measrainsey
Copy link
Contributor

There are a few technologies (mainly CCS) in the tools.costs module that have their first years after 2020 or 2021 (usually 2030). For some reason, their costs projections during between 2020 and the start year look kind of strange. See example below with bio_istig_ccs.

bio_istig_ccs

I did a check and the reference region's cost at 2020 and 2030 (in this case) are the same. So, this shouldn't really have a big impact on the results if we're making sure to only add in the cost data from the start year onwards when updating the inv_cost or fix_cost parameters in MESSAGE.

The possible problems are that this (a) could be slightly affecting the results of the non-reference regions and (b) feels like bad form. I will add it to my list to fix this issue and to modify the tool to not project costs for technologies before their start year.

However, this does bring up the issue on how to deal with "base year" costs when a technology's start year is 2030, for example. Does the base year cost refer to start year cost or the cost in 2020 and therefore needed to adjust for start year?

@measrainsey measrainsey added the bug Something isn't working label Apr 11, 2024
@measrainsey measrainsey self-assigned this Apr 11, 2024
@measrainsey measrainsey changed the title Odd projections from tools.costs for technologies with first years in the future Fix odd tools.costs projections for technologies with first years in the future Apr 11, 2024
@glatterf42
Copy link
Member

Please help me understand: do we already have something like "base year cost" in the model or is this an addition from your recent PR merger?
If the former, I'd hope it's documented. If it's not documented or the latter, I'd draw the attention of specific experienced colleagues to this PR by mentioning them with @.

@measrainsey
Copy link
Contributor Author

@glatterf42 From what I understand, base year costs are not exactly in MESSAGEix itself, but base year costs are used when projecting investment costs and fixed operational and maintenance costs. This can be traced back to the older method of projecting costs here in message_data. Specifically, the NAM_technology_cost_input_20200507.xlsx file has details of how base year costs are derived for each technology (in this case, mostly energy technologies).

The base year cost values in the spreadsheet linked above are used in the recent tools.costs PR merge, as an input data column called base_year_reference_region_cost (for example, in this file). The data is read in by the get_raw_technology_mapping() function.

Regarding the specific issue of the spike in costs projections mentioned, I spoke with Volker about this yesterday, and we have decided on a way to address it. So I think I have a path forward for that.

But regarding the broader issue of base year cost and whether that's documented somewhere, the base year cost is only briefly mentioned in the "Modules and model variants" portion of the tools.costs documentation. If this feels insufficient (and if additional details/information should be written down somewhere), then I am happy to help in documenting this. Although we would have to decide/discuss what to actually write down (just the concept of base year costs, or how we derived the values for different technologies), and where this documentation should go (within the tools.costs documentation or elsewhere).

@glatterf42
Copy link
Member

Thanks for the explanation :)
If I understand correctly, the base year cost is mainly used as input in tools.costs, so I would describe what it refers to in the docs of tools.costs. For the actual values, I think it depends if they are somehow project-specific. In that case, their origins should probably be explained in project-specific docs. If there is just one version of every value for now or if they are generally applicable, I'd include at least one or two examples of how those values can be derived in the general tools.costs.base year cost section.

@measrainsey
Copy link
Contributor Author

The problem with the costs jumping has been fixed with #186, so closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants