Yegberink/geothermal_research_1

None

Overview

Latest release: None, Last update: 2026-10-28

Share link: https://snakemake.github.io/snakemake-workflow-catalog?wf=Yegberink/geothermal_research_1

Quality control: linting: passed formatting: failed

Deployment

Step 1: Install Snakemake and Snakedeploy

Snakemake and Snakedeploy are best installed via the Conda package manager. It is recommended to install conda via Miniforge. Run

conda create -c conda-forge -c bioconda -c nodefaults --name snakemake snakemake snakedeploy

to install both Snakemake and Snakedeploy in an isolated environment. For all following commands ensure that this environment is activated via

conda activate snakemake

For other installation methods, refer to the Snakemake and Snakedeploy documentation.

Step 2: Deploy workflow

With Snakemake and Snakedeploy installed, the workflow can be deployed as follows. First, create an appropriate project working directory on your system and enter it:

mkdir -p path/to/project-workdir
cd path/to/project-workdir

In all following steps, we will assume that you are inside of that directory. Then run

snakedeploy deploy-workflow https://github.com/Yegberink/geothermal_research_1 . --tag None

Snakedeploy will create two folders, workflow and config. The former contains the deployment of the chosen workflow as a Snakemake module, the latter contains configuration files which will be modified in the next step in order to configure the workflow to your needs.

Step 4: Run workflow

The deployment method is controlled using the --software-deployment-method (short --sdm) argument.

To run the workflow with automatic deployment of all required software via conda/mamba, use

snakemake --cores all --sdm conda

Snakemake will automatically detect the main Snakefile in the workflow subfolder and execute the workflow module that has been defined by the deployment in step 2.

For further options such as cluster and cloud execution, see the docs.

Step 5: Generate report

After finalizing your data analysis, you can automatically generate an interactive visual HTML report for inspection of results together with parameters and code inside of the browser using

snakemake --report report.zip

Configuration

The following section is imported from the workflow’s config/README.md.

Configuration

This module calculates depth-resolved geothermal potential and LCOE, reduces the results to two-dimensional rasters, and aggregates them to user-provided regions. The complete annotated example is config/config.yaml; configuration values are validated by workflow/internal/config.schema.yaml.

When the workflow is imported as a module, place these settings under the key passed to the module’s config directive, for example:

module_geothermal:
  baseline_scenario: base
  perform_sensitivity: false
  which_cycles: [orc]
  carrier_out: power
  # Add the remaining model parameters from config/config.yaml.

Workflow and scenario controls

Setting	Meaning
`baseline_scenario`	Name used for the reference scenario, normally `base`.
`perform_sensitivity`	Enables the study-wide sensitivity figures and summaries. Set it to `false` for a baseline-only run.
`scenarios`	Optional mapping or list of named scenario overrides. When supplied, it takes precedence over automatic scenario expansion.

Explicit scenarios inherit all baseline model values and replace only the listed settings:

baseline_scenario: base
perform_sensitivity: true
scenarios:
  base: {}
  shallow:
    max_depth: 3000
  long_lifetime:
    lifetime: 40.0

Conversion technologies

which_cycles selects one or more of orc, flash, and kalina. carrier_out must be power; this initial public release models geothermal electricity only. A turbine outlet temperature must be supplied for every selected electricity cycle:

which_cycles: [orc, flash, kalina]
carrier_out: power
temp_turbine_out:
  ORC: 70.0
  Flash: 150.0
  Kalina: 80.0
min_dt: 10.0

min_dt is the minimum difference in °C between production and turbine outlet temperature for electricity generation to be feasible.

Reservoir and drilling assumptions

Setting	Unit	Meaning
`max_depth`	m	Deepest evaluated layer; must be a multiple of 250 m.
`include_egs`	boolean	Whether Enhanced Geothermal Systems may be used.
`EGS_cutoff`	m	Depth below which only EGS is assumed.
`SED_NAN_POLICY`	—	`always_egs` treats missing sediment thickness as 0 m; `depth_only` permits EGS only below `EGS_cutoff`.
`drilling_cost_curve`	—	Name of the active entry in `drilling_cost_curve_definitions`.
`stimulation_cost_per_doublet`	million €2020	EGS stimulation cost per doublet.
`well_spacing`	km	Distance between production and injection wells.
`flowrate_egs`	kg/s	Mass flow rate per EGS doublet.
`flowrate_conventional`	kg/s	Mass flow rate per conventional doublet.

The supplied example defines thermogis, shamoushaki_2021, getem_2017, and getem_2025 drilling-cost curves. Custom named definitions may be added under drilling_cost_curve_definitions and selected with drilling_cost_curve. The source temperature model covers 0–10 km, so max_depth, EGS_cutoff, and all configured depth intervals must stay within that range.

Plant economics

Setting	Unit	Meaning
`orc_money_per_kw`	€2020/kW	ORC plant CAPEX.
`flash_money_per_kw`	€2020/kW	Flash plant CAPEX.
`kalina_money_per_kw`	€2020/kW	Kalina plant CAPEX.
`pump_cost`	million €2020	Pump cost per doublet pair.
`lifetime`	years	Economic lifetime.
`capacity_factor`	fraction	Annual availability for generation, from 0 to 1.
`fixed_OM_rate`	fraction/year	Fixed O&M as a fraction of CAPEX.
`parasitic_fraction`	fraction	Share of gross output consumed by auxiliary equipment.

Spatial aggregation

The workflow first converts each depth-resolved LCOE cube to two-dimensional rasters with method_2d_aggregation:

LCOE_minimization selects the least-cost feasible depth in each grid cell and calculates potential at that depth.
depth_categories retains a separate LCOE and potential raster for every interval in depth_categories, such as [0, 3000] and [3000, 6000].

It then aggregates the rasters to the polygons supplied through the shapes path variable. Select the regional method with method_region_aggregation:

quantiles divides each regional LCOE distribution into n_quantiles classes.
fixed_bins applies the intervals in fixed_bins uniformly, using strings such as "0-50" and "50-100" in €2020/MWh.
cutoff reports the potential at or below lcoe_cutoff and the mean LCOE of that potential. The cutoff is expressed in €2020/MWh.

cutoff is the quickest choice for large sensitivity sweeps. Use quantiles or fixed_bins when downstream models need a cost-supply distribution.

Sensitivity analysis

Set perform_sensitivity: true, list the variables to vary in active_sensitivity_parameters, and define each variable in sensitivity_parameters. The automatic sweep changes one parameter at a time while keeping all other baseline assumptions fixed.

Numeric parameters support either symmetric percentage changes:

active_sensitivity_parameters: [flowrate_egs]
sensitivity_parameters:
  flowrate_egs:
    max_dev_pct: 30
    steps: 1

or explicit values:

active_sensitivity_parameters: [max_depth]
sensitivity_parameters:
  max_depth:
    absolute_values: [3000, 9000]

For a boolean parameter, provide a boolean placeholder and the workflow flips the baseline value. For a categorical parameter, provide the values to explore:

active_sensitivity_parameters: [include_egs, drilling_cost_curve]
sensitivity_parameters:
  include_egs: true
  drilling_cost_curve:
    - thermogis
    - shamoushaki_2021
    - getem_2017
    - getem_2025

sens_tech (orc, flash, or kalina) selects the reference technology for sensitivity summary plots. See the repository’s config/config.yaml for the full set of supported sensitivity parameters and example ranges.

Configuration validation rejects unsafe or duplicate scenario names, unknown sensitivity parameters, missing sensitivity definitions, invalid explicit overrides, and drilling-cost curves without a selected definition. It also requires ordered, non-overlapping depth and LCOE bins. Scenario names may use letters, digits, _, -, and ., and must begin with a letter or digit.

Inputs and outputs

Configuration controls model behaviour; file placement is controlled through Snakemake path variables. See INTERFACE.yaml for the required polygon input and public module outputs, and the integration example for a complete import.

The shapes input is GeoParquet and must have a declared CRS, unique shape_id values, and valid Polygon or MultiPolygon geometry. shape_class is optional; rows with shape_class: maritime are excluded from aggregation.

geothermal_regions.parquet has the following public columns:

Column	Meaning
`technology`	Conversion cycle (`orc`, `flash`, or `kalina`).
`depth_category`	Configured depth interval, or `all_depths` after LCOE minimization.
`region_id`	String form of the input `shape_id`.
`price_bin`, `bin_id`	Human-readable and path-safe identifiers for the LCOE interval.
`bin_left`, `bin_right`	LCOE interval bounds in €2020/MWh; the lower bound is empty for cutoff aggregation.
`potential`	Net electric capacity in MW.
`mean_lcoe`	Potential-weighted mean LCOE in €2020/MWh.
`n_cells`	Number of contributing raster cells.
`geometry`	Aggregation-region polygon in the input CRS.

overall_potential_by_scenario.tsv reports study-wide potential in TW by scenario and technology. overall_potential_summary.tsv reports the baseline and its sensitivity envelope in TW.

Development environments

The repository separates its Pixi development environment from the minimal module environment used by Snakemake rules. After changing runtime dependencies, run pixi run export-snakemake-env module to regenerate workflow/envs/module.yaml and its platform pin files. Run pixi run test-quick for the fast validation suite.

Linting and formatting

Formatting results

[DEBUG] 
[DEBUG] 
[DEBUG] In file "/tmp/tmpf4hwupod/workflow/rules/_utils.smk":  Formatted content is different from original
[DEBUG] 
[DEBUG] 
[DEBUG] 
[DEBUG] 
[DEBUG] 
[INFO] 1 file(s) would be changed 😬
[INFO] 6 file(s) would be left unchanged 🎉

snakefmt version: 0.11.5