Solar Access and Sun-Simulation Review Checklist

A moving shadow can make a solar model feel self-evident. Drag the clock, watch the chimney shadow cross a roof plane, and the scene appears to explain itself. The animation proves only that the geometry and sun-position routine produced that frame. Annual solar access requires a much longer chain of inputs and definitions.

Review therefore begins outside the animation. The designer needs to know which site, coordinate basis, time convention, weather source, roof revision, horizon, shade objects, irradiance method, electrical grouping, and output definition created the result. A plausible picture cannot recover a missing link in that chain.

The Sandia PV Performance Modeling Collaborative solar-position guide explains the modeled solar geometry used to locate the sun relative to an observer. That mechanism supports the first review principle: if location or time is wrong, a beautifully rendered shadow is still wrong for the project.

This checklist is for solar designers and reviewers checking sun simulations, shading scenes, or solar-access outputs before they inform layout or production discussions. It is not a site survey, energy guarantee, structural review, or professional approval.

Define the output before interpreting its color

Write the exact metric name, units, period, spatial level, reference condition, and calculation method. “Solar access” can refer to different ratios or tool-specific outputs. A percentage without a definition is not portable between tools or projects.

Create an output card:

If the tool does not expose a definition, restrict the claim. Use the output as a comparative design signal inside the same method rather than treating it as an independently verified physical fact.

Do not translate a colored heat map into customer language until the team knows what each color measures. A red area may represent lower access relative to a reference, not a prediction that modules placed there will “lose” the same percentage of annual production.

Check site coordinates and time convention

Confirm latitude, longitude, elevation where the method uses it, time zone, daylight-saving treatment, and timestamp convention. Make sure the coordinates belong to the modeled building, especially on campuses or repeated developments.

Review the relationship between clock time and solar time in the selected method. Do not shift a scene until it matches a photograph by eye without determining when and how the photograph’s timestamp was recorded. Phone time zones, camera metadata, and daylight-saving settings can mislead.

Use diagnostic scenes rather than a single attractive one. Select times when a major object’s shadow should cross a recognizable edge. Compare direction and relative length with independent evidence where available. The purpose is to expose rotations, time offsets, or height errors.

Record the sun-position method and software version. A model update may change behavior or defaults. Retain enough information to reproduce the reviewed scene rather than saving only an image.

Confirm weather data and its relationship to the site

Weather data provides irradiance and environmental inputs beyond geometric sun position. The PVPMC weather-data sources guide describes sources used in PV performance modeling. The project record should state the file, provider, location, period or typical-year basis, access date, and any transformations.

Do not call a weather file “local” without explaining its relationship to the site. A nearby station, gridded dataset, satellite-derived source, and typical meteorological year each carry different provenance. The responsible modeling method decides whether the source is suitable.

Inspect missing data, units, timestamps, and irradiance components where the workflow exposes them. A format import can shift time or misread units while still producing a complete chart. Compare basic seasonal patterns and selected records with source documentation.

The PVPMC irradiance and insolation overview distinguishes irradiance as power per area and insolation as solar energy accumulated over time. Use the correct term and unit in the review record. Do not swap them because a proposal template uses a familiar label.

Verify roof orientation, slope, and plane identity

The simulation should reference the released or clearly qualified roof model. Confirm coordinate orientation, plane azimuth and tilt basis, elevations, and module-surface assignment. Select a few planes and trace them from source geometry through the solar-access output.

Check whether the tool models bare roof planes, module planes, or points placed above the surface. That offset can matter near parapets or short obstructions. Record module tilt or racking geometry separately when it differs from the roof.

The PVPMC plane-of-array irradiance guide describes beam, diffuse, and ground-reflected components on a plane. This explains why orientation and tilt affect more than direct-shadow outlines.

Do not validate geometry with the simulation it feeds. Use independent imagery, survey, drawing, photograph, or field evidence according to the model’s intended use. A smooth seasonal curve cannot prove that a roof plane was drawn correctly.

Fast, reviewable solar roof modeling gives the geometry evidence checklist that should precede this simulation review.

Inspect the horizon and far-field obstructions

Near objects such as chimneys and dormers are easy to see in a 3D scene. Trees, adjacent buildings, terrain, parapets, and a distant horizon may be missing, clipped, or represented through another data layer.

List every obstruction class included. State its source date, coordinate relationship, height basis, seasonal treatment where relevant, and confidence. For vegetation, distinguish measured or observed canopy from an assumption about leaf state or growth.

Walk around the modeled site from several virtual viewpoints and compare with current photographs or survey evidence. Look for objects that intersect the ground incorrectly, float, sit on the wrong parcel, or cast shadows from an implausible height.

When far-field effects use a horizon profile rather than 3D objects, record how the profile was created and applied. Do not add the same obstruction again as geometry and count its effect twice. Review the junction between horizon and local objects for gaps.

Test shade scenes for geometric failure

Choose diagnostic times that isolate each major obstruction. Observe shadow origin, direction, length, surface intersection, and transition between planes. A shadow that begins below a chimney or jumps across a roof gap reveals geometry or rendering trouble.

Use a scene log with date/time convention, object, expected intersection, observed behavior, evidence compared, and disposition. Screenshots help communication, but keep the underlying model state and input record.

The PVPMC shading, soiling, and reflection-loss guide separates several loss mechanisms that can otherwise be bundled under one generic percentage. The review should state whether the tool’s shade output represents only geometric obstruction or includes another treatment.

Do not adjust object height until a shadow “looks right” without a source. Use the mismatch to request better evidence. Where a preliminary decision must proceed, label the assumption and test a conservative alternative within the approved method.

Review diffuse light, reflection, and transposition assumptions

Direct-beam shadows dominate visual simulations, but performance models also treat diffuse and ground-reflected irradiance. Confirm which transposition and sky-diffuse approaches the workflow uses, which albedo or ground-reflection basis applies, and whether obstructions affect diffuse components.

Avoid comparing a ray-traced direct shade image with an annual loss total as if one generates the other transparently. Document the intermediate method. If the tool abstracts or hides it, qualify the result and use an approved independent method where the release requires one.

Inspect unusual inputs. A very bright ground assumption, inappropriate snow treatment, or a horizon omitted from diffuse calculations may affect results without changing the visible direct shadow. The responsible model reviewer decides materiality.

Keep source dates and volatility. Weather and physical surroundings may change on different schedules. A typical-year file does not make a newly constructed neighboring building disappear.

Connect shade results to module and electrical grouping

A roof heat map is not the final system effect. Modules occupy specific areas, strings or module-level equipment connect them electrically, and inverter behavior affects the performance chain. Record how spatial shade information moves into the selected system model.

Check module positions against the reviewed roof revision. If layout changed after simulation, retire or rerun the affected output. A solar-access value attached to a module ID should not migrate to another physical location when IDs are reused.

The DOE PV system design basics describes inverters and power electronics as system components. The relevant manufacturer documentation and project method control how a specific electrical architecture is represented. Do not assume one shading-loss behavior across string inverters, optimizers, and microinverters.

State what the model includes and omits. Geometric shade, irradiance transposition, module electrical response, mismatch, bypass behavior, inverter clipping, availability, soiling, and degradation are distinct mechanisms. Avoid wrapping them in one unexplained “solar access” number.

Compare outputs without declaring a winner too early

If two tools differ, freeze the same project geometry and map their inputs. Compare coordinates, time conventions, weather files, horizon, object geometry, transposition, diffuse treatment, module placement, electrical configuration, and output definition.

Build an input-difference table before comparing annual totals. Some results may become comparable after harmonization; others may remain method-specific. Report that boundary instead of ranking tools from one unmatched case.

Use targeted intermediate comparisons. Do both tools place the sun similarly at selected times? Do direct shadows intersect the same roof edge? Do plane-of-array components use the same units and period? At which stage does the result separate?

Never infer that agreement proves correctness. Two tools can share the same wrong coordinate or imported geometry. Independent source checks remain necessary.

Package a simulation another reviewer can reproduce

The package should include project and model revision, site coordinates, time basis, sun-position method, weather source, roof and shade geometry sources, horizon, irradiance method, module/layout revision, electrical representation, output definition, diagnostic scenes, assumptions, exceptions, reviewer, and allowed use.

Use three outcomes: return for source/model correction, ready for responsible review, or released for a named use. A preliminary shade visualization can support a customer discussion if its limitations are visible. It should not silently become a guaranteed production statement.

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.

Shading analysis workflow explains where this review fits from site evidence through system modeling. Generation and Financial Tool describes SurgePV’s energy-yield and financial modeling support. Keep each output tied to the design and assumption revision that produced it.

What should a sun-simulation review packet contain?

A sun-simulation review packet should contain the intended decision, metric definition, site coordinates, time convention, sun-position method, weather source, roof and obstruction revisions, horizon treatment, irradiance method, system representation, diagnostic scenes, uncertainty register, change history, open conditions, and named reviewer. It should let another qualified person reproduce selected checks without relying on an animation, unlabeled screenshot, or the modeler’s memory.

Build the packet around the current release, not every experiment. Preserve prior versions under revision control, then index the exact inputs and outputs that support the reviewed result. A folder full of scene captures can show activity while concealing which one belongs to the current roof, weather file, or calculation method.

Use this packet index:

Use a copy-ready cover:

Project and simulation revision:
Decision supported:
Metric and period:
Site, time, and weather basis:
Roof, layout, and shade-object revisions:
Horizon and irradiance treatment:
Electrical or system representation:
Diagnostic scenes retained:
Highest-impact uncertainties:
Current conditions and prohibited claims:
Reviewer and release disposition:

Keep identifiers stable between the model and packet. “Large tree” becomes ambiguous when the site contains several trees or another source uses a different viewpoint. An object ID should connect location, geometry source, diagnostic scenes, uncertainty, and any required field confirmation.

Before release, have someone outside the preparation path reproduce one selected scene from the packet. They should be able to find the timestamp convention, site coordinates, geometry revision, and relevant object without verbal coaching. Failure to reproduce the scene is a handoff defect even when the underlying model is technically sound.

Use solar design confidence levels to label screening, proposal, and higher-consequence evidence consistently. A simulation’s confidence should follow its sources and review state, not the visual realism of its shadows.

How should a time or geometry mismatch be investigated?

Investigate a sun-simulation mismatch by freezing the model, identifying the object and scene, and checking site identity, orientation, timestamp convention, sun-position method, geometry source, and surface intersections in that order. Compare with independent dated evidence, change one supported input at a time, and retain each result. Never drag the clock or resize an object merely until the shadow looks plausible.

Use this sequence:

1. Record the model, roof, object, and layout revisions used by the scene.
2. Preserve the mismatched frame with its exact date, time, zone, and clock convention.
3. Confirm that the coordinates and modeled building match the project.
4. Verify model orientation and the convention used for north.
5. Check the sun-position configuration without altering geometry.
6. Trace the object’s footprint, height, and location to independent evidence.
7. Inspect shadow origin and surface intersections from several viewpoints.
8. Change only an input supported by another current source.
9. Rerun the diagnostic scene and record what changed.
10. Expand the review to annual or system outputs affected by the corrected input.

Illustrative workflow example, not a measured project result: A customer photograph shows a chimney shadow reaching a visible roof joint, while the modeled scene for the recorded time places the shadow on another plane. The reviewer does not increase the chimney height to force agreement. They first verify the photograph’s timestamp, site orientation, roof revision, and object identity.

The review finds that the model and image use different clock conventions. The team corrects the time basis according to the approved method, reruns the diagnostic scene, and records the change. It then identifies every annual or customer-facing output created from the former setting and decides which must be regenerated, qualified, or withdrawn.

If the timestamp cannot be trusted, the photograph may still support object presence and approximate geometry without validating that exact shadow position. Mark that limited use. One weak field should not cause the team to discard useful evidence or upgrade it into a stronger claim than it supports.

Keep a mismatch record:

Scene and object IDs:
Observed mismatch:
Independent evidence and date:
Coordinate and orientation check:
Time-convention check:
Geometry-source check:
Supported input change:
Affected metrics and outputs:
Reviewer disposition:
Evidence still required:

The process deliberately separates diagnosis from model tuning. A reviewer is testing which source relationship failed, not searching the interface for a picture that resembles expectations.

Test uncertainty where it can change the layout decision

A model can contain many uncertain inputs without needing a full sensitivity study for each. Prioritize uncertainties that can change module placement, electrical grouping, equipment selection, or the customer conclusion. This keeps the review useful rather than turning it into a catalog of every possible imperfection.

Start with source confidence. For each major shade object, record whether location, footprint, and height are measured, drawn from current imagery, inferred from perspective, or assumed. For the horizon, record whether it comes from surveyed data, terrain data, site observation, or a generic default. For weather, record the dataset and its relationship to the site.

Then define a plausible alternative from real evidence or a clearly labeled conservative bound. Do not invent a percentage range. Move an uncertain tree height only within the documented observation, test an alternate roof orientation only when sources conflict, or compare weather files only when the approved modeling method permits the comparison.

Run the alternative and observe which decision changes. A different shade total with the same layout choice may be relevant to production communication but immaterial to module placement. A small geometric change that removes a narrow viable row can be decisive. Record the decision effect rather than ranking uncertainty by the size of one output difference.

Use an uncertainty register:

Do not average alternative outputs into a more “balanced” answer. Choose the basis accepted by the responsible method or present the alternatives with their conditions. An average can correspond to no physical scene and conceal the input that still needs verification.

Close sensitivity work when the team understands which uncertainty controls the decision and has assigned the evidence required. More runs add noise after that point. If a high-consequence conclusion remains sensitive to weak evidence, narrow the release purpose or wait for better evidence.

When should a solar-access result be held from release?

Hold a solar-access result when its site, time, metric, weather, geometry, horizon, method, system mapping, or review authority cannot support the intended use. Also hold any downstream claim that depends on an unresolved controlling input. A narrower diagnostic or preliminary use may continue only when its limits, audience, open conditions, and next verification step are recorded clearly beside the result.

Use hold reasons that tell the owner what to repair. “Simulation issue” is not actionable. State whether the gap is site identity, clock convention, weather provenance, roof revision, object geometry, horizon duplication, method definition, module mapping, customer-language mismatch, or missing qualified disposition.

Prioritize the earliest failed source. If the model uses the wrong roof revision, do not open separate holds for every module’s solar-access value. Hold the affected simulation on geometry identity, list dependent outputs, and repeat their checks after the roof source is corrected.

Use this hold record:

Result, metric, and simulation revision:
Intended release and audience:
Failed or unresolved input:
Source or decision required:
Affected roof areas, modules, and outputs:
Owner responsible for correction:
Qualified role responsible for acceptance:
Narrower use allowed, if any:
Claims prohibited during the hold:
Closure evidence and reopen trigger:

Do not close the hold because a new animation appears plausible. Closure needs the corrected input record, affected reruns, comparison with the prior result, and the required reviewer disposition. If the correction changes a customer-facing image or conclusion, route the new communication through its approval path and retain the superseded version.

Some waits are legitimate. A current tree measurement, survey, utility record, model review, or customer decision may sit outside the designer’s control. The workflow should show the owner and permitted interim work instead of hiding the delay inside “in progress.” Visibility does not remove the dependency, but it prevents a preliminary result from leaking downstream as accepted evidence.

Require recipient acknowledgment for a released simulation package. The receiver should confirm the project, design revision, metric, purpose, and conditions they received. A download receipt proves transmission only. It does not show that sales, design, engineering, or another consumer understood which visual or value is current.

If the receiver needs a simpler image, create it from the released model and retain its source identity. Do not detach the picture from its metric definition, relevant assumption, or prohibited claim. Archive the approved communication beside the technical package so a later geometry or method change can trigger a deliberate review of both.

Close the handoff when the recipient accepts, returns, or escalates the named package. Silence leaves the simulation in transmission, even if the file exists in a shared folder. That distinction prevents an unreviewed shade view from becoming the default simply because it is the easiest artifact to find.

Explain shade findings without upgrading them into guarantees

Customer and commercial teams often need a simple explanation. Simplicity should come from a clear causal chain, not from removing limitations. Show the relevant roof area, the obstruction, the period or scene, the design response, and what remains subject to site or technical review.

Avoid translating a solar-access metric directly into bill savings or annual production. The customer may hear “ninety percent solar access” as “ninety percent of ideal system output,” even when the tool defines the metric differently. State the tool’s definition in ordinary language and keep broader energy results in the full performance model.

Use comparison views carefully. A before-and-after layout can show that modules were moved away from a shaded area. It does not prove the revised layout has a particular financial advantage unless the approved model and current commercial inputs support that separate claim.

Keep diagnostic animations subordinate to the annual method. A dramatic winter shadow may occupy much of the roof when the sun is low, while its annual energy effect depends on irradiance and duration. Conversely, a modest-looking repeated obstruction can matter over many periods. Explain why the annual calculation uses more than one scene.

Where field evidence is pending, say so beside the visual. “Tree geometry estimated from imagery captured on the stated date; confirm current canopy and height before final design” tells the reader what could change. A disclaimer on the last page does not repair an unqualified image earlier in the proposal.

Give sales and customer-facing reviewers a short approval checklist. Does the visual match the current design revision? Is the metric defined? Are source date and important assumptions visible? Does the language avoid a guaranteed output? Is the next verification step named? If one answer is no, return the communication without changing the technical model to fit a sales phrase.

The useful explanation may be modest: “This model indicates that the chimney affects the lower part of this plane during the selected periods, so the preliminary layout leaves that area open. Current site conditions and the final reviewed model still control.” It gives the buyer a mechanism and a design response without claiming more than the evidence shows.

Archive the exact customer-facing image with the model revision and approval note. If geometry, weather basis, layout, or metric changes, decide whether the earlier explanation remains valid and whether the recipient needs an updated view. Do not reuse an attractive simulation from another design option merely because the roof looks similar. The image is an output of a specific source chain, and its communication status should change when that chain changes.

That record also gives later reviewers the context needed to retire stale visuals safely.

Frequently Asked Questions

What does solar access mean in a design review?

Solar access describes how available solar radiation at a location and surface is affected by sun position and obstruction over a stated time basis. The exact metric depends on the tool and method. Reviewers should record its definition, period, irradiance basis, geometry, weather source, and exclusions before interpreting a value.

Can one sun-path screenshot validate a shading model?

No. A screenshot can expose a geometry or orientation error at a selected time, but it does not validate the full annual calculation. Review several diagnostic dates and times, confirm the underlying sun-position and weather basis, inspect shade-object geometry, and compare the model with independent site evidence.

Should nearby trees be included in a solar simulation?

Include trees when their location and dimensions can materially affect the intended placement or analysis. Record source date, geometry confidence, and whether seasonal canopy or future growth is represented. If evidence is weak, use a visible conservative assumption or require field confirmation rather than inventing a precise tree model.

Why can two shading tools produce different results?

Tools can use different weather files, time conventions, sun-position methods, horizon treatment, irradiance transposition, shade geometry, diffuse-light assumptions, electrical mismatch treatment, and loss definitions. Compare their inputs and output definitions before comparing totals. A difference is a diagnostic prompt, not automatic proof that one tool is wrong.

Does solar access prove expected PV production?

No. Solar access is one input or diagnostic within a broader performance model. Production also depends on weather data, plane-of-array irradiance, module and inverter behavior, electrical configuration, temperature, losses, availability, assumptions, and review. Keep the solar-access output tied to the model version and its stated limitations.

A convincing shadow is the start of review

Sun simulations are useful because they make an invisible geometry problem visible. They are risky when visual confidence outruns input control. The reviewer should be able to move from any shade result back through its surface, object, sun position, weather basis, method, and project revision.

Use animations to find questions, annual calculations to answer the defined metric, and independent evidence to validate the model. Keep those three jobs separate and the output becomes easier to explain without turning it into a promise.