MSTWeatherGen

From observations to stochastic realizations

The Python server calls the official MSTWeatherGen R package inside Docker. The scientific algorithms are not approximated in Python. This application pins upstream revision 08f525e, package version 1.0.1.9999, so rebuilds use a known scientific code base.

1. Check that the engine badge says R engine available.
2. Load the SAFRAN example extracted from the official package during Docker build, or the synthetic software-test dataset.
3. Select years, variables and calibration options. Keep Guarded seasonal for normal use.
4. Click Fit and save model. Each season is validated before the next one begins.
5. Select a completed calibration, choose dates and seeds, then click Generate.
6. Inspect the diagnostics and download CSV or the experiment ZIP.

Generated series are stochastic weather sequences calibrated on historical data. They are not weather forecasts and do not become climate-change scenarios merely by choosing future calendar dates.

Long format: one row per date and site

date,site_id,longitude,latitude,Precipitation,Wind,Temp_max
2016-01-01,S01,4.80,44.10,0.0,3.2,8.4
2016-01-01,S02,4.95,44.10,1.4,4.1,7.9

Use ISO dates YYYY-MM-DD, stable site identifiers and WGS84 longitude/latitude in degrees. UTF-8 is required. Comma and semicolon delimiters are accepted; semicolon files may use decimal commas.

Coordinates may instead be placed in a separate stations.csv containing site_id,longitude,latitude. The observations file then contains date,site_id plus weather variables.

Rainfall must be named exactly Precipitation to activate the upstream precipitation treatment. No imputation or unit conversion is performed.

Two estimation modes in v1.1.1

Guarded seasonal - recommended

DJF is estimated and numerically inspected immediately. Only if it passes does the application continue with MAM, then JJA and SON. This prevents a bad winter fit from wasting time on the remaining seasons.

Official native all-seasons call

This mode calls the upstream multi-season estimator once with all four meteorological seasons. It is provided as a comparison tool: if guarded seasonal fails but native succeeds, the adapter orchestration deserves investigation; if both fail on the same season, the instability is much more likely to come from the data/model estimation itself.

Annual models use a single guarded estimation. Calibration parameters tmax, n1, n2, optimizer iterations and the random seed are stored with the job.

Test one season before refitting everything

Open Scientific parameters & troubleshooting, choose DJF, MAM, JJA or SON, then click Test selected season only. This run does not create model.rds and cannot be used for simulation.

For every evaluated season, v1.1.1 writes season_SEASON_diagnostic.json. The report includes:

• exact paths of non-finite covariance parameters;
• invalid marginal-regression coefficient paths;
• number and frequency of weather types;
• per site/variable sample size, number of unique values, mean, standard deviation, range, zero fraction, wet-day count and near-constant flag;
• matrix dimensions, finiteness, symmetry error, minimum eigenvalue and approximate condition number where available;
• warnings emitted by the upstream engine.

The application does not replace NaN/Inf by zero and does not silently force a failed fit into simulation. A numerical repair that changes the model must be explicit and scientifically assessed.

Reuse a validated complete calibration

A season-only diagnostic is intentionally absent from the saved-model list. Complete calibrations can generate 1 to 30 realizations. Realization i uses seed + i - 1. Full calendar years are simulated internally before the requested dates are cropped, preserving leap days and avoiding very short seasonal blocks.

The application rejects output with missing rows, duplicate date/site pairs, invalid weather types or non-finite simulated values. It reports physically unusual values such as negative wind/radiation or Temp_min > Temp_max as warnings rather than silently modifying them.

Inspect distribution and dependence, not same-day prediction error

The interface provides daily series, monthly means, empirical distributions, quantile comparisons, site statistics, lags 1-20 autocorrelation, spatial correlations and cross-variable correlations. These are descriptive in-calibration diagnostics unless you explicitly construct an out-of-sample validation workflow.

Exports keep the scientific context

The experiment ZIP contains available simulations, exact normalized calibration inputs, parameters, logs, session information, model files for complete fits, seasonal numerical diagnostic JSON files, bundled adapter source and software provenance. Exports read saved outputs; they do not regenerate a realization.

What v1.1.1 changes - and what it does not

v1.1.1 makes failures earlier and much more interpretable, but it does not claim to cure a statistically ill-conditioned covariance fit. It also separates the heavy R installation layer from the lighter worker validation layer so Docker rebuilds are much faster after UI or adapter changes. A DJF failure in both guarded and native modes should be investigated through the season report, the weather-type support and the input series before changing the statistical model.

For Windows, keep Docker Desktop in Linux-container mode. The host does not need R or Python.