Solar forecasting explained · 20 October 2026 · Full English version

Solar forecasting: why deploy frugal models?

The best model is not determined by forecast error alone. It must also fit the available device, respond on time and remain maintainable.

Why consider deployment from the start?

A forecast may run at a weather station, battery controller or near an inverter. These devices do not all have a GPU, ample memory or continuous cloud connectivity. The computing budget is part of the forecasting problem.

Local inference can reduce network dependence and data transfers. It still requires device security, error monitoring and model updates when operating conditions change.

Frugal does not mean simplistic

The principle is to justify additional complexity. A clearly defined persistence forecast, followed by linear autoregression, provides an informative starting point. A richer model is useful when its gains are robust and valuable relative to its cost.

An ELM uses randomly fixed hidden-layer weights and fits the output weights. It offers a way to study nonlinear forecasting with a simple fitting procedure. This does not guarantee the best forecasts everywhere or negligible memory use: fixed weights must also be stored.

What do we gain by adding capacity?

If two models both meet a control application’s requirements, a much larger memory footprint deserves justification. Conversely, a modest error improvement may be valuable if it avoids a costly decision. Model selection depends on use, not size alone.

The PV_ELM_pred repository compares persistence, BLEND, linear autoregression and ELM variants under a common protocol. A capacity sweep helps examine accuracy alongside stored parameter count.

Worked example: more model, for what gain?

Model A stores 100 parameters and has an RMSE of 100 W. Model B stores 10,000 parameters and achieves 95 W on the same observations and horizon: 100 times as many parameters for 5% lower RMSE. That may be worthwhile, but the error score alone does not settle deployment.

With float32 storage, the parameters alone occupy about 400 bytes for A and 40,000 bytes for B. Inputs, temporary arrays and software add overhead. Latency and energy cannot be inferred from these counts; measure them on the target device.

If persistence has an RMSE of 125 W, the two error ratios are 0.80 and 0.76. Both beat that reference in this example, at very different storage costs. This is a fictitious teaching example, not a ranking from the ongoing studies.

What should be measured on the device?

• Forecast quality: identical dates and horizons, an explicit baseline and stability across periods.
• Deployment: actual memory use, response time, update cost and offline behavior.
• Energy: measurements on the target hardware, distinguishing preprocessing, fitting and operation.

Where does the approach stop?

Forecasting a channel from its own history explores local short-term prediction. It does not automatically replace numerical weather prediction for day-ahead forecasting or physical models when these add useful information. Wind, load and other renewable-energy applications require their own validation.

Reducing input dimensionality and reducing model capacity are separate levers. Combining them requires evaluating the entire pipeline and the final forecast.

Open code and research in progress

The associated first-author manuscript, How Much Model Is Enough for Endogenous, Edge-Oriented Solar and Weather Forecasting?, remains unsubmitted. This page does not publish its numerical findings or rankings.

The public Python repository is the current entry point for the models, protocol and data-access conditions. The Palaiseau example is supplied; other datasets can have separate access requirements.

Explore the Python benchmarkTechnical ELM guideWhy reduce the inputs?