PVGIS vs PVWatts for UK Roofs: Which Baseline to Trust

You run the same roof through both tools and get two answers 400 kWh apart. Neither is broken. They are built on different weather data, they book losses in different places, and only one of them knows there is a hill to your south. Once you understand which is which, the gap stops being noise and starts being information.

This page is about picking a primary baseline for a UK roof and using the other tool properly. For the wider question of how any model turns irradiance into kilowatt-hours, and where the rest of the uncertainty sits, the overview at Forecasting What Your Roof Will Actually Generate is the place to start.

Start with the answer

For a UK roof, PVGIS with the SARAH3 database should be your primary baseline. PVWatts should be your cross-check on tilt and orientation sensitivity, not your second absolute number.

The reason is dull and decisive: spatial resolution of the underlying weather data. PVGIS (run by the European Commission’s Joint Research Centre) serves the UK from a satellite-derived dataset on roughly a 5 km grid, averaged over 2005 to 2023. PVWatts (NREL) has no gridded dataset covering Britain. Outside the Americas it snaps your coordinates to the nearest station in a set of international typical-year files, and for the whole of the UK that set contains roughly twenty-odd stations, most of them airports, most of them built from hourly observations recorded between 1982 and 1999.

There is one case where the answer flips. If you are modelling a system in the US, or you specifically want NREL’s transparent, itemised loss stack as a teaching tool, PVWatts is the better instrument. For a semi-detached in Stockport, it is working from data collected before the roof was probably even considered.

Check which station PVWatts actually gave you

Most people never look. The PVWatts JSON response carries a station_info object, and it tells you exactly how much to trust the result:

GET https://developer.nrel.gov/api/pvwatts/v8.json
  ?api_key=YOUR_KEY&lat=53.38&lon=-1.47
  &system_capacity=4.4&tilt=35&azimuth=180
  &array_type=1&module_type=0&losses=14&timeframe=monthly

"station_info": {
  "lat": 53.48,
  "lon": -1.00,
  "city": "FINNINGLEY",
  "state": null,
  "country": "GBR",
  "distance": 32000,
  "weather_data_source": "INTL"
}

That distance is in metres. A Sheffield roof is being modelled on data from a former airfield 32 km east, at different altitude, with a different cloud regime. Move the pin to Kendal or Bangor or Inverness and the distance can pass 80 km. Two roofs an hour’s drive apart frequently receive byte-identical weather, which means PVWatts cannot resolve the thing UK homeowners most want resolved: whether their specific bit of the country is sunnier than the next valley.

PVGIS will tell you which dataset and grid cell it used too. Add &outputformat=json and read inputs.meteo_data: you want PVGIS-SARAH3 for mainland Britain. If it hands you PVGIS-ERA5, you are outside the satellite footprint or you asked for it explicitly; ERA5 is reanalysis on a much coarser grid, and for anywhere south of Shetland you should not be using it.

The loss stacks are not comparable at face value

Both tools default to “14% losses”. They mean different things by it, and this single misunderstanding accounts for a large share of the gaps people report.

PVGIS applies its loss parameter (default 14%) to cover cabling, mismatch, soiling, and inverter conversion, all in one number. Temperature, low-light behaviour, spectral effects and angular reflection are handled separately inside its crystalline-silicon performance model, so they are not in that 14%.

PVWatts v8 splits it. Its losses parameter (default 14.08%) is a DC-side stack: soiling 2%, shading 3%, snow 0%, mismatch 2%, wiring 2%, connections 0.5%, light-induced degradation 1.5%, nameplate rating 1%, availability 3%. Inverter efficiency is a separate parameter, inv_eff, defaulting to 96%.

Do the arithmetic and the mismatch is obvious:

That is a 4.1% difference in bookkeeping alone, before either tool has looked at the sky. To align them, set PVWatts losses=10.4 while leaving inv_eff=96, which gives 0.896 × 0.96 = 0.860. Now you are comparing weather data and module models instead of comparing accounting conventions.

Two more settings to match while you are in there. PVGIS defaults to mountingplace=free, meaning a free-standing array with air on both sides; for a roof you want mountingplace=building. PVWatts’ equivalent is array_type=1 (fixed roof mount) rather than array_type=0 (open rack). In Spain this choice is worth 2% or more. In the UK, where annual temperature losses on a domestic roof run closer to 2–4% than 8%, it is worth about 1%, but it is free to get right.

And watch the azimuth conventions, because getting this wrong silently swaps east for west. PVGIS aspect is measured from south: 0 is due south, −90 is east, +90 is west. PVWatts azimuth is measured from north: 180 is due south, 90 is east, 270 is west. A roof facing 20° west of south is aspect=20 in PVGIS and azimuth=200 in PVWatts.

Worked example: one Bristol roof, four numbers

Take a 4.4 kWp array (11 × 400 W panels) in south Bristol, 30° pitch, facing 20° west of south, no significant near shading. Same roof, four baselines:

The owner’s inverter logged 4,050 kWh over its first twelve months. So PVGIS ran about 3% high against that year, realigned PVWatts about 4% low, and the quote was conservative by roughly 9%. Your own run will produce different figures; the arithmetic is the transferable part.

The interesting question is why PVWatts sits low even after the loss stacks are aligned. Bristol’s nearest international station file is Boscombe Down, about 80 km southeast, but distance is probably the smaller factor. Northwest Europe has brightened measurably since the 1980s as sulphate aerosol loading fell, on the order of a few per cent per decade through the 1990s and 2000s. A typical year assembled from 1982–1999 observations is therefore describing a dimmer country than the one your panels are installed in. PVGIS’s 2005–2023 satellite average is describing the current one.

Keep that in mind when an installer’s number comes in low. MCS figures and PVWatts defaults both tend conservative for UK sites, and conservative is not the same as accurate when you are deciding whether to spend £9,000.

Horizon is the thing PVGIS does that PVWatts cannot

Add &usehorizon=1 to a PVGIS call and it applies a terrain horizon derived from SRTM elevation data at roughly 90 m resolution. For a flat site in Cambridgeshire this changes nothing. For a house in a Welsh valley, on the north side of a Pennine ridge, or anywhere in a Scottish glen, turning it on can cut the annual figure by 3% to 8%, and almost all of that loss lands between November and February when the sun never climbs above the ridge line. PVWatts has no terrain model for international sites at all. Its only shading input is a flat 3% inside the loss stack.

Better still, PVGIS lets you supply your own horizon. The userhorizon parameter takes a comma-separated list of horizon elevation angles in degrees, starting due north and stepping clockwise at even intervals:

&userhorizon=8,9,12,14,11,7,4,3,3,4,6,9,14,18,21,19,15,11,9,8,7,7,8,8

Twenty-four values means one every 15°. Measure them with a clinometer app (Theodolite, Sun Surveyor, Solar Compass) standing on the roof or at an upstairs window, and you have replaced a guessed shading percentage with a measurement. This is the single highest-value thing an intermediate analyst can do to a PVGIS run, and there is no PVWatts equivalent.

Terrain does not include the neighbour’s chimney or the sycamore at the end of the garden. Near shading needs a proper shade calculator or an hour with a fisheye photo, and it is the largest remaining source of error on most real UK roofs.

If you are sizing a battery, the annual total is the wrong output

PVWatts gives you one typical year. PVGIS gives you real years, individually, which is what battery modelling actually needs. The seriescalc endpoint returns hourly AC output:

https://re.jrc.ec.europa.eu/api/v5_3/seriescalc
  ?lat=51.45&lon=-2.59&raddatabase=PVGIS-SARAH3
  &startyear=2016&endyear=2023&pvcalculation=1
  &peakpower=4.4&loss=14&angle=30&aspect=20
  &mountingplace=building&usehorizon=1
  &outputformat=csv&browser=0

Eight calendar years of hourly generation, aligned to real weather sequences rather than a synthesised composite. Join that to your own half-hourly consumption (n3rgy or the Bright app for any UK smart meter, the Octopus API if you are with them) and you can simulate self-consumption, export, and cycles per year against eight different Februaries. A typical year hides exactly the information you need: how bad a bad winter looks, and how often a 5 kWh battery fails to fill.

UK annual irradiance swings roughly ±5–8% year to year. Spring 2025 was exceptionally sunny across England, 2024 was notably dull. That variability is why a single metered year cannot validate a long-term average to better than about 5%, and why recalibrating your model off one good summer will leave you over-forecasting for a decade.

Calibrating your baseline against your own meter

Once you have twelve months of inverter data, compute one number and write it down:

calibration = metered_kWh / PVGIS_modelled_kWh
Bristol example: 4,050 / 4,180 = 0.969

Apply that factor to future PVGIS runs on the same roof: different tilt, an added string, a modelled east-west split. The absolute weather bias, your particular panels’ real-world behaviour, your inverter’s clipping and your soiling all get absorbed into one empirical correction. Do not extend the factor past 24 months without recomputing it, and do not trust it to better than about 5% until you have three years behind it.

When you want a third opinion, use something with independent data rather than a third front-end on the same numbers. Solcast offers free API access for home systems with satellite-derived data on a finer grid and a much shorter latency than SARAH3. renewables.ninja is built on MERRA-2 and CM-SAF and is quick for orientation sweeps. If you are comfortable in Python, pvlib will run a proper single-diode or PVWatts-equivalent model on whatever weather you feed it, which means you can put Solcast data through the same chain as PVGIS data and isolate the weather from the model.

So the next time a quote lands with a generation figure on it, ask which tool produced it, then reproduce it. If it came from an MCS lookup or PVWatts defaults, you can usually work out the shortfall to the nearest per cent before you reply.