raman0330/weather-load-analyzer

Purpose and deployment shape

This repository is an electricity-load forecasting and decision-support system, centered on Haryana/Punjab forecasting, weather effects, accuracy correction, scenario simulation, and backtesting. It ships a React frontend plus two Python API surfaces: a forecasting service and a Django application. Container orchestration and reverse-proxy configuration are present in docker-compose.yml, Dockerfile.fastapi, Dockerfile.django, Dockerfile.frontend, and nginx.conf.

Entry points and application surfaces

• Forecasting/API service entry candidates: api.py, backend/main.py, and backend/run.py.

• Django service entry point: django_api/manage.py, with project routing in django_api/django_api/urls.py.

• Browser client entry: frontend/src/main.jsx, which initializes routing/providers around frontend/src/App.jsx.

• The frontend’s backend endpoint configuration is isolated in frontend/src/apiConfig.ts and frontend/src/lib/api.ts.

Forecasting engine and model artifacts

The main forecasting boundary is the Python backend. backend/engine.py, backend/gridintel_engine.py, and backend/hybrid_ai_engine.py appear to provide alternative or composed forecast engines; model structure is in backend/hybrid_ai_model.py. Region-specific learned assets are versioned locally under backend/artifacts/haryana/model.weights.h5, backend/artifacts/haryana/scalers.pkl, and backend/artifacts/punjab/model.weights.h5. This makes artifact loading and region selection a core runtime dependency rather than a remote model-serving boundary.

Short-term forecast pipeline and weather/load integration

backend/short_term_pipeline.py is the likely orchestration stage for operational forecasts, exposed through backend/pipeline_router.py. Weather and load processing are separated into weatherData.py, loadProcessor.py, weather_load_processor.py, and weatherloadIntegrator.py. The primary flow is weather/load inputs → feature preparation/integration → hybrid or grid-intelligence model inference → forecast payloads for API consumers.

Forecast-quality and operational correction layer

Post-model forecast adjustment is a distinct architecture layer under backend/accuracy/: backend/accuracy/calibration_layer.py, backend/accuracy/bias_correction.py, and backend/accuracy/sldc_validator.py. Additional specialized handling includes backend/accuracy/ramp_weather.py and backend/weather_anomaly.py. This boundary likely applies calibration, bias/ramp corrections, anomaly handling, and validation before results are surfaced or evaluated.

Evaluation, reporting, and scenario workflows

Offline evaluation is represented by backend/backtester.py, backend/backtest_may_jun_2025.py, and persisted reports such as reports/backtest_may_jun_2025.xlsx. Haryana-focused RCA/monsoon analysis is produced from scripts and report assets including scripts/run_report.py, reports/haryana_monsoon_report.html, and exports/Haryana_RCA_OPEN_THIS.xlsx. Scenario state is persisted locally in exports/scenarios_store.json; the frontend simulator consumes its own scenario/data services in frontend/src/features/simulator/scenarioService.ts and frontend/src/features/simulator/simulatorDataService.ts.

Frontend product domains and identity boundary

The Vite/React frontend organizes user workflows by feature: forecast presentation in frontend/src/features/forecast/ForecastPage.tsx, monitoring in frontend/src/features/monitor/AccuracyMonitorPage.jsx, backtesting in frontend/src/features/backtest/BacktestPage.jsx, and scenario simulation in frontend/src/features/simulator/SimulatorPage.tsx. Authentication is gated client-side by frontend/src/app/AuthGate.tsx, while Django owns account models/routes in django_api/accounts/models.py and django_api/accounts/urls.py. The repository does not identify third-party weather, identity, or database services; these integrations should be confirmed from environment variables and runtime code.