Missing geothermal investment costs lead to solver issues

[Eric-Nitschke]

Checklist

• I am using the current main branch or the latest release. Please indicate.
• I am running on an up-to-date pypsa-earth environment. Update via conda env update -f envs/environment.yaml.

Summary

Geothemal generators can be extended without costs when using enable: retrieve_cost_data: true and extendable_carriers: Generator: [geothermal]. This leads to solver issues, as there is now an infinite number of solutions that are equality good.

Describe the Bug

When using enable: retrieve_cost_data: true, PyPSA-Earth downloads costs_[year].csv from the PyPSA technology database. If enable: retrieve_cost_data: false is used instead, PyPSA-Earth uses data/costs.csv . While data/costs.csv contains a value for the investment costs of geothermal generators, costs_[year].csv from the database does not. As a result, it will then default to the fill-values provided in the config under costs: fill_values: investment: 0. This is problematic since:

• geothermal generators now don't cost anything, leading to wrong results
• if geothermal generators are included in extendable_carriers: Generator: [...], they will most likely be build a lot as extending them doesn't cost anything
• if their p_nom_max is sufficiently high, extending them past a certain point does not impact the system costs anymore. As a result, there is an infinite amount of solutions, which are equaly good. This can lead to the solver continuously trying to perform DPushes (which could look something like the error message), resulting in the solver shutting down.

This could be solved by either providing an investment cost for geothermal in the technology database or by using a non-zero fill value for the investment instead. The second option however may have unexpected consequences elsewhere in the code.

Error Message

2816 DPushes remaining with DInf 0.0000000+00

[ekatef]

Hello @Eric-Nitschke, interesting!

I can reproduce the issue and confirm that there is something wrong here. It appears that investment costs for geothermal have been lost for some reason from PyPSA/technology-database on which we relay for building costs inputs for each time horizon. E.g. for 2035 geothermal costs do not contain investments, while organic Rankin cycle and central geothermal heat source do. Not sure what exactly was the reason but it appears investments filed has been missed for geothermal: I see that it's still there for v0.6.0 but seems to be removed after.

A great catch and feel free to open an issue or a PR in https://github.com/PyPSA/technology-data.

[For you modeling use case, I assume you are perfectly aware that PyPSA-Earth does not (yet) support expansion of geothermal by default for any country. While it's indeed perfectly possible using custom implementations]

[Eric-Nitschke]

Hey @ekatef,

thank you for your response!

It seems like the issue was already identified in the technology database repository by Issue #146, though it was never investigated further. I've added a comment to the original issue and suggest, we move any further discussion to it as well. However, I'd leave this issue open until it is addressed.

[Yes I am aware of it. One of my students was using a custom geothermal implementation, when we initially encountered the issue.]

[ekatef]

Hey @ekatef,

thank you for your response!

It seems like the issue was already identified in the technology database repository by Issue #146, though it was never investigated further. I've added a comment to the original issue and suggest, we move any further discussion to it as well. However, I'd leave this issue open until it is addressed.

[Yes I am aware of it. One of my students was using a custom geothermal implementation, when we initially encountered the issue.]

@Eric-Nitschke Perfect, many thanks for the investigation and the detailed comment to technology-database! Completely agree that the technology database must be model agnostic and as general as possible.

I think it's precious to be aware of implications which this pitfall has for the model, so let's keep the issue open for sure. Probably, we may need to add some safety procedure which uses the data from data/costs.csv to fill gaps in the costs values extracted from technology-database.