Add geothermal-sourced central heat pumps

[amos-schledorn]

This feature adds geothermal-sourced central heating based on utilisation potentials by Manz et al. and technology data from the DEA techn. catalogue.

Changes proposed in this Pull Request

-retrieve_fraunhofer_heat_source_utilisation_potentials: retrieve heat source potentials for those heat sources set in config under sector:district_heating:fraunhofer_heat_utilisation_potentials if the respective source is listed in the config under sector:heat_pump_sources:urban_central
-build_heat_source_potentials: map utilisation potentials to onshore-regions and scale them by a) FLH and b) unit (input is TWh)

• build_cop_profiles: a) COP for fixed-source temperature geothermal heat is computed as for air-sourced heat pumps, b) for all sources: COP is set to zero if source temperature exceeds forward temperature
• build_direct_heat_source_utilisation_potentials: generates profiles in the same format as COP profiles. 1, when (where) forward temperature above source temperature, 0 otherwise.
• prepare_sector_network: If heat pump source is in fraunhofer_heat_sources, then add a generator. The corresponding heat pumps convert 1 MWe (electricity) + (COP - 1) MWth (geothermal heat) to COP MWth usable central heat. Also add a direct-utilisation-link (using the aforementioned profiles) that converts the heat source to urban central heat 1-to-1.

Notes

• DEA technology data refers to 1200m deep geothermal district heating (in contrast to 2000-3000m assumed in Manz et al.)
• The results for low spatial resolution can be inaccurate: Geothermal heat is overused as relatively large areas are modelled as heat lakes. This could be remedied limiting the geothermal potential pre-clustering to the NUTS3 heat demand (and then summing the limited geothermal wattage). That's why I would suggest turning geothermal heat off by default.
• Any heat source from the Manz et al. (2024) can be used by adjusting the config accordingly.
• This feature necessitates an additional technology for direct geothermal heat utilisation (c.f. feature in technology-data, which is why the related config setting points to the technology-data master, rather than the latest release. I'm not entirely sure how to resolve that.

Checklist

• I tested my contribution locally and it works as intended.
• Code and workflow changes are sufficiently documented.
• Changed dependencies are added to envs/environment.yaml.
• Changes in configuration options are added in config/config.default.yaml.
• Changes in configuration options are documented in doc/configtables/*.csv.
• Sources of newly added data are documented in doc/data_sources.rst.
• A release note doc/release_notes.rst is added.

Testing

I've used the following config for testing:

  name: 
    - no-geothermal-365h
    - geothermal-365h
  scenarios:
    enable: true
    file: config/scenarios.yaml

scenario:
  clusters:
    - 6
    - 20
    - 60
  planning_horizons:
    - 2030

foresight: overnight
countries: ['DE', 'DK']

clustering:
  temporal:
    resolution_sector: 365h

with the following scenarios.yaml:

  sector:
    heat_pump_sources:
      urban central:
      - air

geothermal-365h:
  sector:
    heat_pump_sources:
      urban central:
      - air
      - geothermal

Results for the no-geothermal-365h scenario seem like a reasonable baseline:

In the geothermal-365h scenario, it becomes apparent that we need to use a high spatial resolution, since geothermal heat utilisation varies strongly going from 6 to 20 to 60 clusters (note that the order in the plot is 20, 6, 60):

I've quickly checked this and we can see that, if for each region, the geothermal potential is capped by the heat demand (i.e. we take the max. of the two per region) and sum over regions, this number decreases with an increasing number of clusters:

Hence, I propose to turn this feature off by default (I'm just leaving this turned on for the CI but would change this before merging - so please do not merge (or turn off geothermal heat in the config).

[github-actions]

Validator Report

I am the Validator. Download all artifacts here.
I'll be back and edit this comment for each new commit.

❗ Run failed!

Download 'logs' artifact to see more details.

• master passed! ✅
• add-geothermal-sourced-heat-pumps failed in: no_logs_found

Model Metrics

Benchmarks

Comparing add-geothermal-sourced-heat-pumps (0d8f4ad) with master (920ffb4).
Branch is 50 commits ahead and 2 commits behind.
Last updated on 2024-12-09 18:04:29 CET.

[cpschau]

Looks very good and clean to me! I have only two formal remarks about the data documentation and the technology data version referenced in the config. I would agree to to keep it turned off, until a reasonable value is found for the upper bound. For the latter, one could maybe use the open data from the seenergies project.

[amos-schledorn]

Looks very good and clean to me! I have only two formal remarks about the data documentation and the technology data version referenced in the config. I would agree to to keep it turned off, until a reasonable value is found for the upper bound. For the latter, one could maybe use the open data from the seenergies project.

Thanks for the review, @cpschau! I've fixed the docs and technology-data version and will merge, after another test run.
I agree regarding bounds on heat source usage and opened a separate issue: #1443

[fneum]

Look good! Small change requests.