How to Use ChatGPT to Learn Hydrological Modelling (III): base R, vibe coding and reproducible projects

Write me code to calibrate a model.

I have daily precipitation [mm/day], mean temperature [°C] and discharge [m3/s]
for a catchment of 850 km2.

I want a base R function that:
1. aligns the series by date;
2. detects missing values;
3. converts discharge to mm/day;
4. returns a data.frame ready for modelling.

Do not use tidyverse.
Before programming, tell me what additional information you need.

Implement the minimum working version first.
Use base R functions.
Do not add optimisation or plotting yet.

str(x)
head(x)
summary(x)

dim(x)
length(x)

colSums(is.na(x))

Now create three simple tests that will fail if:
- dates are unsorted;
- discharge is negative;
- the lengths do not match.

stopifnot(!is.unsorted(dat$date))
stopifnot(all(dat$q >= 0 | is.na(dat$q)))
stopifnot(nrow(dat) == length(dat$date))

Explain each decision in the code that could affect the hydrological result.
Do not describe trivial syntax.

Turn the solution into reusable functions.
Add argument validation.
Keep base R and minimal dependencies.

setwd("C:/Users/my_name/Desktop/Project")

file.path("data", "precipitation.csv")

Review this project and identify absolute paths that harm reproducibility.
Suggest replacements using file.path().

dat <- read.csv("data/input.csv")
write.csv(dat, "results/output.csv", row.names = FALSE)

saveRDS(dat, "results/data_processed.rds")
dat2 <- readRDS("results/data_processed.rds")

What information might be lost if I save this object as CSV rather than RDS?

dat$date <- as.Date(dat$date)

dat$datetime <- as.POSIXct(
  dat$datetime,
  tz = "UTC",
  format = "%Y-%m-%d %H:%M:%S"
)

Give me tests that help verify whether two hydrological series really represent the same days.

idx <- dat$date >= as.Date("2000-01-01") &
       dat$date <= as.Date("2010-12-31")

cal <- dat[idx, ]

colSums(is.na(dat))

I have 2% missing precipitation values.
Do not recommend interpolation immediately.
Ask me about duration, temporal distribution and modelling purpose before suggesting a treatment.

run_experiment <- function(par, input) {
  stopifnot(is.numeric(par))
  stopifnot(is.data.frame(input))

  # run model
  sim <- ...

  sim
}

Split this script only when there is a clear functional responsibility.
Do not create unnecessary functions.

out <- lapply(files, read.csv)

out <- vector("list", length(files))

for (i in seq_along(files)) {
  out[[i]] <- read.csv(files[i])
}

plot(obs, sim,
     xlab = "Observed",
     ylab = "Simulated")

abline(0, 1)

plot(dat$date, dat$obs, type = "l")
lines(dat$date, dat$sim)

res <- dat$sim - dat$obs
plot(dat$date, res, type = "h")
abline(h = 0)

Do not suggest a plot just because it looks nice.
Tell me what hydrological diagnostic question each plot helps answer.

set.seed(1234)

if (!all(required %in% names(dat))) {
  stop("Missing required columns.")
}

ans <- tryCatch(
  run_model(par),
  error = function(e) NA
)

In what situations would tryCatch() hide a methodological problem that should actually stop the analysis?

hydroGOF::KGE(sim, obs)

help(package = "hydroGOF")
?hydroGOF::KGE

sessionInfo()

IIO409_project/
|
|-- 00_data/
|   |-- raw/
|   `-- processed/
|
|-- 01_scripts/
|   |-- 01_read_data.R
|   |-- 02_qc.R
|   |-- 03_model.R
|   |-- 04_sensitivity.R
|   |-- 05_calibration.R
|   |-- 06_verification.R
|   `-- 07_uncertainty.R
|
|-- 02_results/
|-- 03_figures/
|-- 04_docs/
|-- config.R
`-- README.md

Act as a reproducibility auditor.
I will paste the file tree and the main scripts.
Identify:
- absolute paths;
- manual steps;
- objects created outside scripts;
- parameters written in multiple places;
- undocumented dependencies;
- result files that cannot be rebuilt.

cfg <- list(
  warmup_start = as.Date("2000-01-01"),
  calibration_start = as.Date("2001-01-01"),
  calibration_end = as.Date("2010-12-31"),
  validation_start = as.Date("2011-01-01"),
  validation_end = as.Date("2020-12-31"),
  seed = 1234L
)

source("config.R")

read -> validate -> sort -> align -> convert units -> diagnose -> model

I have these columns:
date, p_mm, t_c, q_m3s.

Before modelling, create a quality-control checklist.
For each check:
- explain why it matters hydrologically;
- provide base R code;
- indicate which action should NOT be automated without inspection.

stopifnot(!anyDuplicated(dat$date))
stopifnot(!is.unsorted(dat$date))

summary(dat$p_mm)
summary(dat$t_c)
summary(dat$q_m3s)

which(dat$p_mm < 0)

which(dat$q_m3s < 0)

Do not give me the formula immediately.
Make me derive how to convert mean daily discharge [m3/s] into runoff depth [mm/day]
for a catchment with area A [km2].
Check the dimensional consistency of each step.

q_to_mm_day <- function(q_m3s, area_km2) {
  stopifnot(area_km2 > 0)

  volume_m3_day <- q_m3s * 86400
  area_m2 <- area_km2 * 1e6

  (volume_m3_day / area_m2) * 1000
}

Here is the documentation of the function we are going to use.
Do not invent arguments outside this documentation.

Explain:
1. inputs;
2. outputs;
3. the meaning of each parameter;
4. units;
5. relevant internal states;
6. three checks to perform before running it.

Write a base R wrapper to run the model and return:
- the simulation;
- metrics;
- parameters;
- the period.
Include argument validation.

Do Sobol.

I want to perform a global Sobol sensitivity analysis.

Before writing code, build with me a decision table with:
parameter, range, justification, output, sample size, seed and expected cost.

Do not choose values arbitrarily without marking them as assumptions.

Here are my first-order and total indices.
Do not interpret them immediately.
Ask me four questions to check whether I understand interaction and dominance.

objective_function <- function(par, input, obs) {
  sim <- run_model(par, input)

  if (length(sim) != length(obs)) {
    stop("sim and obs have different lengths")
  }

  score <- ...

  score
}

Review this objective function.
Do not change the code yet.

Look for:
- information leakage;
- NA values;
- length mismatches;
- max/min orientation;
- wrong period;
- warm-up dependence;
- units.

stopifnot(max(cal_dates) < min(val_dates))

Give me five programmatic tests that reduce the risk of accidentally using
validation data during calibration.

I have NSE, KGE and PBIAS for calibration and verification.
Do not classify the model yet.
Tell me what additional information I should inspect for three different aims:
1. water balance;
2. low flows;
3. flood peaks.

Do not write the whole GLUE analysis in one script.

First design the functions we need and their interfaces.
Then we will implement and test them one by one.

evaluate_par <- function(par, input, obs) {
  sim <- run_model(par, input)
  score <- ...
  c(score = score)
}

set.seed(1234)

Which problems might not appear with five simulations but could appear with 100,000?

attrs <- data.frame(
  basin = c("A", "B", "C"),
  p_mean = c(1200, 950, 1300),
  elev = c(850, 620, 910)
)

d <- dist(scale(attrs[, c("p_mean", "elev")]))
as.matrix(d)

What is the limitation of using scale() and Euclidean distance if attributes have
different distributions, relevance or collinearity?

Design a file structure and a set of functions for a workflow:
climate data -> preprocessing -> bias correction/downscaling -> hydrological model
-> indicators -> period comparison.

Do not write the code yet.
First identify which metadata must be kept to reproduce each step.

It does not work.

1. the goal;
2. the minimal code;
3. the full error message;
4. the expected result;
5. the obtained result;
6. the structure of the objects involved.

This is a minimal reproducible example.
Do not rewrite everything.

1. identify the most likely cause;
2. explain which part of the error message supports it;
3. propose the smallest possible change;
4. give me a test that verifies the fix.

The code runs without errors, but the hydrograph looks suspicious.
Give me an ordered diagnostic strategy from the simplest checks
to structural problems in the model.
Do not assume the issue is calibration.

Here is my run_model() function.
Before optimising anything, create a small set of tests.

I want to check:
- arguments;
- dimensions;
- NA handling;
- reproducibility;
- behaviour with out-of-range parameters;
- unit consistency.

Audit the reproducibility of our current project.

I will give you:
- the file tree;
- README;
- config;
- scripts.

Look for steps that only work because we know manually what to do.

Could a third person run this project from scratch?
List everything they would still have to guess.

Act as a reviewer.
For each row in this table, formulate one question that would force the team
to justify the decision with evidence or hydrological reasoning.

Here is an exercise that I have already solved.
Create a variation that changes two important conditions.
Do not only change the numbers.

I want it to force me to modify the code and reinterpret the result.

Do not give me code for the first 15 minutes.
Only answer conceptual questions and review my plan.

We have 12 results.
Our scientific message is [MESSAGE].

Help us select the four results that are strictly necessary.
For each result we exclude, explain why it is not essential.

Formulate five difficult questions that a lecturer might ask after the presentation.

Act as an oral examiner for IIO409.

I will describe our project.
Ask me individual questions about:
- decisions;
- parameters;
- sensitivity;
- calibration;
- performance;
- uncertainty;
- limitations;
- alternative scenarios.

Ask one question at a time.
If my answer is superficial, go deeper.
Do not praise me or give hints too early.

Change one decision in the project and ask what consequences I would expect.

git status
git add
git commit
git pull
git push

Explain this Git conflict.
Do not give me a resolution command yet.
First explain what happened and what information I could lose with each alternative.

1. objective;
2. data;
3. structure;
4. requirements;
5. order of execution;
6. generated outputs;
7. configurable decisions;
8. authors/contact.

Audit this README from the perspective of a person who has never seen the project.
What information is still missing to reproduce it?

Act as a scientific programmer with expertise in R and hydrological modelling.

CONTEXT
[describe data, model, units, period and objective]

TASK
[what you need to achieve]

CONSTRAINTS
- base R; no tidyverse.
- Minimal dependencies.
- Do not invent package functions or arguments.
- Reproducible code.
- Validate inputs.
- Use set.seed() if there is randomness.
- Do not hide important errors.

PROCESS
Before writing code:
1. summarise the problem;
2. identify crucial missing information;
3. propose a minimal strategy.

Then:
4. deliver the code;
5. create a small example;
6. add checks;
7. explain how to validate the result hydrologically;
8. identify possible failure modes.

Now remove the finished solution from your explanation.

Make me reconstruct this code block by block.
Ask me what each block should do before showing it.