90-Day SMARD Backtest: Revenue Uplift From DP Dispatch, With Wear Explicitly Priced

Hydro and pumped-storage operators already know that high prices do not automatically create high margin. A turbine-hour has an opportunity cost, a water value, and a fatigue cost. A schedule that chases every attractive spread can increase gross revenue while consuming more maintenance budget than the extra revenue justifies.

That is why this case study uses the 90-day backtest as an evidence test rather than a slogan. The value proposition is to increase revenue per turbine while minimizing wear, but the only defensible way to make that claim is to show revenue, net value, and fatigue accounting side by side. The report does that, including the uncomfortable results.

The backtest window runs from 2024-10-01T00:00:00+00:00 through 2024-12-29T23:00:00+00:00: 90 days and 2,160 hourly dispatch steps. The dispatch price series is German DE-LU day-ahead power prices loaded through the SMARD.de live/cache data path, recorded in the report as price_source smard_de_api.

The report also records CH and FR price series fields as smard_de_api with 2,160 hours each. Inflow and meteo data use open_meteo for the grande_dixence catchment. The simulated baseline is intentionally simple: operate the best-efficiency turbine during the top 8 price hours per UTC day and stay in standby otherwise.

The primary optimizer in the report is stochastic_dynamic_programming. It uses an 8-hour rolling horizon, 2 price scenarios, 2 inflow scenarios, bootstrap scenario generation, and a shared maintenance_schedule fatigue cost accounting model with damage_cost_per_unit_eur set to €60,000. Terminal water value is modeled with a price_proxy over a 168-hour price window and a 0.85 round-trip-efficiency assumption.

Both optimized and baseline dispatches are executed through damagedopt.backtesting.simulator.PlantSimulator, and the validation block reports mass_balance_pass as true for the stochastic optimized run, the baseline, and the deterministic comparison run. The report also includes deterministic_vs_stochastic comparison mode, which is important because the deterministic DP solver produced the revenue-uplift signal while the stochastic configuration did not.

In the deterministic solver comparison, optimized dispatch revenue was €6,128,037.21 versus €2,196,737.29 for the baseline. That is a €3,931,299.92 gross-revenue uplift, or +178.96%, over the same 90-day SMARD window and the same top-price-hours baseline.

The same deterministic comparison reports total net value of €5,393,005.36, water-adjusted net value of €7,100,996.80, and net-value uplift of €6,199,885.11 (+688.03%) versus the baseline. This is the real uplift proof point in the artifact: dynamic programming found materially more market value than a naive top-8-hours dispatch rule.

The primary report result is less flattering and should not be hidden. The stochastic DP optimized run produced €1,820,080.39 of revenue versus €2,196,737.29 for the baseline, a €376,656.90 shortfall and -17.15% gross-revenue uplift. The headline report also shows -18.18% water-adjusted net-value uplift.

Daily consistency was weak: positive uplift appeared on 24 of 90 days, or 26.67%. The monthly breakdown was negative in October, November, and December, with revenue uplift of -€187,541.71, -€86,033.56, and -€103,081.63 respectively. This means the stochastic configuration in this artifact is not yet a production proof of uplift.

The backtest does not support a wear-reduction claim. In the deterministic comparison, total wear cost was €735,031.85 and wear cost avoided was -€728,223.58 versus baseline. In the stochastic run, total wear cost was €48,281.88 versus €6,808.27 for the baseline, so wear cost avoided was -€41,473.61. Negative wear avoided means the optimized run spent more modeled fatigue budget, not less.

That caveat matters commercially. A revenue-only optimizer can look attractive while quietly moving cost into maintenance, outage risk, or fatigue headroom. DAMagedOpt's useful contribution here is not that this particular report proves lower wear; it is that the report prices wear explicitly enough to reject an unsafe claim. The next optimization target is therefore not simply maximum revenue, but wear-adjusted uplift.

This is a SMARD-backed market replay, not a live trading audit. German DE-LU day-ahead prices were used from the SMARD data path; plant-specific bidding constraints, imbalance exposure, real outage windows, and site-specific commercial rules are not represented in the published report. The hillchart source is recorded as estimated, so plant-calibrated efficiency and fatigue curves would be required before using the absolute numbers as an operating guarantee.

The deterministic result should be treated as a strong upside signal, not a final dispatch policy, because it earned substantially more revenue while taking substantially more modeled wear. The stochastic result should be treated as a tuning signal, because it used the wear-aware configuration but did not beat the naive baseline. Together, those two facts make the case study credible: there is measurable revenue value, and the wear model prevents us from overselling it.

For hydro operators and energy trading desks, the lesson is straightforward. Dynamic programming can identify revenue that simple top-price-hours logic misses, but the schedule only deserves deployment when wear-adjusted net value improves under plant-specific constraints. That is the standard we use for uplift-based pricing: measure the incremental value, then subtract the fatigue cost of earning it.

If you want to test the same logic on a simplified case, start with the interactive demo. If you want to understand how DAMagedOpt aligns fees with measured performance rather than flat software seats, review the uplift-based pricing model.