Document Prediction Accuracy Expectations (maybe crowdsourced)?

[symbioquine]

I feel like it would be useful for this library to include some sort of more nuanced qualifiers in the documentation about under what scenarios it is likely to be accurate and for what kind of predictions.

In other words, as a potential consumer of the library, it would be useful to know if it will be helpful for:

• Predicting daily total kWh generated numbers - perhaps for off-grid power budgeting / timing generator use
• Predicting several hours ahead for peak load shedding - e.g. when to run big loads like resistive heating, car charging, etc
• Regions other than the UK
• Sites with unusual geographic / weather features - seasonal/daily mountain/tree shadows, rain-shadow effects, lake/coastal morning fog, etc

This is maybe similar to #27 but I didn't want to complicate that issue. Basically, I'm thinking it might be good to aggregate a bunch of real-world examples and compare the model output against the real-world data to demonstrate how accurate/inaccurate the model can be in different circumstances and summarize some sort of guidance about when it can be expected to be useful - perhaps compared to a naive benchmark i.e. average daily output of tool like https://re.jrc.ec.europa.eu/pvg_tools/en/#api_5.3

I'm thinking about this because I'm comparing these models to my actual PV output for my own purposes and hoping one will be a good fit, but it feels a bit random so far - based on only a few days data.

[sid200727]

Thanks for raising this, I agree that clearer guidance around expected prediction accuracy would be very helpful for users.

I’d like to propose the following approach:

1. Add a new section in the documentation titled “Prediction Accuracy & Expected Use Cases”
2. Include:
   • Summary of typical error metrics (MAE / RMSE / MAPE if available)
   • Guidance on daily kWh accuracy vs intra-day accuracy
   • Discussion of performance in:
   • UK vs non-UK regions
   • Sites with complex terrain or shadowing
   • Comparison against a simple baseline (e.g. naive persistence or average daily output)
3. Optionally include a small evaluation example using real historical data.

Would this align with the maintainers’ expectations for this issue?