Answer
Before finalizing a solar layout, confirm the roof geometry and obstruction data, including their dates and uncertainty. Check seasonal shading, nearby obstacles, distant horizon and row-to-row effects for the actual module positions. Compare viable layout alternatives with consistent simulation assumptions, then record unresolved site checks and the design revision used in the proposal.
A shading check should answer a layout question: which modules are affected, what causes the shade, and whether the evidence is strong enough to release that design. A screenshot of shadows at noon does not settle those questions for a full year.
This checklist is for installers and EPC design teams moving from a preliminary model to a final layout. It keeps the useful distinction between confirmed site facts, estimates and unresolved checks. Project-specific structural, electrical and access requirements need their own responsible reviewers.
1. Make an obstruction inventory before placing modules
Record nearby buildings, roof ridges, chimneys, vents, parapets, trees and roof equipment. Include objects outside the parcel when they can affect the array. Give each object a source, date and verification status; a feature missing from an aerial image is not proof that it is absent on site.
HelioScope’s shade-modeling guidance distinguishes row-to-row shading, modeled obstructions and horizon effects. This is a useful way to organize the review even when using another tool.
| Object or condition | What to record | Question before release |
|---|---|---|
| Chimney or plant enclosure | Position, footprint and height relative to the roof | Is the height measured or estimated? |
| Trees | Location, canopy geometry, evidence date and seasonal assumptions | Does the model represent the present canopy? |
| Adjacent building | Geometry and source of height information | Does the building extend beyond the scene boundary? |
| Roof ridge or parapet | Elevation and relationship to the proposed modules | Is roof self-shading included? |
| Distant terrain | Horizon data and calculation setting | Is terrain shading handled separately? |
| Planned construction or pruning | Evidence and implementation status | Is this an existing-condition or future scenario? |
The table is a recommended working record, not a jurisdictional submission checklist. Do not enter a proposed tree removal as an existing site fact.
2. Reconcile the model with the roof and data dates
Confirm that roof planes, slopes and elevations describe the current building. Check the imagery and any point-cloud dates independently: data from different surveys can show different states of the site. Review azimuth conventions rather than assuming every tool defines zero the same way.
Aurora’s obstruction documentation instructs users to align obstruction geometry with imagery and adjust height using LIDAR. This is a vendor-described modeling workflow, not a guarantee that every remote dataset is current or complete.
For each material estimate, specify what would resolve it. An unclear chimney height may call for a suitable site measurement; a removed tree may require dated confirmation. Have trained personnel use appropriate survey methods and site-access arrangements. A designer should not invent a height to make the production estimate fit the quotation.
Check both geometry and calculation settings
A visible object may not be included in the shading calculation under every setting. Ask which objects cast shade, whether horizon and row shading are enabled, and whether an older manual derate is also applied.
Aurora’s simulation-engine documentation explains the relationship between the enabled shading engine, module irradiance and circuit simulation. Confirm the analogous settings in the tool used for your project; do not transfer one vendor’s behavior to another platform by assumption.
3. Inspect timing and affected modules
Review relevant morning, afternoon and seasonal conditions, then inspect monthly or hourly outputs where available. A shadow animation is useful for identifying the obstruction, while the resource and electrical simulations answer different questions about energy.
Look for recurring shade on one roof plane, a small module group or an entire row. A favorable system average may conceal that pattern. Conversely, one shaded moment does not establish the annual effect without considering its duration and available solar resource.
When reading monthly results, distinguish access percentages from absolute energy. Shorter days can reduce monthly energy even without additional shading. See how to read a solar shade report for Solar Access, TOF and TSRF interpretation; this checklist focuses on the inputs and decisions that come before releasing the layout.
4. Test the actual row arrangement and layout alternatives
Changing the module position, tilt or row spacing can change shade on other modules. HelioScope’s modeling explanation describes the trade-off between closer rows, installed capacity and row-to-row shading. There is no universal instruction to maximize spacing or fill every available gap.
Compare feasible alternatives using the same weather data and other unchanged assumptions. Record the module count, arrangement, modeled annual and relevant time-period AC energy, and any change in equipment or project cost. If electrical configuration changes too, identify it rather than attributing the entire output difference to moving the panels.
| Alternative | Change being tested | Evidence needed to compare it |
|---|---|---|
| Move modules away from a chimney | Reduce exposure to that obstruction | Current geometry and rerun result |
| Increase row separation | Reduce inter-row shading | Capacity change and modeled energy |
| Use another roof plane | Change orientation and exposure | Fit, constraints and comparable simulation |
| Model selective pruning | Evaluate a possible future condition | Permission, realistic scope and separate scenario |
Electrical equipment can affect mismatch losses; it does not erase an obstruction’s shadow. An annual shading percentage alone should not decide optimizer requirements, string topology or safety limits.
5. Keep mitigation separate from the current design
A tree-removal scenario can support a decision, but the customer needs to see that it is conditional. Record who controls the tree, whether the work is permitted, what intervention is proposed and when the geometry will be confirmed. Avoid promising future growth rates or assuming pruning eliminates all shade.
Aurora’s LIDAR cutout documentation explicitly supports both tree-removal scenarios and correcting outdated data. Removing an object digitally therefore needs an explanation: was the object verified absent, or is the report showing proposed mitigation?
Keep an existing-condition model alongside the proposed-condition model until the assumptions are resolved. Identify which scenario supplies the production figure in the offer.
6. Close the site checks and hand off one design revision
Hypothetical coordination example: an aerial model uses an estimated plant-enclosure height. A later survey identifies a different height, and the proposed modules have also moved closer to it. The earlier shade result describes neither the updated geometry nor the updated layout. Update the obstruction, rerun the affected analysis, compare the production result, and reconcile the quotation before release. This is a workflow example, not a claimed customer case.
Use a release record with these fields:
- Project and design revision, with model and evidence dates.
- Material obstructions and whether each is confirmed, estimated or planned.
- Simulation settings and the outputs reviewed.
- Chosen layout and reasons for rejecting the other feasible options.
- Open site checks, their owners and the condition that requires revision.
- Matching report, production forecast and customer quotation versions.
An unresolved preliminary assumption can be visible in a sales discussion without being represented as a confirmed final design. If it could materially alter the offered layout or production, resolve it or explicitly make the offer conditional on that check.
Evaluate the software workflow against your checklist
Bring a current model and your release record when reviewing SurgePV’s shading workflow. Ask which geometry inputs, shading settings, comparisons and export outputs are available for the project. Software output does not establish site accuracy by itself. Discuss those requirements in a demo.
Frequently Asked Questions
Should shading be checked before or after panel placement?
Use an initial obstruction review before placement and check the resulting layout against the current shading model before finalizing it.
What makes a shading result stale?
A changed layout, changed roof geometry, new obstruction information, or changed assumptions can make a prior result stale.
Can one annual shade percentage decide a layout?
No. Review the source data, timing, affected array area, uncertainties, and project objectives alongside the aggregate metric.
Sources
Primary research and reference material used for this desk-research article.
Where this fits
This article is part of SurgePV's Solar Design hub, which works through the topic from first principles to the decisions a project team actually has to make.
