8 Solar Shading Analysis Mistakes to Catch

A designer opens a roof model and sees a believable morning shadow stretching across two module rows. The annual shading field is already populated, the production case is attached, and the proposal is waiting. One detail is missing: nobody can say whether the tree in the scene came from current site evidence, an older remote model, or a default object copied from another revision.

The shadow may look physically plausible. That does not make the result usable. Shading analysis mistakes often survive because the image, percentage, and annual model each appear reasonable when viewed alone. The defect sits in the relationship between them: wrong identity, undefined output, missing source, duplicate loss, or a revision that no longer describes the released design.

This guide does not rank shading tools or supply a typical loss value. The shading-analysis workflow owns the full process, while the solar-access review checklist owns the detailed simulation checks. Here, the job is narrower. Find eight defects that can bend the expectation away from the modeled question, then repair the record before the result travels downstream.

What does it mean for shading analysis to distort solar expectations?

A shading analysis distorts expectations when a layout, loss field, production model, proposal, or decision gives the result a stronger or different meaning than its sources and method support. The number can be calculated exactly and still mislead if it describes the wrong site, time basis, scene, irradiance component, electrical case, loss boundary, or design revision.

“Distort” does not mean the model must be proven numerically wrong. It means the released interpretation cannot be reconstructed from the retained evidence. A value intended to describe geometric obstruction may be read as annual energy loss. A scene built for early screening may reach a customer as if it reflects field-verified conditions. A corrected tree height may update the visual while leaving the old production run active.

Keep four objects separate:

This distinction matters when teams compare an image, a solar-access display, a shading-loss field, and a modeled production result as though they were interchangeable. Each answers a different question. The reviewer has to preserve the bridge from observed condition to modeled scene, from scene to irradiance treatment, and from irradiance treatment to the exact downstream design case.

The satellite-imagery limitations guide covers what an overhead source may miss. In this article, imagery is one record among several. Even a current, clear image can be used incorrectly if the model attaches it to the wrong structure, omits height, or carries its scene into a later design without review.

What records should exist before a shading result is interpreted?

Before interpreting a shading result, identify the project and surface, source evidence, observation dates, coordinates, time convention, roof and obstruction geometry, vegetation state, horizon, weather or resource source, irradiance method, output definition, electrical case, design revision, model revision, assumptions, limitations, reviewer, release purpose, and every downstream artifact that consumes the result.

Start with the exact output under review. A screenshot in a sales deck, a percentage in a loss table, and a value inside an energy model may share a label while coming from different scenes. Record where the value lives, who exported it, which revision generated it, and whether another application transformed or re-entered it.

Use a source-and-model inventory:

The Sandia PV Performance Modeling Collaborative describes solar position as locating the sun relative to an observer. That general mechanism makes project location and time identity indispensable, but it does not approve a coordinate, time convention, or implementation for a private model.

PVPMC also documents weather-data sources used in PV performance modeling. Preserve the actual file or dataset, provider, relationship to the site, period or typical-year basis, access date, and any transformations. A familiar provider name is not a substitute for the exact source record.

The inventory should expose uncertainty without converting it into a favorable default. If tree height is missing, mark tree height missing. If the remote source does not show a recent addition, state that coverage gap. A reviewer can then restrict the result, request evidence, or accept a bounded preliminary use through the approved process.

Which eight shading analysis mistakes can make the output misleading?

Eight shading analysis mistakes deserve a source-level review: leaving the output undefined, using the wrong project or time identity, modeling stale or incomplete geometry, mixing resource or plane bases, reducing irradiance to a direct-shadow picture, combining or duplicating loss categories, omitting electrical-response context, and comparing or releasing revisions that do not share one traceable basis.

1. The output is precise but undefined

A field labeled “shade,” “solar access,” or “loss” can refer to obstruction at one moment, a ratio over a period, a change in an irradiance component, a model input, or a downstream energy effect. The label does not establish the definition.

Write the metric name, unit, surface, time basis, aggregation, included components, exclusions, method, and downstream use beside the value. PVPMC distinguishes irradiance from insolation: irradiance is a power-per-area quantity, while insolation accumulates solar energy over time. That distinction supports correct terminology, not a private project result.

The repair is not a longer disclaimer under the chart. Repair the field identity in the model and every export consuming it. If the team cannot define the output, hold the claim. Do not rename it with a more familiar term and preserve the same ambiguity.

2. The scene belongs to the wrong site, surface, or time basis

Coordinate swaps, a nearby structure, an unselected roof plane, a detached building, an incorrect orientation, or a time-convention mismatch can generate a coherent shadow for the wrong observer. Visual plausibility is weak protection because many wrong scenes still look like ordinary daylight.

Confirm site identity against the project record, mark the intended surface, and test selected scenes against source evidence. Preserve the location, time convention, scene timestamp, software or method version, and reviewer. If a customer-facing image displays a clock time, the team should be able to explain what that time means in the model without improvising.

Do not use one attractive scene as the release test. The sun-simulation review checklist goes deeper on coordinates, time, horizon, and selected-scene testing. This mistake section owns the identity failure and its downstream restriction.

3. The roof and obstruction scene is stale or incomplete

A roof model can preserve an old tree, miss a new vent, flatten a parapet, simplify a neighboring structure, omit terrain or horizon context, or use a planned roof state without saying so. None of those conditions can be corrected by changing the annual loss field in isolation.

Every modeled object needs a source or a visible assumption. Record its geometry basis, evidence date, confidence state, and owner. Treat vegetation as a condition with observation timing and future-state assumptions, not as a permanent solid whose dimensions never change. Separate current, proposed, inferred, and unresolved objects.

When new site evidence conflicts with the scene, preserve both records. Identify which model objects change, which results reopen, and which downstream files received the earlier state. Silent replacement makes the current model cleaner while destroying the audit trail needed to correct prior use.

4. The resource input and module-plane basis do not match the comparison

Two shading runs can use the same roof geometry and still resist comparison if their weather or resource sources, periods, transformations, orientations, slopes, plane identities, or irradiance methods differ. A side-by-side chart can hide those differences because it places outputs in matching visual containers.

Create a comparison basis before interpreting the delta:

If the purpose is sensitivity testing, change one declared input family and preserve the rest. If several families change, call it a scenario comparison and describe the full difference set. Do not attribute the output change to shading alone.

5. The model turns a direct-shadow picture into the whole irradiance story

A rendered shadow usually helps a reviewer reason about blocked direct light. The image does not, by itself, state how the model treats every irradiance contribution on the module plane. PVPMC describes plane-of-array irradiance with beam, diffuse, and ground-reflected components.

Record which components the shading method modifies, how the selected method represents the sky and horizon, and where the output enters the performance model. Keep that record at mechanism level. This article does not prescribe a transposition method or supply a component value for any site.

The practical warning is simple. Do not convert “this object blocks the sun in this scene” into “this picture is the annual energy effect.” The second statement requires more inputs and model steps than the first. If those steps are missing or unclear, restrict the downstream claim.

6. Shading, soiling, and reflection are combined or applied twice

PVPMC presents shading, soiling, and reflection losses as separate mechanisms. A project workflow may combine fields for a defined purpose, but the combination must remain visible. Otherwise one mechanism can disappear, inherit the wrong assumption, or be applied in both the design tool and the receiving model.

Build a loss-path ledger:

The loss-factor documentation guide owns the broader ledger. For shading QA, trace the shade-related field from its scene and definition through every export and imported model input. Never remove an apparent duplicate until the responsible reviewer confirms that both fields represent the same mechanism and basis.

7. The electrical response is assumed rather than modeled and reviewed

Shade falling on modules is not yet a complete electrical or energy result. The path depends on the represented modules, grouping, equipment, topology, component behavior, model method, configuration, and manufacturer or engineering basis. This page cannot supply a universal response rule for string inverters, module-level power electronics, or another architecture.

DOE describes PV modules as one part of a complete system and discusses mounting, inverters, and power electronics among other elements. Use that as general component context. Use current manufacturer documentation, the approved modeling method, and qualified project review for a specific electrical case.

Record the equipment and electrical scenario that consumes the shading result. If stringing or equipment changes, reopen the relevant model step. Do not keep the same energy interpretation merely because the roof shadow stayed in the same place.

8. The released result cannot be tied to one revision chain

The scene changes, then the layout changes, then the production model changes, then a proposal is regenerated. A common failure is letting one artifact skip a step. The proposal may show the new array image beside a production result from the old scene, or the current model may exist while an older shared link remains active.

Use parent identities, not filenames alone. The shading output should name its evidence and scene parents. The production case should name the shading and design parents it consumed. The released report or proposal should name the model case, approval state, and any conditions that reopen it.

When correcting a released result, preserve the prior artifact and recipients, state the material change where appropriate, restrict unsupported continued use, and issue a linked successor. A quiet overwrite can make the repository look current while leaving the customer, sales team, or reviewer on a stale basis.

How should a team audit and repair a suspect shading result?

Audit a suspect shading result by freezing the released artifact, defining its metric, tracing its parent scene and evidence, verifying solar and resource identities, mapping every loss and electrical step, comparing revisions on a declared basis, correcting the earliest defective object, and releasing a linked successor only after dependent layouts, models, reports, and proposals have been reviewed.

Use this eight-step audit:

1. Freeze the questioned output. Preserve the exact screenshot, field, report, model case, proposal, recipients, and release state. Do not begin by cleaning the current model.
2. Write the output definition. Record metric, unit, surface, time basis, aggregation, included irradiance components, included losses, exclusions, and intended decision.
3. Trace the scene backward. Identify the project, surface, coordinates, source evidence, observation dates, object geometry, horizon, vegetation state, assumptions, and scene revision.
4. Verify solar and resource identities. Check time convention, solar-position method, weather or resource source, period, transformations, orientation, slope, and plane identity.
5. Trace the model forward. Map how the shading output changes irradiance, losses, electrical representation, production, layout choices, and customer-visible artifacts.
6. Compare revisions on one declared basis. State what changed and what stayed fixed. If several input families changed, do not attribute the difference to a single cause.
7. Repair the earliest defective object. Correct, restrict, withdraw, or supersede the source, scene, definition, configuration, model case, or release record that created the defect.
8. Review every dependent artifact. Issue one linked successor with current parent identities, reviewer, limitations, recipients, and re-entry triggers.

Copy-ready shading-analysis audit record

The record is useful only if a reviewer can reopen the named sources. “Verified in software” does not identify the evidence, method, configuration, or owner. Attach or link the approved source objects through the controlled project record instead of pasting isolated screenshots into a quality folder.

How should missing geometry, weather, or electrical evidence be handled?

Missing shading evidence should create a visible unknown, affected-decision list, owner, restriction, and re-entry condition. Do not supply favorable object dimensions, resource inputs, irradiance treatment, loss values, equipment behavior, or field conditions from memory. Continue only with a declared preliminary use that the responsible reviewer accepts, and withhold dependent production or customer claims that require the missing evidence.

Use the narrowest response that still helps the project move:

Do not upgrade an unknown into a conservative number without a defined method and authority. “Conservative” depends on the decision, model, and direction of risk. An assumed tall tree might reduce a modeled output while also steering a layout away from an area that later proves usable. The word cannot replace a documented basis.

Illustrative workflow: a tree record changes after site evidence

This illustrative workflow is not a customer case, field measurement, shade-loss result, production result, savings result, timing result, approval, or product claim.

An early scene contains a tree inferred from remote imagery. The released screening layout and shading report name that preliminary scene. Later site evidence indicates that the tree geometry and condition differ from the inferred object, but the team has not yet accepted a replacement model.

The reviewer preserves both evidence states, marks the affected object unresolved, restricts the earlier shading and downstream production use, and identifies every design, model, report, and proposal that consumed the old scene. A qualified owner decides what evidence is sufficient to revise the object. Only then does the team rerun the dependent cases and issue a successor with an explicit change record.

That response avoids two opposite mistakes. The old result does not remain active merely because it was already sent. The new observation also does not become an accepted model input merely because it appears more recent.

What should a release-ready shading record let another reviewer reconstruct?

A release-ready shading record should let another reviewer reconstruct the analyzed project and surface, source evidence, observation timing, scene geometry, solar and resource basis, output definition, irradiance and loss treatment, electrical case, parent revisions, assumptions, limitations, reviewer, intended use, recipients, and every condition that requires restriction, recalculation, withdrawal, or a linked successor.

Test the record without the original designer’s private memory. Can the reviewer answer these questions?

• Which site, structure, roof plane, module area, or ground area was analyzed?
• Which evidence created each roof, horizon, obstruction, and vegetation object?
• Which objects are current, proposed, inferred, excluded, or unresolved?
• Which coordinates, time convention, solar-position method, and selected scenes were used?
• Which weather or resource source, period, transformations, orientation, and plane basis apply?
• What does each shading or loss output mean, including its unit and included mechanisms?
• Which equipment, electrical grouping, and modeling method consume the result?
• Which layout, production case, report, and proposal revisions are its children?
• What has been reviewed, what remains limited, and what event reopens the result?
• Which recipients hold an older artifact, and how will a correction reach them?

If the record fails one of those questions, classify the consequence. A missing delivery recipient is a correction-control problem. A missing weather file is a modeling-provenance problem. An undefined output is a claim-identity problem. Different failures need different owners, even when the visible symptom is the same percentage.

Measure record quality without inventing an accuracy benchmark. Track outputs that lack a parent scene, scenes with unresolved objects, comparisons with mismatched bases, duplicate loss paths, releases with stale children, restrictions awaiting evidence, and successors that have not reached prior recipients. Review samples against the retained record rather than reporting that fewer questions prove the models are better.

SurgePV’s responsible role in shading analysis

SurgePV can support roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Those functions depend on source evidence, assumptions, equipment models, configuration, and responsible review. They do not establish field conditions, choose the accepted method, guarantee accuracy or production, or replace engineering and external approval.

Use connected software to preserve project, scene, layout, shading, model, and proposal context. Use people and controlled review to decide whether evidence is sufficient, an object is accepted, a method fits the project, an electrical case is represented correctly, or a customer statement may be released.

The SurgePV shadow-analysis page describes the verified product context. Keep each output attached to the inputs and revision that produced it. If evidence changes, reopen the dependent objects instead of editing only the last visible report.

Frequently Asked Questions

What is the most common shading-analysis mistake?

There is no measured universal winner. Start by checking whether the displayed output has an explicit definition, unit, time basis, project identity, design revision, scene revision, weather or resource source, loss-category boundary, electrical treatment, and reviewer. An undefined percentage or color map can be internally consistent while answering a different question from the one the proposal or designer assumes.

Can one shadow screenshot validate a solar shading result?

No. A screenshot can help a reviewer inspect one scene, but it does not by itself establish the site identity, timestamp, time convention, object geometry, weather source, irradiance treatment, annual aggregation, electrical response, or release state. Keep the screenshot as evidence inside a larger reproducible record and obtain field or qualified review when the decision requires it.

Should shading, soiling, and reflection use one loss field?

Only when the chosen method explicitly defines that combined field and the downstream model does not apply any included mechanism again. PVPMC presents shading, soiling, and reflection as separate mechanisms. Record the category boundary, source, method, application point, owner, and downstream consumer so the team can detect omissions and duplicate application without guessing a replacement value.

How should a team handle missing shade-object geometry?

Mark the affected result as restricted, identify the missing object and decisions it can change, request suitable remote or field evidence, and define the re-entry review. Do not silently remove the object, assign a favorable height, or release a precise annual result. A preliminary layout may continue only with a visible evidence state and a bounded use that the responsible reviewer accepts.

Can shading software guarantee a production estimate?

No. Software can help represent roofs, obstructions, sun paths, shade, layouts, and model inputs, but production still depends on source evidence, weather and irradiance methods, equipment representation, electrical treatment, losses, assumptions, configuration, and responsible review. Keep the shading result tied to its exact design and model revision, and never present software output as field verification or external approval.

A believable shadow still needs a chain of custody

The strongest shading review is not the one with the most polished animation. It is the one that lets another person follow the result backward to its evidence and scene, then forward through irradiance treatment, loss categories, electrical context, production, and release. That chain makes disagreement useful because the team can locate the disputed object instead of arguing over a screenshot.

Start with one result already used by another team. Define it, trace it, and find every parent and child. If the chain breaks, restrict the affected claim and repair the earliest defective object. The work may end with the same visible layout. What changes is that the expectation now has a basis another reviewer can inspect.