Explain Solar Access, Irradiance, and Expected Output

Customers are often shown three solar concepts in the wrong order. They see an annual energy number, then a shade graphic, then a map colored by sunlight. The presentation asks them to trust the output before anyone has explained what reaches the site, what reaches the array, and what the system model does with it.

A better conversation follows the physical chain. Solar radiation arrives at a location and surface. Nearby objects and the horizon affect access to that resource. Array orientation, equipment, temperature, losses, and operating assumptions convert the available resource into modeled electrical output. Each step answers a different question and carries its own evidence.

This walkthrough helps installer and EPC teams explain that chain to a buyer. It does not replace site verification, engineering review, manufacturer instructions, or the requirements that apply to a project. It gives the customer a useful mental model and a clear way to challenge an assumption.

Start with three different nouns

Use the same words consistently throughout the meeting.

Irradiance describes solar power arriving on a surface at a moment. Irradiation usually refers to solar energy accumulated on that surface over a period. Expected output is modeled electrical energy from a particular system configuration over a stated period. Solar access sits between resource and system: it describes how shading and horizon conditions affect access to the available solar resource under the chosen method.

The U.S. Department of Energy’s solar radiation basics distinguish direct, diffuse, and reflected components and explain variation with location, time, weather, and surface orientation. That source supports the vocabulary. It does not establish the irradiance at a customer’s roof on a future date.

Avoid using “sunlight,” “irradiance,” “solar access,” and “production” as interchangeable labels. A bright site can still have a poor array orientation. A plane with good access can carry fewer modules. Two designs on the same roof can have different electrical and loss assumptions. Precision in the nouns keeps the explanation short because each graphic has one job.

Give the customer a one-line chain: resource reaches the site, shade modifies what reaches the array, and the system model estimates what becomes electrical energy. Return to that chain whenever the discussion gets lost in software fields.

Show the resource before showing the roof

Begin with the geographic and weather basis. Name the solar-resource source, the data period or representative method when known, and the plane or orientation being described. A map or weather dataset is evidence about the modeled resource, not a measurement made on the customer’s roof during the meeting.

NLR provides the National Solar Radiation Database for several resource measures and geographies. Regional resource data are useful for broad context. They do not resolve one building’s tree line, roof obstruction, soiling, or operating condition. Explain scale before zooming to the property.

Customers may ask why a cool clear day can look different from a hot hazy day or why a south-facing and east-facing surface receive different modeled energy. Keep the answer physical. Sun position, cloud and atmospheric conditions, surface orientation, and time determine how radiation reaches that surface. The system model then adds conversion behavior.

Do not quote a single resource value without its unit and period. Power per area at a moment is different from energy per area accumulated across a day or year. If the customer does not need the unit, leave the raw value in the method note and use a comparison graphic. Removing a confusing number is better than relabeling it loosely.

Place the proposed array inside the resource story

Move from the region to the actual design. Show the building or ground area, the proposed planes, array orientation, and the source used to create geometry. State whether dimensions and obstructions came from imagery, customer material, a survey, or an assumption.

The DOE overview of photovoltaic system design explains that design considers solar resource, orientation, tilt, equipment, and system configuration. Use that broad design frame, then show the project-specific record. The government page does not validate the customer’s layout.

Explain why placement is a decision rather than a coloring exercise. A high-resource portion of the roof may conflict with access, roof use, setbacks selected for the project, structural questions, service routes, or equipment constraints. A lower-yield plane might still belong in an option if customer goals and project requirements support it.

Keep a preliminary layout labeled. A clean module arrangement based on imagery does not confirm roof condition, dimensions, loading, electrical feasibility, or approval. The customer should know which site findings can change module placement and when the team expects to verify them.

Use solar design confidence levels to distinguish a screening view, a proposal basis, and a release for a named technical decision. The image can remain the same while the evidence status changes.

Make solar access a comparison, not a grade

Solar access scores are easy to present as a school mark: green is good, red is bad, and a single percentage appears to settle placement. That presentation hides the period, reference resource, geometry, horizon, vegetation, and calculation method behind the score.

Instead, use solar access to compare named surfaces under the same method. Show which obstruction or horizon sector causes the difference. If trees create the modeled shade, state whether their height and persistence were measured, observed, or inferred. A deciduous tree, planned removal, future growth, and neighboring ownership raise different project questions.

Explain direct and diffuse light carefully. A shade object can block direct beam radiation at certain times while diffuse sky radiation remains. The model’s treatment matters. Avoid saying a shaded module “produces nothing” unless a validated scenario shows that for the stated period and configuration.

Tie the graphic to the customer’s decision. A sales discussion may compare two array locations or show why a section was omitted. A detailed design review may inspect horizon profiles, obstruction geometry, string placement, and electrical effects. Give the customer the view that supports the present choice.

The Irradiance and shading analysis workflow can help a team visualize shading. Results still depend on source data, geometry, assumptions, configuration, and review. Field evidence and responsible technical judgment remain part of project release.

Explain orientation and time without a trigonometry lesson

Use a day and a year. Across a day, sun position changes relative to each plane. Across the year, the path and day length change. Roof azimuth and tilt therefore shape when and how much irradiance reaches the array plane in the model.

Customers often expect the highest annual total to be the only sensible design. Their actual objective may include morning generation, afternoon generation, self-consumption, export constraints, roof use, aesthetics, or expansion. Present annual energy and time-of-generation as separate views when timing affects financial value.

Avoid universal orientation rules. The preferred arrangement depends on location, roof geometry, shading, equipment, tariff, load, and project constraints. “South is always best” or an equivalent hemisphere-specific slogan can be wrong outside its assumed context and can obscure a more useful east-west or multi-plane discussion.

A simple comparison card works well. Give each option the same module and model basis, identify plane orientation and material shading difference, then show modeled annual output and an appropriate time profile. The purpose is not to crown a winner before customer priorities are known. It is to show why two physically plausible layouts behave differently.

Build the bridge from irradiance to electrical energy

Now introduce the production model. Name the design revision, resource dataset, module and inverter assumptions, array orientation, shading treatment, system losses, and analysis period. If the model includes availability, degradation, clipping, curtailment, storage, or export limits, state how each affects the output shown.

The National Laboratory of the Rockies (NLR, formerly the National Renewable Energy Laboratory/NREL) provides the PVWatts calculator, which estimates grid-connected PV energy production from user-defined inputs. The PVWatts V8 API documentation enumerates model inputs and outputs. These sources are helpful method examples. They do not prove that a particular proposal’s inputs are correct.

Use a waterfall when the customer needs more detail. Start with modeled plane-of-array resource, then show conversion and loss categories without implying that every value was measured on site. Keep categories mutually understandable. A single miscellaneous-loss bar prevents a meaningful review.

Explain that the annual total is a modeled scenario, not a meter reading from the future. Actual production can differ because weather, site conditions, equipment behavior, downtime, maintenance, grid conditions, and operations differ from the model. The point is not to make the estimate meaningless. The point is to identify what it can support.

Separate expected output from a savings promise

Production and savings are downstream neighbors, not synonyms. Expected output estimates electrical energy. Savings assigns a financial value according to customer consumption, tariff, exports, financing, operating costs, and other assumptions. The same production scenario can produce different financial results for different load and tariff conditions.

Keep the transition visible. First agree which design and production scenario are under discussion. Then show how energy is valued. Do not use a lifetime savings total as proof that the irradiance or shade inputs are correct.

If the customer asks about payback, define the financial method and its cost boundary. A project can have an annual production estimate without a defensible customer payback result. Missing tariff or financing information should hold the financial claim, not force the designer to make a convenient assumption.

The projected solar savings checklist gives the downstream release questions. During this meeting, the simple boundary is enough: the energy page explains modeled electrical output; the financial page explains value under another stated set of inputs.

Use uncertainty labels the customer can repeat

Technical qualifiers fail when the customer cannot repeat them. Use short, stable labels beside the graphics.

• Resource basis: historical or representative dataset named in the model.
• Site basis: imagery, customer documents, field observation, or verified survey.
• Design basis: layout and equipment revision shown in the proposal.
• Shade basis: geometry, vegetation, horizon, and period represented.
• Output basis: model, loss assumptions, and operating boundary.
• Open condition: evidence that could materially change the result.

Do not hide all six in a disclaimer paragraph. Put the material one beside the affected number or graphic. A tree-height assumption belongs with the shade comparison. An unverified roof plane belongs with the layout. A generic “results may vary” line does not tell the customer what to inspect.

Give every open condition an owner and next event. “Verify southern tree height during site survey” is usable. “Subject to shading” is not. The first phrase connects uncertainty to work; the second merely transfers discomfort to the customer.

What should a solar-resource walkthrough page contain?

A solar-resource walkthrough page should contain the customer decision, site and design revision, resource source, irradiance view, solar-access comparison, proposed array, shading and loss assumptions, expected-output model, uncertainty labels, exclusions, reviewer, and next verification step. Each visual must state what it shows and what it cannot establish for the project. The visual sequence keeps four distinct claims from collapsing together.

The page should work as a sequence, not a collage of heat maps and charts. Start with the solar resource, place the roof and proposed array inside it, then show how the model converts that resource through design and losses into expected electrical output. Savings remains a separate later proof chain.

Use one revision identifier across the roof visual, loss table, production output, and customer proposal. A beautiful resource map paired with an old layout creates a coherent story about the wrong system.

How should the presenter explain a shading difference?

Explain a shading difference by identifying the exact roof area, model view, time or period, obstruction basis, solar-access method, and design revision being compared. Show how the difference enters the current production model, then state which site conditions or later evidence could change the interpretation without turning the comparison into a performance guarantee. Customers must repeat the model boundary clearly.

Start with the picture the customer can locate. Point to the plane, obstruction, or time window. Then move to the metric. A solar-access value without a surface and period can sound like a grade for the whole property, which it is not.

1. Confirm the customer is viewing the current site and design revision.
2. Name the roof area or array section being compared.
3. Show the sun-path or shading source used by the model.
4. Identify the obstruction evidence and uncertainty.
5. Connect the difference to the loss or production model.
6. State the preliminary or reviewed release boundary.
7. Ask the customer to restate what changed in ordinary language.

Use this copy-ready presenter note:

Customer decision:
Site and design revision:
Roof area discussed:
Resource and shading source:
Time or period represented:
Obstruction evidence:
Solar-access comparison:
Production-model effect:
Known limitation:
Next verification step:

The restatement is a comprehension test, not a sales technique. If the customer says “that roof produces exactly this much,” the presenter should correct the certainty. A better restatement is that the current model expects a difference under the shown resource, design, obstruction, and loss assumptions.

How should a design revision change the explanation?

A design revision should update every solar-resource visual, solar-access comparison, loss assumption, expected-output figure, and customer explanation affected by the change. The team should issue a new identifier, retire the stale customer asset, preserve the reason, and explain the visible consequence before using the revised projection in another meeting. The explanation follows the current project record, not private presentation memory.

Illustrative example, not a project result: A site visit confirms that an obstruction is larger than it appeared in the remote source. The current layout changes on one roof plane, and the production model is rerun under the new design revision.

The customer update begins with the site evidence and affected plane. It shows the old asset as superseded, the new array placement, the changed loss or expected-output item, and the current limitation. It does not imply that the revised model is guaranteed because it uses better information.

If the change has no material effect on one visual, record that assessment rather than regenerating content for appearance. If it affects savings, equipment, proposal, or another downstream output, route those records to their owners and issue them under the same scenario.

Use the solar-access visualization guide for additional visual formats and the seasonal sun-path explanation when the customer needs time-of-year context. This page owns the end-to-end walkthrough.

Test the explanation from the customer’s side

Before using the page broadly, ask a colleague who did not build the model to follow the walkthrough. The reviewer should identify the claim each frame makes, the source, the limitation, and the next action without relying on narration that is absent from the page.

Watch for confident misinterpretation. A reviewer who says “the graphic is clear” but cannot restate its boundary has found a design problem. Ask them to describe the page without using the presenter’s words. Their errors show where the visual is doing more persuasion than explanation.

Use accessible alternatives. Color should not be the only carrier of good and poor access. Provide labels, legends, table values where appropriate, sufficient contrast, and alt text that names the purpose rather than repeating “solar chart.” The customer may receive the page without the live cursor or animation that made it understandable in the meeting.

Keep technical depth available without forcing it into the first view. A customer may want the resource source, loss details, model configuration, or reviewer note. Link or expand those records from the relevant frame. Progressive disclosure works only when the underlying evidence exists and remains reachable.

End the test by changing one input. Switch the design revision, obstruction record, or modeled assumption in a controlled copy and verify that every affected frame changes together. If the old production figure survives beside the new layout, the walkthrough is not safe to issue even though each component looks polished.

Record the test case, reviewer, misunderstanding, corrective change, and retest. Do not claim the page improves customer comprehension from one internal check. The evidence proves that a defined failure was found and corrected, not a market outcome.

Structure the customer walkthrough

Run the meeting in this order:

1. State the customer decision and current confidence level.
2. Define irradiance, solar access, and expected output in one sentence each.
3. Show the resource source and the surface being described.
4. Show the site and proposed array, including unverified geometry.
5. Compare shade or access only across named design options.
6. Explain orientation and generation timing where relevant.
7. Show the model inputs that turn resource into electrical energy.
8. State the expected-output range or scenario with its method boundary.
9. Name the conditions that trigger another design or production run.
10. Ask which assumption the customer wants to inspect first.

This order follows causality. If the customer challenges output, trace backward to design, access, and resource. If they challenge a roof choice, remain at placement until the tradeoff is resolved. Do not jump to financial totals as a way to end a technical question.

Keep a second layer of detail available. The customer-facing view can be readable while the project record retains data source, dates, units, model settings, equipment identifiers, loss values, design revision, reviewer, and calculation run. Simplicity on the screen must not come from deleting the evidence.

Handle the hard customer questions directly

“Why is this different from another company’s estimate?” Compare inputs before outputs. Ask whether both proposals use the same roof area, equipment, shading, weather data, losses, analysis period, and operating assumptions. A larger number may reflect a larger design or a different loss choice rather than a better system.

“Can the trees grow and reduce production?” Yes, vegetation can change. Identify what the model assumed, who controls the trees, and whether maintenance or future growth was represented. Do not promise a stable access score when the site condition is outside the company’s control.

“Is the shade analysis accurate?” Explain the geometry source, review completed, period modeled, and unresolved conditions. Accuracy claims require a retained test specific to the method and use. The safer answer is evidence-based: what was observed, what was modeled, and what will be verified.

“Will the system produce this amount every year?” No annual model should be described as an exact future meter result. Show the resource basis and other assumptions, then explain which factors can cause variation. If a contract or guarantee exists, its controlling language and qualified review are separate from the sales explanation.

“Why not fill every roof plane?” Point to the named constraint or objective: access, shading, equipment, service route, structural question, aesthetics, customer load, export limit, or future roof use. Do not invent a rule. Let the design record answer.

Preserve the explanation when the design changes

Customer education is wasted if the proposal later changes silently. Link the walkthrough page to a design revision and production-run identifier. When layout, equipment, shading, resource data, or loss assumptions change, update the output and the explanation affected by that change.

Use a change note written for the customer: what changed, why it changed, which result moved, and which parts stayed the same. Avoid unexplained replacement of an annual figure. A transparent revision teaches the customer that the model responds to evidence.

Keep the original released artifact in the record. Sales and design should be able to reconstruct what the customer saw. This is especially important when a site survey corrects imagery-based geometry or a later obstruction changes the layout.

The solar site survey data collection guide helps connect remote modeling with field evidence. The handoff works in both directions: the model tells the surveyor what remains uncertain, and the survey tells the model owner what must change.

Use a final release check

Train the walkthrough with a deliberately awkward site, not only a clean roof. Give the presenter incomplete imagery, a shaded plane, a recent addition, and a customer who asks about a competitor’s larger estimate. The presenter should slow down, identify the evidence gap, and choose the next check. If the script only works when every input is settled, it is not ready for ordinary sales work.

Listen for words that collapse the chain. “The roof gets this much sun” may be acceptable conversational shorthand only when the graphic and explanation identify the modeled surface and period. “The panels will make this” converts an estimate into a promise. Correct the noun, restate the model basis, and continue without turning the correction into a defensive disclaimer.

Give sales an escalation route. Questions about structural condition, electrical suitability, legal rights, tax treatment, contract guarantees, or authority acceptance should reach the responsible reviewer. A good customer educator knows where the technical model ends. That boundary protects the customer and keeps the conversation credible.

Before showing expected output, verify:

• The customer page names the intended decision and confidence level.
• Resource source, method, period, and surface are identifiable.
• Site and roof geometry sources are recorded.
• Shading objects and unresolved conditions are visible.
• Layout and equipment match the production run.
• Loss and operating assumptions are listed at the right level.
• Units distinguish instantaneous power, accumulated solar energy, and system electrical energy.
• Annual output is labeled as modeled, not measured future performance.
• Financial value remains separate unless its inputs and method are reviewed.
• Revision triggers, owner, and next evidence are stated.

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

The NREL fourth-edition solar-resource best-practices handbook provides deeper context on collecting and using solar resource data. For the customer meeting, the practical standard is simpler: name the source, preserve the boundary, and connect every output to the design and assumptions that produced it.

Frequently Asked Questions

What is solar irradiance in plain language?

Solar irradiance is the rate of solar power arriving on a surface at a particular moment, commonly expressed per unit area. A production model uses irradiance or related solar-resource data across time. Irradiance is not the same as system output because orientation, shading, equipment, temperature, losses, and operation affect conversion.

What does solar access tell a customer?

Solar access describes how much of the available solar resource reaches a proposed array after nearby shade is considered over a stated period and method. It helps compare placement, but the score is tied to the modeled geometry, vegetation, horizon, and observation assumptions. It should not be presented as a permanent site guarantee.

Why can two roof planes have different expected output?

Roof planes can differ in orientation, tilt, shading, module count, ventilation, wiring, and equipment configuration. Those differences change the solar resource received or the way the system converts it. A customer comparison should hold the modeling method constant, show the design for each plane, and identify which assumptions caused the result.

Does an annual production estimate predict next year’s weather?

No. Many energy models use historical or representative weather data to estimate a scenario. Actual weather in a future year can differ. The estimate should name the resource dataset and period or method, then explain other design and loss inputs. A model supports planning; it does not forecast exact future weather or generation.

When should the expected-output explanation be updated?

Update it when material site or model inputs change, including layout, equipment, roof geometry, shading, vegetation, resource data, loss assumptions, curtailment, storage operation, or the intended decision. Keep the design revision and production-run identifier with the customer page so an old explanation is not attached to a revised project.