Short-Term Electricity Demand Forecasting for Karnataka: A Walk-Forward Model Comparison Study

KDFF (Karnataka Day-Ahead Demand Forecaster) is a research study that builds and rigorously compares day-ahead electricity-demand forecasting models for the Karnataka grid, using only open, official data published by the Grid Controller of India (Grid-India) and the NITI Aayog India Climate & Energy Dashboard (ICED).

Karnataka's power system has changed fast: peak demand crossed 17,000 MW in FY 2024-25 and keeps setting records, while a rapidly growing solar fleet reshapes the evening "net load" ramp. Distribution companies such as BESCOM must schedule generation and day-ahead-market purchases one day in advance, so forecast error converts directly into deviation-settlement charges and costly last-minute purchases.

The study frames three research questions and answers them with a proper evaluation protocol rather than a single train/test split: (1) how much a feature-based machine-learning model improves on seasonal-naive and SARIMAX baselines at the 24-hour horizon; (2) whether temperature data earns its place in the feature set; (3) where forecasts fail — summer heat waves, festival days — and what that means for discom scheduling.

Models include seasonal-naive, SARIMAX, random forest and histogram gradient boosting, evaluated with rolling-origin (walk-forward) validation, MAPE/RMSE/sMAPE and Diebold–Mariano significance tests. The deliverable is a paper-style study: a clean dataset, a reproducible pipeline, results tables with confidence in the comparison, residual diagnostics and a viva-ready analysis.

Karnataka's discoms and load dispatch centres plan day-ahead power procurement without a rigorous, locally validated demand-forecasting model: scheduling relies on last year's curves and manual heuristics, while published forecasting research rarely transfers to an Indian state-level, open dataset and often reports results from a single arbitrary train/test split that overstates accuracy. There is no public, reproducible study that (a) builds a clean hourly demand dataset for Karnataka from official Grid-India sources, (b) compares classical statistical and machine-learning models under a rolling-origin protocol that mimics real day-ahead operation, and (c) tests whether observed differences between models are statistically significant rather than artefacts of one split. This dissertation fills that gap with an auditable pipeline, a pre-declared evaluation protocol, significance-tested model comparisons and an error analysis focused on the periods that matter operationally — summer peaks and festival days.

Abstract

This dissertation compares statistical and machine-learning models for day-ahead (24-hour-ahead) forecasting of electricity demand in the Indian state of Karnataka. An hourly demand series for the state is assembled from official Grid-India publications and the NITI Aayog ICED dashboard, cleaned into a reliable dataset, and used to evaluate five forecasting approaches under a rolling-origin (walk-forward) protocol. Gradient-boosted trees with calendar, lag and temperature features beat the strongest statistical baseline by a clear, statistically significant margin; the study quantifies the gain, locates the residual failures and releases the full pipeline.

Introduction

Every morning, Karnataka's load dispatch centres and discoms must commit to tomorrow's power: how much to schedule from central generating stations, what to buy on the day-ahead market, and where solar and wind output will land against demand. Demand met has grown to record peaks above 17,000 MW; planning mistakes are expensive in both directions — under-commitment forces costly real-time purchases, over-commitment wastes capacity. A trustworthy day-ahead demand forecast is therefore a working tool, not an academic exercise.

Existing system and literature gap

Published short-term load forecasting research is dominated by single-country or US/European datasets, and much of the Indian work either uses small private datasets or reports one favourable train/test split, which flatters complex models. Industry practice at discoms still leans on spread-sheet heuristics and last-year curves. What is missing — and what this study provides — is a head-to-head, statistically tested comparison on a fully open, auditable Indian state-level dataset, with the evaluation protocol (rolling origin, refit policy, metrics, significance tests) fixed before results are produced, in the spirit of research-methodology practice taught in 22RMI16.

Proposed work

• Assemble an hourly Karnataka demand series from Grid-India daily reports / ICED exports; document every cleaning decision (missing hours, load-shedding days, lockdown period flags).
• Engineer calendar features (hour, day-of-week, festival calendar), lag features, rolling statistics and optional daily maximum temperature.
• Implement seasonal-naive and weekly-naive baselines, SARIMAX with daily seasonality, random forest and histogram gradient boosting; keep an optional sequence model as a stretch goal.
• Evaluate all models with an expanding-window walk-forward loop that mimics real day-ahead operation, reporting MAPE, RMSE and sMAPE per fold, aggregate mean ± standard deviation, Diebold–Mariano tests for pairwise differences, and an ablation without weather features.
• Analyse residual structure (ACF, Ljung–Box) and error concentration across seasons and festival days.

Feasibility

• Technical: the entire pipeline runs on a 16 GB laptop; statsmodels and scikit-learn cover every model; hourly data for two to three years is a few million rows at most, comfortably handled by pandas with an SQLite cache.
• Data: demand data are official and free (Grid-India daily reports, ICED); temperature comes from public weather archives — no paid data is required.
• Economic: zero licence cost; compute is a personal laptop.
• Operational (research): the protocol is fully scripted, so every number in the report regenerates with two commands — the audit trail examiners ask for.

In scope

• State-level hourly demand met for Karnataka, 2–3 years up to the most recent complete month; 24-hour-ahead (day-ahead) horizon.
• Models: seasonal-naive, weekly-naive, SARIMAX (daily seasonality), random forest, histogram gradient boosting; one sequence model (e.g. a small recurrent network) only as an optional stretch goal.
• Features: calendar/festival, lags and rolling statistics, daily maximum temperature for Bengaluru (ablation-tested).
• Evaluation: expanding-window walk-forward with daily refit policy options, MAPE/RMSE/sMAPE, Diebold–Mariano tests, residual diagnostics.

Out of scope

• Circle- or substation-level (discom-internal) data — only state-aggregate public data is used.
• Probabilistic/quantile forecasting and multi-day horizons beyond day-ahead.
• Live production deployment inside a discom; the study stops at validated models and a deployment discussion.
• Weather-model output (numerical weather prediction pipelines); a single observed-temperature feature suffices for the ablation.

The work follows a quantitative, comparative-experimental research design executed in the incremental phases expected of an M.Tech dissertation, with the evaluation protocol frozen before the first model is scored (a deliberate 22RMI16 discipline to avoid unconscious protocol-fitting).

Validation inside the study: unit tests for feature functions and metric implementations, a holdout period excluded from all development until the final run, and a reproducibility check (re-running the pipeline from raw downloads must reproduce the results tables bit-for-bit up to library-version notes).

The pipeline is a linear, fully scripted research workflow with an explicit cache, so that expensive steps are never silently repeated and every intermediate artefact is inspectable.

flowchart TD
  A["Grid-India daily reports + ICED exports"] --> B["Ingest and parse<br/>raw hourly demand"]
  W["Public temperature archive"] --> B
  B --> C["Cleaning and flags<br/>missing hours, load-shedding, lockdown"]
  C --> D[("SQLite cache:<br/>verified hourly series")]
  D --> E["Feature builder<br/>calendar, lags, rolling, temperature"]
  E --> F["Model zoo<br/>naive, SARIMAX, RF, HistGB"]
  F --> G["Walk-forward harness<br/>expanding window, 24 h horizon"]
  G --> H["Metrics: MAPE, RMSE, sMAPE"]
  G --> I["Diebold-Mariano tests"]
  H --> J["Results tables and diagnostics<br/>plots, ACF, seasonal breakdown"]
  I --> J

Three design decisions matter for the viva. First, the dataset cache is versioned: the cleaning script writes the series and its flags to SQLite, and every later stage reads only that artefact, so a cleaning bug cannot silently leak into already-published tables. Second, the walk-forward harness owns all model scoring — models never see a metric computed outside the harness — which makes protocol tampering structurally impossible and lets the pre-declared protocol be quoted verbatim in the dissertation. Third, the analysis layer separates point forecasts (metrics), model comparison (Diebold–Mariano tests on the paired daily forecast errors) and diagnostics (residual ACF and seasonal error breakdowns), mirroring the structure of the results chapter: one table per question, each reproducible by a single script.

The harness itself is small but strict: for each evaluation day it trains on all history strictly before that day (expanding window), forecasts the next 24 hours, stores the paired errors of every model, and rolls forward one day. Refit frequency (daily for statistical models, weekly for tree ensembles) is a recorded configuration, not an ad-hoc choice.

• Extend to probabilistic day-ahead forecasts (quantile regression / conformal intervals) so discoms can plan reserve margins, not just point demand.
• Add circle/discom-level disaggregation and net-load forecasting as solar penetration grows.
• Online learning: models that refit themselves nightly inside a discom's data feed, with drift monitoring.
• Replicate the full study for two more states to test whether the model ranking transfers across climates and load mixes.