Denmark’s energy infrastructure is controlled by a centralized authority known as Energinet. Energinet makes a lot of rules and regulations, and I recently ran into a problem with rooftop solar installation regulations.
The below diagram from Energinet shows a recommended installation configuration for rooftop solar of size < 50kW peak:

Sorry about the Danish diagram, but the important thing is that there are two metering points, M2 and M3 (M1 is crossed out). The M2 metering point reports how much electricity is delivered to the grid and the M3 metering point reports how much electricity is consumed from the grid. With this configuration, it is not possible to know how much electricity is produced by the rooftop solar panels (Egetforbrug til elproduktion). Any amount of electricity from the rooftop solar installation could be consumed before the remainder is delivered to the grid through M2.
Most rooftop solar installations include a production reporting solution integrated with the inverter:

But the data coming out of these smart inverters is not standardized or open. Businesses with multiple sites may struggle to create a coherent picture of their rooftop production. This problem becomes especially thorny if different vendors’ smart inverters are installed at different sites owned by the same business.
Businesses need a cohesive picture of their rooftop production. If they cannot get this picture from the grid operator and they cannot get this picture from their rooftop solar installation partner, then where can they get it? Maybe we can estimate it using public data with a reasonable level of accuracy?
If we are going to try and estimate rooftop solar production we need some data to test on. This kind of data is a bit hard to come by and I had to settle on using solar production data provided by the City of Las Vegas. The dataset has monthly solar production broken down by site since 2014. Many of the sites are confusingly named and it isn’t always clear which solar panels are associated with which site. I decided to simplify the problem by focusing on the 12 fire stations because they have clear site boundaries and their panels are easy to count.

These fire stations have solar over their parking instead of on their roof. But the principles of solar production estimation should still be similar. I used NREL’s PVWatts to estimate each fire station’s solar production with the following parameters:
| PVWatts Parameter Name | Parameter Value | Explanation |
| Module Type | Standard | The panels don’t look like “Premium” or “Thin Film” |
| Angle | 10° | Based on this page |
| Capacity | Number of Panels * 250kW per panel | The number of panels were counted using Google Maps satellite images. The kW per panel is estimated based on the typical panel range (250kW-400kW) and the fact that the panels were installed in 2014. |
| Azimuth | 180° | Standard for the northern hemisphere |
| Array Type | Fixed roof-mounted | Roof-mounted should be similar to over-parking installations |
| Losses | 14% | An example value taken from PVWatts documentation |
| Latitude and Longitude | 36.17°, 115.139° | All fire stations are in Las Vegas, so they should all have similar weather trends |
When I compare the estimated production to the actual production, this is what I get:
| Average | 95th Percentile | |
| Absolute Monthly Production Error | 19.6% | 41.3% |
| Absolute Yearly Production Error | 13.1% | 29.3% |
This is really good performance considering the number of simplifying assumptions made. The 95th percentile error is much lower than I expected (I would have guessed > 100% error). I wish I had a larger dataset to make a stronger statistical case, but the dataset I used has a good variety of configurations for its size.
This estimation technique works fine if you need a general idea of the production per year of a solar rooftop installation. Just review the parameters for your situation, count the panels using Google Maps, and be realistic about the accuracy! If you are interested, check out my code and dataset on GitHub.
Leave a Reply