Repository: https://github.com/tylerirvin543/Steamboat_Creek_Geochemistry_Database

1 Research Context and Motivation

The Steamboat Springs geothermal field in Reno, Nevada represents a complex intersection of long-term geothermal production and a dynamically evolving hydrothermal system. After more than four decades of sustained fluid extraction and reinjection—during which surface expressions such as geysers, fumaroles, and hot springs largely ceased—the system experienced a dramatic reawakening in June 2025, characterized by a geyser-like eruption exceeding 30 meters in height from an abandoned well.

The scientific goal of this project is to construct a reproducible and extensible data infrastructure capable of integrating historical regulatory chemistry, modern field measurements, laboratory analyses, and sensor data. This framework supports hypothesis testing related to pressure-driven and geochemical triggers for renewed hydrothermal activity and serves as the foundation for subsequent geochemical modeling.

2 Data Sources

This database integrates heterogeneous data streams including:

All sources are ingested through scripted workflows to ensure reproducibility and provenance.

3 Geochemical Modeling and Reproducibility

Validated chemistry is transformed programmatically into PHREEQC-ready input tables. Forward speciation and inverse modeling are executed externally with results written back to the database, ensuring a complete link between observations, interpretations, and modeled processes.

All ingestion, validation, and analysis steps are scripted and version-controlled. Raw input files are archived prior to ingestion, and no manual database edits are performed.

Conceptual workflow and relational structure of the Steamboat geochemical database, illustrating the integration of regulatory, field, laboratory, and sensor data through controlled ingestion pipelines into a normalized relational schema.

4 Database Run Configuration

DB_DEMO <- "database/geochem_demo.sqlite"
DB_PROD <- "database/geochem_operational.sqlite"

MODE <- "DEMO"   # or "OPERATIONAL"  or "DEMO"

DB_PATH <- if (MODE == "DEMO") DB_DEMO else DB_PROD

DEMO mode - Database rebuilt from scratch - Deterministic - Used for teaching and reproducibility

OPERATIONAL mode - Database persists - Ingest happens only when explicitly invoked - Protects real field and lab data

Demonstration vs. Operational Databases

For reproducibility and teaching purposes, figures in this document are generated from a demonstration database rebuilt from raw inputs at render time. During active research, the same ingestion pipelines are run incrementally against a persistent operational database, allowing the ingest run log to accumulate and reflect real system evolution through time. In operational mode, ingest‑history visualizations are suppressed until data are ingested, reflecting the true state of the research database prior to field or laboratory uploads.

5 Script Calls for Data Ingest

# Ensure database directory exists
dir.create("database", showWarnings = FALSE)

# Open connection ONCE
con <- DBI::dbConnect(RSQLite::SQLite(), DB_PATH)
DBI::dbExecute(con, "PRAGMA foreign_keys = ON;")
## [1] 0
# --------------------------------------------------
# Ensure schema exists (DEMO or first OPERATIONAL run)
# --------------------------------------------------
tables <- DBI::dbListTables(con)

if (!"Locations" %in% tables) {
  message("No schema detected — creating schema.")
  source("database/schema/01_define_schema.R")
}

# --------------------------------------------------
# DEMO MODE: deterministic rebuild
# --------------------------------------------------
if (MODE == "DEMO") {

  message("DEMO mode: rebuilding database.")

  DBI::dbDisconnect(con)
  unlink(DB_PATH)

  con <- DBI::dbConnect(RSQLite::SQLite(), DB_PATH)
  DBI::dbExecute(con, "PRAGMA foreign_keys = ON;")

  source("database/schema/01_define_schema.R")

  source("scripts/ingest/ingest_ndep.R")
  # source("scripts/ingest/ingest_field.R")
  # source("scripts/ingest/ingest_temperature_loggers.R")
  # source("scripts/ingest/ingest_lab.R")
  # source("scripts/ingest/ingest_photos.R")
}

# --------------------------------------------------
# OPERATIONAL MODE: explicit, incremental ingest
# --------------------------------------------------
if (MODE == "OPERATIONAL") {

  message("OPERATIONAL mode: persistent database.")

  # Run NDEP once if empty
  if (DBI::dbGetQuery(con, "SELECT COUNT(*) AS n FROM Lab_Analyses")$n == 0) {
    message("Running initial NDEP ingest.")
    source("scripts/ingest/ingest_ndep.R")
  }

  # Field ingest (safe to re-run; no-op if empty)
  # source("scripts/ingest/ingest_field.R")

  # Logger metadata ingest
  # source("scripts/ingest/ingest_temperature_loggers.R")

  # Lab ingest
  # source("scripts/ingest/ingest_lab.R")

  # Photos ingest
  # source("scripts/ingest/ingest_photos.R")
}

5.1 Example Database Graphed Query Calls

5.1.1 “What is actually happening in the database as data accumulate?”

5.1.2 “What kinds of chemistry paramaters does the database contain?”

5.1.3 “How does raw chemistry turn into geochemical modeling?”

5.1.4 ndep vs field measurments

5.2 Ingestion over time

5.3 By data source

“Database updates were tracked using a persistent ingest run log that records the timestamp, data source, and number of records inserted for each ingestion event. Visualization of ingest activity through time demonstrates both the reproducibility and incremental growth of the database, including deliberate no‑op runs when no new data were present. This audit trail ensures transparency in how regulatory, field, laboratory, and sensor datasets contribute to the evolving database.”

5.4 photos

Photographic observations are ingested as structured metadata and linked to sites, sampling events, and field probe samples where applicable. Image files were archived externally, while metadata were stored relationally to preserve provenance without embedding binary data in the database.

6 Current State of Database

Note: In operational mode, ingestion scripts are executed explicitly and independently. Re‑knitting this document does not modify the database and functions as a read‑only, reproducible report.