Forecast three-hour solar generation from weather and solar position
This example builds a compact nonlinear surrogate for a Berkeley solar installation. Nine routinely available weather and timing variables are converted into an estimate of the energy generated during each three-hour period.
Short-horizon generation estimates can support production planning, deviation analysis and expected-versus-actual monitoring. The model is deliberately lightweight, but professional use still requires timestamped forecasting, plant availability signals, unit calibration and validation on future operating periods.
- Industrial challenge
- Data set
- Neural network
- Training
- Model selection
- Testing
- Deployment
- Limitations
- References
1. Industrial challenge
This is an approximation problem: the network maps a three-hour operating context to the generation reported by the data source.
Potential users include solar plant managers, operations and maintenance teams, performance engineers, energy forecasters, portfolio operators and industrial analytics teams.
2. Data set
The updated solar_power_generation.csv contains 2,920 records, nine inputs and one target. Each row represents a three-hour period. All input combinations are unique; one average_wind_speed value is missing and is imputed with the training statistic configured in the Neural Designer project.
| Variable | Operational meaning | Source scale / range |
|---|---|---|
distance_to_solar_noon | Absolute angular distance from solar noon | 0.0504 to 1.1414 rad |
temperature | Ambient temperature | 42 to 78 °F |
wind_direction | Coded wind-direction sector | 1 to 36; approximately ten-degree sectors |
wind_speed | Observed wind speed | 1.1 to 26.6 mph |
sky_cover | Cloud-cover category | 0 clear to 4 overcast |
visibility | Reported visibility | 0 to 10 mi |
humidity | Relative humidity | 14% to 100% |
average_wind_speed | Average wind speed over the period | 0 to 40 mph |
average_pressure | Average atmospheric pressure over the period | 29.48 to 30.53 inHg |
power_generated | Generation reported for the three-hour period | Target; 0 to 36,580 dataset units |
The scatter plot captures the expected decline away from solar noon, but also exposes a deployment issue: the unconstrained neural response can become negative and non-monotonic at the edge of the represented range. This is addressed explicitly in the deployment controls below.
The configured random split contains 1,752 training, 584 selection and 584 testing records.
3. Neural network
The baseline model standardizes the nine inputs, uses three tanh neurons in one hidden layer, and returns one continuous output through an identity activation and output unscaling.
This compact 9–3–1 architecture provides the starting point for training before the hidden-layer width is selected from held-out data.
4. Training strategy
The network minimizes normalized squared error with the quasi-Newton method. Over 104 epochs, the training error falls from 1.0056 to 0.1477 and the selection error from 0.3451 to 0.0381.
The declining curves show stable convergence for the configured random split. They do not, by themselves, demonstrate performance on a future season or a different photovoltaic installation.
5. Model selection
The growing-neurons task evaluates hidden layers from one to ten neurons. The minimum selection error occurs with nine hidden neurons, reducing the selected training and selection errors to 0.1269 and 0.0323.
6. Testing analysis
The final exported network is evaluated on the 584 testing records that were not used to fit its parameters or choose the hidden-layer size.
The model explains approximately 89.5% of testing variance, but the chart shows compression at high generation: the network tends to underpredict some of the strongest production periods. The 95th percentile absolute error is about 7,042 dataset units, which is operationally more informative than R² alone when defining alert thresholds.
7. Model deployment
A professional workflow combines forecast or SCADA inputs with schema, unit and range checks; applies the trained surrogate; enforces physical operating rules; and records the forecast, model version and later measured production for monitoring.
Representative near-noon operating case
This observed row from the dataset matches the reference point used in the regenerated directional-output analysis. It provides reproducible values for testing the downloaded Python model or the browser calculator.
| Input | Value |
|---|---|
| Distance to solar noon | 0.16623 rad |
| Temperature | 62 °F |
| Wind direction code | 29 |
| Wind speed | 14.9 mph |
| Sky cover | 1 — low cloud |
| Visibility | 10 mi |
| Relative humidity | 68% |
| Average wind speed | 14 mph |
| Average pressure | 29.77 inHg |
| Result | Dataset units / 3 h |
|---|---|
| Observed generation | 24,553 |
| Model prediction | 22,254.3 |
| Prediction error | -2,298.7 (-9.4%) |
Interpretation: the model estimates 22,254.3 units, around 9.4% below the observed value. For a plant manager, this single estimate is not an alarm threshold; it is a reproducible baseline that can be combined with an error band and later compared with the meter reading to identify sustained underperformance.
Distance-to-solar-noon scenario analysis
Holding the remaining reference inputs fixed, the directional-output task shows the estimated production profile as the operating period moves away from solar noon.
The central decline is operationally intuitive; the negative and upward-turning tail is not. Treat it as evidence that the unconstrained surrogate should not be extrapolated into a physical production curve without daylight logic, non-negative bounds and validation against timestamped plant data.
Try the three-hour generation model
Use one of the representative operating points or enter values inside the ranges represented by the data. The calculation runs locally in the browser with the same weights and scaling as the exported Python model. Inputs outside the training range trigger a warning; this is not a certified forecasting, dispatch or settlement tool.
Dataset generation units per three-hour period. Demonstration model, not a dispatch or revenue-settlement system.
Integrate the exported model
The deployment package contains the exact Neural Designer Python export and a README with the input order, example call and production safeguards.
from model import NeuralNetwork
model = NeuralNetwork()
generation = model.calculate_outputs(
[0.166230366, 62, 29, 14.9, 1, 10, 68, 14, 29.77]
)[0]8. Scope and limitations
- The data represents one Berkeley solar installation and does not establish transfer to another technology, orientation, capacity, soiling regime or climate.
- The random 60/20/20 row split can mix neighbouring periods across subsets. Operational validation should reserve later dates and complete seasons to test genuine forecasting performance.
- About 45.2% of target values are zero. A two-stage daylight/availability classifier followed by a positive-generation regressor may model this structure more naturally.
- Direct irradiance, module temperature, installed capacity, inverter status, curtailment, outages, cleaning and shading are absent; these can explain production changes that weather proxies cannot.
- The public data does not document sufficient meter calibration and plant metadata to convert the target into a defensible engineering energy unit.
- The current network can return negative values and compresses the highest outputs. Physical bounds and stronger high-generation validation are required.
- Forecasting use must evaluate forecast weather rather than observed weather and compare against simple persistence and clear-sky baselines.
- Maintenance alerts should require sustained, statistically significant measured-versus-expected deviations, not a single model residual.
References
- BigML. Predicting solar power energy generation: origin and context of the Berkeley installation data.
- Neural Designer testing analysis: goodness-of-fit and error interpretation.
- Neural Designer model deployment: output calculation and Python export.
