On this page13 sections
- 01Why an array is sized in peak sun hours rather than daylight hours
- 02Concepts to hold first
- 03Why sizing starts at the meter, not the roof
- 04The two numbers people guess wrong
- 05How the method works
- 06Try it, verified
- 07What each input represents
- 08Worked example
- 09Reading the result
- 10Common mistakes
- 11Questions readers arrive with
- 12When this calculation is used
- 13Assumptions and guards
Why an array is sized in peak sun hours rather than daylight hours
The answer arrives in kilowatts-peak, and the suffix is doing real work. A kWp is the output a module family produces under Standard Test Conditions — irradiance of 1,000 watts per square metre on a cell held at 25 °C — which is a laboratory reference point, not a promise about a roof. An array almost never delivers its nameplate in service; nameplate is simply the common currency in which arrays are bought, quoted and compared, and it is the currency the rest of this cluster trades in.
Peak sun hours compress a whole day of varying sunlight into an equivalent number of hours at full laboratory strength. A site quoted at 5.5 PSH receives, over a typical day, the same energy it would receive from five and a half hours of STC-grade sun and darkness the rest of the time. That compression is what makes the sizing a single division — but the figure is an ANNUAL AVERAGE, and averaging is where it bites: a mid-latitude site can see winter days at a fraction of its summer figure, so an array sized on the average will overshoot the bright months and fall short in the dark ones.
The performance ratio concedes that a real system is not the laboratory. Cell temperature above 25 °C, inverter conversion, wiring resistance, soiling, mismatch between modules — each takes its share, and the performance ratio is the fraction of the ideally available energy that survives all of them together. It sits in the denominator, so a lower ratio grows the array: the machine is deliberately oversized to cover its own losses.
The structure of the division is worth reading before any values go in. Load sits alone in the numerator, so the required array scales directly with demand; sun and performance sit together underneath, so halving either doubles the array. The pack also declares the reverse workflow: fix an array size — a roof or a budget already decided it — and the same relation, run backwards by the engine, returns the daily load that array can support.
Concepts to hold first
The electrical energy a household consumes in a day, read from a bill or a meter rather than estimated appliance by appliance. It is the demand side of the whole calculation: everything else exists to supply this number.
The day’s entire solar income compressed into equivalent hours of full-strength sun. A long overcast day and a short brilliant one can carry the same peak sun hours, which is exactly why the measure is useful: it makes different skies comparable.
The fraction of theoretically available energy a real installation delivers after heat, dust, wiring, inverter conversion and mismatch each take their share. It is the honesty coefficient of the calculation — the number that separates a brochure from a forecast.
The array’s rated output under standardised laboratory light. It is a nameplate for comparing panels, not a promise about any real roof — the rest of the calculation exists to translate the nameplate into delivered energy.
Why sizing starts at the meter, not the roof
A roof is a constraint, not a requirement. Starting from the roof answers the question “how much solar could I fit?”, which is almost never the question being asked. The question is “how much of my consumption can the sun carry?”, and that starts at the meter: a year of bills, divided into a daily rhythm, tells you what the array must produce on an average day before a single panel is chosen.
Working from consumption also exposes the cheapest improvement first. A household that trims its daily load before sizing buys a smaller array, a smaller inverter and — if storage comes later — a smaller battery. Every saved daily kilowatt-hour is bought once; every generated one is bought as hardware that must also be installed, maintained and eventually replaced.
The load number deserves more scepticism than either of the other two inputs, because it is the one the household controls and the one that changes. An electric vehicle, a heat pump, a new workshop — each rewrites the daily load, and an array sized to last year’s bills quietly becomes undersized without anything failing.
Demand flows from the meter to the array size, not from the roof
The direction of the reasoning: demand first, site and losses second, array size as the conclusion. A roof-first estimate runs this arrow backwards.
The two numbers people guess wrong
Peak sun hours are not daylight hours, and the difference is the most common sizing error in either direction. Daylight counts every pale morning hour at full value; peak sun hours weigh each hour by how much energy it actually delivers. A site’s figure comes from irradiance data — solar atlases, meteorological services, installer databases — and using a generic value from a different climate moves the array size by more than any other single mistake.
The performance ratio is guessed wrong in the optimistic direction almost exclusively. Heat derates panels precisely when the sun is strongest; dust accumulates fastest in the seasons it rains least; inverters convert at slightly less than their brochure figure all year. None of these is a defect — they are what “real installation” means — and the ratio exists so they are counted once, deliberately, instead of discovered later as disappointment.
Neither number requires precision to be useful. What both require is provenance: a peak sun figure traceable to the site’s own climate, and a performance ratio chosen from the installation’s actual conditions rather than from hope. The calculator’s guards refuse values outside the physically plausible range, but they cannot know your climate — that judgement stays with you.
How the method works
The daily load is divided by the site’s peak sun hours, which converts the energy demanded into the generating capacity that could supply it under the site’s own sun.
That capacity is then divided by the performance ratio, inflating it to cover the losses a real installation will impose between the panel’s rating and the meter.
The result is the array size, in kilowatt-peak, that covers the stated load on a day of average sun — no seasonal margin, no growth allowance, unless those were built into the load figure deliberately.
The certified engine performs this calculation. This page explains what it does; it does not reproduce it, because a second implementation of a specified method is a second answer waiting to disagree with the first.
Try the worked scenario
The calculator below is the same certified engine the calculator page runs — fetched, verified and mounted mid-lesson. It arrives pre-filled with the pack’s own worked example: a modest household load on a sunny site with realistic losses. Change the daily load to your own and watch the array size follow; then try the peak sun hours of a cloudier climate and see how sharply geography prices solar.
Read the result as capacity, not certainty: the array that covers the stated load on an average day. Every figure shown is computed by the verified engine as you type — nothing on this page stores an answer.
What each input represents
The energy consumed in a typical day, in kilowatt-hours — an annual total divided by the days in a year is the usual source, because a single month is biased by season. This is energy, not power: a figure from a utility bill, not the rating of the largest appliance. It is also an average, so it says nothing about the peaks a battery or an inverter would have to be sized for.
The site’s daily solar resource expressed as equivalent hours of full STC-strength sun. Take it from a solar-resource dataset for the actual location — NREL, PVGIS or PVWatts-class data — not from hours of daylight, which is a much larger number that would quietly undersize the array. The default supplied here is illustrative, not a property of any particular site.
The fraction of ideally available energy the whole system delivers after temperature, inverter, wiring, soiling and mismatch losses, entered as a decimal fraction strictly between zero and one. A well-designed grid-tied system justifies the illustrative default; a hot climate, a dusty site or a shaded roof justifies less. The measured performance ratio page in this cluster is how the value assumed here is later checked against reality.
Worked example
The scenario
Take the system this pack uses as its own anchor: a household averaging 22 kWh of consumption a day, at a site with 5.5 peak sun hours, assuming a performance ratio of 0.8 for a well-designed grid-tied installation.
The figure that comes back is the nameplate array size, in kWp, that covers the stated load at the stated sun over an average year. It is the number the rest of this cluster follows: the yield page runs it forwards into an annual production, the measured page audits the ratio assumed here, and the payback page prices the result. Read it as a screening size to set against roof area and budget, not as a completed design.
Now hold the load and drop the peak sun hours to a winter-grade figure. The required array grows in inverse proportion — which is the arithmetic behind a familiar trade-off: size on the annual average and accept a winter shortfall, or size on the worst month and overproduce the rest of the year.
Reading the result
The array size is a coverage statement: this many kilowatt-peak covers this daily load under this sun. It says nothing about when the energy arrives — a grid-tied home exports its midday surplus, an off-grid one must store it, and the same array size means different things in each.
If the result looks larger than roofs you have seen, the load figure probably includes something unusual — or the site’s sun figure is honest where a brochure’s was not. Both are worth knowing before the quote stage, not after.
A result far below the available roof is the pleasant case: it leaves room for the load to grow, or for the array to be built in stages.
Common mistakes
Using daylight hours where peak sun hours belong — the single largest and most common oversizing-in-reverse error, because daylight is always the bigger number.
Taking the daily load from a single summer or winter bill. Consumption is seasonal; an average hides a winter that the array will meet or miss.
Adopting the performance ratio from equipment brochures rather than installation reality — brochures describe laboratories.
Sizing to the roof and then searching for a load figure that justifies it. The calculation will happily oblige; the meter will not.
Questions readers arrive with
Where do I find my daily load?
A year of electricity bills is the honest source: total the year’s consumption and let the calculator’s daily framing do the rest. A per-appliance estimate is better than nothing, but it reliably undercounts the loads nobody remembers owning.
Where do peak sun hours for my site come from?
National solar atlases, meteorological services and installer irradiance databases all publish site-level figures. Any of them beats a figure borrowed from a different climate — peak sun hours are a property of your sky, not of solar panels.
What performance ratio should I assume?
A well-installed, well-ventilated, occasionally cleaned system justifies the upper end of the plausible range; heat, dust, shading and long cable runs argue it down. The calculator refuses values outside the physically credible band, and the third lesson in this journey shows how to measure the real one from a year of meter data.
Does this sizing include a battery?
No. It sizes generation against consumption. Whether the energy arrives when it is needed is a storage question, and it has its own calculators — the payback lesson at the end of this journey hands over to them.
When this calculation is used
Turning a year of electricity bills into a first array size, before any installer has visited the site.
Comparing candidate sites or roof orientations, where the peak-sun-hours figure is the only input that changes.
Pre-sizing an off-grid system, where the array must carry the whole daily load before battery sizing even begins.
Sanity-checking a quotation: an installer’s proposed size, the household’s stated consumption and a plausible performance ratio must be consistent with one another.
Assumptions and guards
Peak sun hours enter as one annual-average figure, so seasonal swing is invisible: the sizing balances the year as a whole, not its worst month.
The performance ratio is a single constant, although the losses it bundles — temperature above all — genuinely vary through the day and the year.
The load is an average energy figure. Nothing here sizes for peak power, so the inverter and any battery need their own calculations.
The relation knows nothing about the roof: whether the resulting array physically fits, and how many modules it takes, are separate checks this pack carries as sibling calculators.
The performance ratio must be strictly below one — the pack ships that refusal as a declared test vector. A ratio of one describes a lossless system, which does not exist, and the same ceiling catches the commonest slip: a percentage entered where a decimal fraction belongs lands far above the bound and is refused rather than sizing an array that is wrong by orders of magnitude.
Peak sun hours are bounded to the range real sites occupy. An annual irradiance total, or a daylight-hours figure for a summer day, falls outside the band and is refused as a unit mistake rather than silently sizing against the wrong quantity.
The daily load must be greater than zero and is capped at a utility-scale ceiling. A zero load has no array to size, and a figure beyond the cap is far more likely an annual total entered as a daily one than a real household.