Skip to main content

BoreTHM: models of circulating temperature and borehole stability for drilling into superhot rock

BoreTHM is an open-source Python model for assessing drilling programmes in superhot geothermal rock. It couples circulating-fluid and downhole-tool temperatures with thermal stress at the borehole wall to calculate the mud-weight window: the range of fluid densities that meets the pressure constraints through drilling, connections and trips.

BoreTHM is intended for drilling engineers and researchers assessing a well design or reusing the thermal and stability calculations. Its reference cases support comparisons with field observations and published models.

Get started

Install BoreTHM with Python 3.11 or later:

python -m pip install borethm

For figures, install "borethm[plot]". Build the water-property cache and run a first assessment:

borethm-water-table
borethm-evaluate --site newberry --json newberry.json

The IAPWS-95 cache is built once, outside the installed package, in the platform's user cache directory. Set BORETHM_CACHE_DIR to choose another location. The evaluator also builds a missing cache on first use. The assessment command prints its result and saves the inputs and calculation provenance as JSON. Evaluations take several minutes; weighted-fluid cases require repeated coupled solves and can take longer.

The same assessment through the public Python interface:

from borethm import evaluate, export_result, find_site
site = find_site("newberry")
result = evaluate(site)
export_result(result, "newberry.json")
print(result["status"]["label"])

Reproduce the reference calculations

Use Python 3.14.4 and the locked dependencies in a source checkout:

git clone https://github.com/ldocallaghan/BoreTHM.git
cd BoreTHM
python -m venv .venv

Use python3 if your system does not provide python. Activate the environment with .\.venv\Scripts\Activate.ps1 in PowerShell, or source .venv/bin/activate on Linux and macOS, then install:

python -m pip install -r requirements-lock.txt
python -m pip install --no-deps -e .
borethm-water-table

Commands for releases before v1.4.0 are in their release records and run from that release's tag.

Run your own assessment

The built-in site keys are soultz, united-downs, larderello, pannonian and newberry.

borethm-evaluate --site soultz --json soultz.json
borethm-sites

The first command evaluates one site; the second reports all five. Use borethm-evaluate --help for the command-line options.

For a new site, follow the site-input guide and, from a source checkout, copy the documented template. It records units and sources, and checks the inputs before evaluation. From the checkout root, the worked example can validate the template without running the full calculation:

python examples/new_site.py
python examples/new_site.py --evaluate --json result.json

The template starts with Soultz's inputs. Replace them with the new site's measurements or explicitly sourced assumptions.

Reading a result

The output guide maps the JSON fields and explains schedule identity.

Start with status and its reasons, then inspect the components that set it. The report includes the operating programme, thermal and hydraulic outputs, stability in each cycle state, allowable mud densities and equipment checks. The JSON retains every evaluated case and the source of each input.

Status Meaning for the evaluated programme and assumptions
GO The modelled checks pass without the additional conditions listed by the evaluator.
CONDITIONAL The assessment depends on stated conditions, such as prescribed fluids or a circulation schedule. Read those conditions before using the result.
NO-GO A modelled gate fails for this programme and these assumptions; the reasons identify the failing components.
INDETERMINATE A required numerical result did not converge, or an equipment qualification remains unresolved without another decisive failure.

An overall NO-GO can coexist with an INDETERMINATE coating check. Exceeding a manufacturer's stated coating rating identifies a qualification question. It does not predict a particular failure mode.

A mud-weight window is the allowable range of fluid density: enough pressure to keep the borehole stable while staying below the modelled fracture-pressure limit. BoreTHM calculates the range that satisfies all evaluated depths, operating states and stress/strength cases, separately for drilling and trips.

Two pressure descriptions appear in the outputs:

  • Target SG-equivalent expresses pressure as an equivalent static column at the target. It is a local stability diagnostic, with the existing friction/backpressure treatment.
  • Surface SG at 20 °C is fluid density divided by 1,000 kg/m³. The combined pressure constraints set the allowable range of that surface density.

A positive target interval does not establish a workable whole-hole fluid. If the required minimum density exceeds the permitted maximum, no mud density satisfies both pressure limits. The densities reported in that situation are calculation inputs and cannot be prescribed.

Example results

The reference assessments target rock at 400 °C. The table reports the base case with immediate breakout formation. Each status applies to the specified design and inputs.

Site Target, km Status Main finding
Soultz-sous-Forêts 10.70 NO-GO No drilling or trip fluid density satisfies all pressure limits; the best attempted run-in exceeds the tool limit.
United Downs 12.86 NO-GO No drilling or trip fluid density satisfies all pressure limits; drilling and run-in exceed the tool limit.
Larderello 2.40 CONDITIONAL Requires weighted drilling and trip fluids.
Pannonian Basin 9.71 NO-GO No drilling or trip fluid density satisfies all pressure limits; coating qualification is unresolved.
Newberry 3.63 GO The evaluated programme passes with water.

These sites have different evidence quality. Soultz and United Downs use measured or calibrated stresses and strengths, extrapolated to the targets. Larderello and Pannonian retain unsourced strength assumptions. Newberry's well check does not reproduce the observed pattern in every rock type. The input-source records explain those differences.

Local stability and the complete programme

At Soultz and United Downs, some stress and strength cases have an open drilling window at the target depth. Neither reference programme has a fluid density that satisfies the pressure limits throughout the hole. The reference-programme comparison gives the case tables, whole-hole pressure bounds and equipment temperatures.

Breakout timing

The assumed time between rock exposure and breakout formation can change the whole-hole drilling-fluid window. In the saved scan, that window first opens between delays of 15 and 20 minutes at Soultz, and between 10 and 15 minutes at United Downs. These are brackets from calculations with assumed delays. Breakout formation time in hot granite has not been measured in the studies reviewed here. Both complete programmes remain NO-GO because other checks still fail. The breakout-timing study explains the assumptions and results.

Design comparisons

No evaluated design change or evaluated pair made either deep-site programme pass. The design comparisons describe the tested settings and remaining failures. They do not establish a complete operating envelope or show that every possible design would fail.

The study summary, also available as a two-page PDF, brings the findings and open questions together.

Models and evidence

The circulation model solves the downgoing and returning fluid temperatures with frictional heating and heat transfer through the pipe, casing and surrounding rock. Rock conduction carries each depth through its exposure and circulation pauses. Fluid properties and pressure losses feed back into the stability and tool calculations.

Model or check Role Evidence and detail
Circulation Fluid temperatures, heat transfer and hydraulics Utah FORGE comparisons and published-model benchmark
Rock reheating Temperature recovery when circulation stops Analytic checks and the limits of the FORGE pause comparison
Borehole stability Breakout width and pressure requirements UD-1 strength calibration and other well checks
Spallation, drilling rate and creep Exploratory estimates of quench effects and closure Physical models and their limits

The circulation/FORGE comparisons, strength calibration and other checks have distinct scopes. They do not validate a complete 10-13 km drilling programme. Full derivations and diagnostic figures are in the physical-model guide; the bibliography, material properties and site inputs retain their sources.

Scope and limitations

A passing result depends on the modelled inputs and checks. A failed assessment does not establish that a different design or existing technology could not drill the site.

The deep targets lie below measured stress data. Strength calibration depends on the assumed stress profile, and the reference mud's viscosity and constant barite properties are approximations. Qualification of insulated pipe and managed-pressure equipment over the full hot drilling cycle remains unresolved.

The base case assumes that breakouts form immediately after rock exposure, before cooling can reduce the initial pressure requirement. Experiments with an assumed delay show how that requirement changes; they do not demonstrate that breakouts wait an hour to form.

The approximation comparisons test individual assumptions and numerical resolution. None changes either deep-site programme to a pass, but the study does not cover every combination of uncertainty. The limitations guide explains the input uncertainties and the approximations in coolant delivery, trip timing and fluid displacement.

Tests and reproducibility

Run the fast suite in the activated environment:

python -m pytest

The default excludes physical regressions marked slow. To include the complete suite after building the water-property cache:

python -m pytest -m "slow or not slow"

Full physical runs can take an hour or more. Single-threaded BLAS avoids oversubscription during repeated solves; set OPENBLAS_NUM_THREADS=1, OMP_NUM_THREADS=1 and MKL_NUM_THREADS=1 before starting Python for those runs.

Saved reference outputs and numerical regression tables support comparison with the published calculations. The changelog records changes. Historical diagnostic figures use their stated programmes and should be interpreted with their captions.

Find your way around the repository

Location Contents
src/borethm/ Installed package, physical models and study modules
scripts/ Standalone diagnostic and figure scripts
benchmarks/ Reference dataset with inputs, expected outputs and tolerances
examples/ Site template and worked example
docs/ Reading guide, model use, science and historical records
src/borethm/data/ Packaged observations and input-source records
results/ Retained numerical evaluations and trial evidence
tests/ Unit checks and physical regressions, including fixed reference tables
figures/ Diagnostic and field-comparison figures

How to cite and data credits

Cite BoreTHM using the software DOI. CITATION.cff provides the citation metadata. The scientific bibliography lists the scientific sources.

The benchmark dataset has a separate citation. Its DOI will be added after deposit on Zenodo.

The FORGE data come from the Geothermal Data Repository: well 16B drilling data and deep-well temperature surveys. The Newberry extracts come from well 55-29 stimulation data. These datasets are used under CC-BY 4.0. The UD-1 image interpretation contains NERC materials ©NERC 2024.

The FORGE and Newberry data guides describe the extracts and how to rebuild them. Other input sources are recorded alongside the corresponding data.

Questions and contributions

Use GitHub issues for questions and problem reports. See SUPPORT.md for what to include and CONTRIBUTING.md for development setup and proposing changes.

Licence

The code in src/, scripts/, tools/, tests/ and examples/ is released under the Apache License 2.0. The documentation, figures, results and summary PDF are released under CC BY 4.0. Data in src/borethm/data/ and benchmarks/data/ keep their source licences, as recorded in their data guides and in NOTICE. Releases up to v1.3.4 were published under the MIT licence.

Metadata

Release files for borethm 1.4.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for borethm 1.4.1
File Size Uploaded Provenance
borethm-1.4.1.tar.gz 837.0 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for borethm 1.4.1
File Interpreter ABI Platform
borethm-1.4.1-py3-none-any.whl Python 3 none any Details

Total release size: 1.7 MB

Release files / borethm-1.4.1.tar.gz

Download URL borethm-1.4.1.tar.gz
Size 837.0 kB
Tags Source
SHA-256 checksum
How to use checksums
5fd62096239cad0fc55915407a500acb8daf64c3fd8c20ae93cdc8727aa5b671
BLAKE2b-256 checksum
How to use checksums
a5bca3423acf752ff7b95049ae430ed05bfdad4b82a078d2982be328b2d1044f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

Release files / borethm-1.4.1-py3-none-any.whl

Download URL borethm-1.4.1-py3-none-any.whl
Size 853.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
0e39e4f3faa4609ffc23b223dcdc9c649c78a8243b466be3e667df5a264d94d3
BLAKE2b-256 checksum
How to use checksums
1e5f257d779231a34a3d0db6f0ca66db91280f8e357d62819a83d67bb3c0e773
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

Security for borethm 1.4.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for borethm-1.4.1.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page