East-West vs South: Modelling Orientation Against Your Own Load Curve

Every installer quote you get on an east-west roof will contain some version of the same sentence: “your roof isn’t ideal, you’ll lose about 20% compared to south.” The number is roughly right. The conclusion drawn from it is usually wrong, because kWh is not the unit your bill is denominated in.

If you are researching east west solar panels uk because your ridge runs north-south and you want to know whether it’s still worth doing, the honest answer is that it very often produces more value than the south-facing array you can’t have, and sometimes more than the south-facing array you could have. Proving that takes about an hour with PVGIS, pvlib and your own half-hourly consumption data. Here’s how.

The yield gap is real, and it’s the wrong metric

Run PVGIS 5.3 (SARAH3 database) for a Nottingham site, 52.95°N, -1.15°E, 35° pitch, 14% system losses:

Twenty-three per cent less per installed kilowatt-peak. That is the number quoted at you, and every solar calculator on the internet reports it, because kWh/kWp is easy to compute and doesn’t require knowing anything about you.

The problem is that nobody buys kilowatt-peaks. You buy a roof’s worth of panels feeding an inverter, and you consume the output against a demand curve that has its own shape. Two arrays producing identical annual kWh can differ by hundreds of pounds a year in value, and two arrays differing by 20% in kWh can be worth the same.

Get your actual load curve first

Before modelling any array, pull your own half-hourly consumption. Three routes, all free:

• n3rgy (n3rgy.com) gives you half-hourly import data straight from the DCC. You need your MPAN and the MAC address off the back of your in-home display. Data goes back 13 months and comes out as JSON or CSV.
• Hildebrand Glowmarkt does the same via the Bright app, with a documented API and a CAD if you want live readings.
• Octopus Energy’s REST API exposes /v1/electricity-meter-points/{mpan}/meters/{serial}/consumption/ with an API key from your dashboard. Two years of half-hourly data, paginated, no faff.

Resample a year of it to a mean daily profile and look at the shape. A house with a morning routine and an evening routine looks like this:

hour    mean kW
00:00      0.21
02:00      0.19
04:00      0.19
06:00      0.66   <- showers, kettle, hob
08:00      0.61
10:00      0.28
12:00      0.30   <- nobody home
14:00      0.32
16:00      0.85
18:00      1.38   <- cooking, washing, telly, everything
20:00      0.75
22:00      0.34

That’s 4,430 kWh a year, and the crucial feature is the trough between 09:00 and 16:00. A south-facing array dumps 63% of its annual output into exactly that window. It is, from a self-consumption point of view, generating hardest at the moment you need it least.

Worked example one: equal kWp, and why the gap collapses

Take 5.4 kWp (12 × 450 W) and model it both ways against the load curve above. No battery, flat import at 27p, a legacy SEG export deal at 5p.

The east-west array generates 1,030 fewer kilowatt-hours and is worth £5.70 more. A 20% energy deficit converts to a 1% value surplus, because south’s extra kWh arrive at 12:30 and get sold for 5p while east-west’s kWh arrive at 07:45 and 17:30 and offset 27p purchases.

Read that table again with the split column: self-consumption rises from 31.5% to 45.5%. That’s the entire mechanism. The east-west array is not better at making electricity, it’s better at making electricity you were going to buy anyway.

Worked example two: the comparison that actually applies to you

Equal-kWp is a thought experiment. In practice you don’t choose orientation, you choose what to do with the roof you own, and a north-south ridge gives you two usable slopes instead of one. That changes the arithmetic completely.

Same house, 3.68 kW inverter (the G98 single-phase limit, no DNO application needed):

Thirty per cent more value, same inverter, same G98 notification, roughly £1,400 more in panels and mounting. The east-west array wins on the metric that loses (total kWh) and the metric that matters, because you could fit almost twice the DC capacity behind the same 3.68 kW of AC.

Clipping is the thing to check here, and it’s the one place east-west’s flatness earns its keep twice. A 7.4 kWp south array on a 3.68 kW inverter would be unusable, with a summer peak north of 5.5 kW. Split east-west, each side peaks at roughly 62% of nameplate at its own solar hour while the other side is on diffuse light, so the combined peak lands around 4.2 to 4.3 kW and clipping costs about 250 kWh a year. Worth modelling, not worth panicking about.

Modelling it properly with pvlib

PVGIS gives you monthly totals through the web UI, which is not enough. You need hourly output, which means the TMY endpoint and pvlib-python. Our pillar on forecasting what your roof will actually generate covers the irradiance and loss modelling in depth; this is the orientation-specific slice.

import pvlib, pandas as pd
from pvlib.location import Location
from pvlib.pvsystem import PVSystem, Array, FixedMount
from pvlib.modelchain import ModelChain

tmy, _, _, _ = pvlib.iotools.get_pvgis_tmy(52.95, -1.15, map_variables=True)
loc = Location(52.95, -1.15, tz='Europe/London', altitude=60)

mods = pvlib.pvsystem.retrieve_sam('SandiaMod')['Canadian_Solar_CS5P_220M___2009_']
invs = pvlib.pvsystem.retrieve_sam('cecinverter')['ABB__MICRO_0_25_I_OUTD_US_208__208V_']

def build(azimuths, strings):
    arrays = [Array(FixedMount(surface_tilt=35, surface_azimuth=az),
                    module_parameters=mods, temperature_model_parameters=tp,
                    modules_per_string=8, strings=n)
              for az, n in zip(azimuths, strings)]
    return PVSystem(arrays=arrays, inverter_parameters=invs)

south = build([180], [1])
east_west = build([90, 270], [1, 1])

Then run each through ModelChain(system, loc).run_model(tmy), scale mc.results.ac to your real kWp, clip at your inverter’s AC rating with .clip(upper=3.68), and join it to the half-hourly consumption you pulled from n3rgy. Resample both to 30 minutes, and self-consumption is one line:

df = gen.to_frame('gen').join(load.to_frame('load')).dropna()
df['self'] = df[['gen', 'load']].min(axis=1)
df['export'] = df['gen'] - df['self']
print(df[['gen', 'self', 'export']].sum() * 0.5)   # half-hourly -> kWh

Output for the 7.4 kWp east-west case:

gen       5427.1
self      2058.6
export    3368.5
dtype: float64

Claude or ChatGPT will write the tariff-weighting layer on top of this in about thirty seconds if you paste in your Agile price CSV. The modelling is not hard. The data collection is what people skip.

Add the time-of-use layer and the gap widens

On Octopus Agile the 16:00 to 19:00 band routinely sits at 30 to 38p while midday in April and May drops to 8p, occasionally to zero, occasionally below. Agile Outgoing tracks the same day-ahead shape, paying around 4p for a midday export and 20p or more for a 17:30 one.

Weight the two arrays’ half-hourly output by those prices instead of a flat rate and the west slope starts doing something a south slope structurally cannot: generating 1.4 kW at 17:00 in July, straight into the peak band, at the exact half hours a Predbat-managed battery would otherwise be discharging. Our 7.4 kWp east-west case picks up roughly 480 kWh a year in the 18:00 to 21:00 window against south’s 349, and those kWh are worth five times a midday one.

Where this argument stops working

Be honest with your own model. Three cases flip it back to south:

A high export rate. On Octopus Outgoing Fixed at around 15p, the equal-kWp comparison reverses hard: south’s £972.60 against east-west’s £849.30, because the 1,290 extra exported kWh are now worth £194 instead of £65. Self-consumption only matters when the import/export spread is wide. Check your actual SEG rate before running any of this.

A daytime base load. Heat pump running a weekday setback, home working with a 400 W office, an EV on a granny charger from 10:00 to 15:00. Any of these fill the midday trough, and a filled trough is precisely what a south array is optimised for. Model it; don’t assume.

Shading. An east slope with a neighbour’s oak on it at 08:00 loses the entire morning hump, which is the whole reason you chose east-west. String-level modelling in PVsyst or per-panel optimisers change that calculation more than azimuth does.

Pull your MPAN data tonight, run the equal-kWp comparison against your own curve, and look at the self-consumption percentage rather than the annual total. If yours comes out below 30% on the south case, your roof was never the constraint.