Software companion
Cross-Domain Transfer of Upper-Ocean Heat-Content Predictors
Overview
Adding a predictor is easy; proving it is the predictor that changed the answer is not. The software here is built around one device: the auxiliary block is a distinct set of input channels, so the same trained weights can be evaluated with the ocean-heat-content input present and with it zeroed. Those two runs share architecture, pretraining budget, initialization and evaluation protocol, and differ only in whether the extra block carries information — which is what allows the resulting degradation to be stated causally rather than guessed at.
The ingestion side is the other half. Simulation heat content comes from CMIP6 potential-temperature fields and the observed side from a separate reanalysis product, so both have to be integrated over the upper ocean, regridded onto the same 24×48 grid, converted to anomalies and packed into their own 37-channel pyramid before they can sit beside the sea-surface channels. The 74-channel model is literally two stacked coefficient blocks, which is why zeroing one is a well-defined operation.
Implementation
- Predictor
- Upper-300 m ocean heat content as a second input block, giving a 74-channel SST-plus-OHC model
- Control
- A zeroed-input twin — identical weights and protocol with the OHC block set to zero — plus an equal-budget sea-surface-only model
- Budget
- Matched 30,000-step pretraining, so the comparison is not confounded by training length
- Sources
- CMIP6 potential-temperature stores for simulation, a separate reanalysis product for observed heat content
- Configuration
- Dedicated store templates and model lists for the potential-temperature stage, plus paired OHC and sea-surface-only evaluation configurations
Components
data/observed_ohc.py- Observed heat-content ingestion, depth integration, regridding and anomaly construction
data/simulation.py- Extended to build potential-temperature simulation stores alongside surface stores
data/dataset.py- Auxiliary input-channel plumbing and the paired dataset that serves both predictors
config.py- The auxiliary-block configuration surface, including the zeroing switch
pretraining/forecast_loop.py- Extended to pretrain the dual-predictor model at the same budget
scripts/prepare_observed_ohc_store.py- Observed store construction
configs/cmip6_thetao_*- Potential-temperature store templates, model lists and the resume configuration
configs/evaluate_coeff_native_ohc_*- The paired OHC and sea-surface-only evaluation configurations
Experiment design
prepare storesBuild matched simulation and observed heat-content stores on the shared grid and coefficient schema.pretrainTrain the 74-channel model on simulation at the same budget as the surface-only reference.transferFine-tune on observations under the frozen adaptation protocol.zero the blockEvaluate the same weights with the heat-content input zeroed.compareScore OHC against its zeroed twin and against the equal-budget surface-only model under the paired bootstrap.
Reproducibility and validation
- The zeroed-input twin is the control that makes the result causal: the comparison holds weights, budget, protocol and evaluation fixed and varies only whether the block carries signal.
- Simulation and observed comparisons are reported separately, because the finding is precisely that they disagree — heat content helps inside simulation and resolvably hurts through the observation pathway.
- Auxiliary-channel ingestion and the paired dataset each carry their own test modules, so a shape or alignment error cannot masquerade as a transfer result.
- Both predeclared consultations for this phase were spent and recorded; the phase was stopped and the previous model retained rather than the design being iterated until it passed.
Availability
Not publicly released. The observed heat-content product and the CMIP6 potential-temperature archive are both public but separately licensed and very large, and the prepared stores are rebuilt from the ingestion scripts rather than distributed.