Tamil Nadu's grid operators must commit to generation schedules and day-ahead power purchases without knowing exactly what tomorrow's peak demand will be; under-forecasting forces expensive last-minute market purchases, while over-forecasting wastes contracted capacity. Published forecasting studies for Indian states rarely allow their claims to be checked: they use private or unshared data, evaluate with random train–test splits that leak future information into training, and seldom compare against a proper statistical baseline. There is no widely available, leakage-free, state-level evidence on how far ahead daily peak demand in Tamil Nadu can realistically be forecast and on whether machine-learning models genuinely outperform a well-specified SARIMA once evaluation is done honestly. This dissertation fills that gap with an openly licensed 11-year daily series, a pre-specified walk-forward protocol, and a failure-day analysis that tells operators when the models break, not just how often on average.
Abstract
State load dispatch centres must plan generation and day-ahead procurement against a demand they can only estimate. For Tamil Nadu — a state whose daily peak swings with monsoon temperatures, agricultural pumping and industrial load — even a small improvement in forecast accuracy translates into better procurement decisions and fewer emergency purchases. This dissertation develops daily peak-demand forecasting models for Tamil Nadu from an open, per-state dataset derived from Grid-India daily reports (2014–2024) and tests whether gradient boosting beats classical SARIMA at 1-, 7- and 14-day horizons under a walk-forward evaluation protocol.
Introduction
Electricity demand is one of the most studied forecasting problems in the time-series literature, yet state-level studies for India remain thin; most published Indian work uses either national series or single-city smart-meter data. Meanwhile, Grid-India has published daily state-wise supply statistics for over a decade, and a curated, quality-controlled version of those reports — including paired meteorological variables — is now openly licensed. That combination makes a reproducible state-level forecasting study possible for a master's student without access to utility SCADA systems.
Existing system / literature gap
Utility-grade short-term load forecasting research is dominated by (a) statistical models — ARIMA and its seasonal variants, exponential smoothing, and regression with weather terms — and (b) machine-learning models — random forests, gradient boosting and neural networks. Published comparisons disagree: ML models win on large, weather-sensitive series, while SARIMA remains competitive when the history is short or the evaluation is careless (random train–test splits that leak information). Indian state-level studies frequently suffer from exactly that flaw, and rarely release their data or code, so their claims cannot be checked. The gap this project fills: a documented, leakage-free, rolling-origin comparison on a public Tamil Nadu series, with the failure days analysed rather than hidden in an average error score.
Proposed study
- Data: the Zenodo dataset's
Tamil_Nadu.csv — daily energy met (MU), peak met (MW), peak unmet (MW), and daily temperature, solar radiation and cloud cover, 2014–2024 — plus a calendar of Tamil Nadu public holidays.
- Models: seasonal-naive baseline; SARIMA with weekly and annual seasonality; random forest and gradient boosting (XGBoost) with lag, rolling-mean, holiday and weather features.
- Evaluation: rolling-origin walk-forward backtesting (retrain windows expanding yearly), 1-, 7- and 14-day horizons, scored with MAPE, RMSE and skill score against the seasonal-naive baseline, with error decomposition for the worst 20 forecast days.
- Deliverables: reproducible Jupyter/R Markdown notebooks, a results chapter with forecast-versus-actual plots, an error taxonomy (heat-wave days, monsoon transitions, holidays), and the dissertation report for the viva-voce.
Feasibility
- Technical: the dataset is a few megabytes of CSV; all models run on a standard laptop using statsmodels and scikit-learn/XGBoost. Nothing needs a GPU or a paid API.
- Economic: zero cost — the data is CC BY 4.0 licensed and every software component is open source.
- Operational: the study is self-contained secondary-data research; the only risk is minor gaps in the scraped series, which the quality-control work-package handles and documents.
Research design: quantitative, comparative time-series study with a pre-specified evaluation protocol (rolling-origin walk-forward backtesting). There is no human participant involvement, so no ethics clearance is required; the dataset is used under its CC BY 4.0 licence with attribution.
| Phase | Weeks | Activities | Output |
|---|
| 1. Literature review & proposal | 1–3 | Survey load-forecasting literature (statistical and ML), finalise research questions and protocol | Synopsis and proposal presentation |
| 2. Data acquisition & QC | 4–6 | Download Zenodo Tamil_Nadu.csv; audit missing/duplicate days; cross-check sampled months against Grid-India daily reports; build holiday calendar | Clean analysis table + QC log |
| 3. Exploratory analysis | 7–8 | STL decomposition, ACF/PACF, distribution of peaks by month and weekday, 2020-lockdown structural break | EDA notebook + figures |
| 4. Baselines & SARIMA | 9–11 | Seasonal-naive; SARIMA order identification and residual diagnostics | Baseline scores |
| 5. ML models | 12–14 | Feature engineering; random forest and XGBoost with time-series cross-validation for tuning | Tuned models + feature importance |
| 6. Walk-forward evaluation | 15–17 | Rolling-origin backtest at 1/7/14-day horizons; MAPE/RMSE/skill-score tables; failure-day taxonomy | Results chapter draft |
| 7. Writing & viva prep | 18–22 | Dissertation writing, reproducibility pass (rerun notebooks end-to-end), PPT and mock viva | Final submission |
Instruments and analysis plan: Python (pandas, statsmodels, scikit-learn, XGBoost) in Jupyter notebooks with fixed random seeds; model comparison via a single scoring script so no result is computed twice differently. Sampling is a complete census of available days (~4,000), not a sample; every gap is documented rather than silently interpolated.