7 Practical Points for Reflecting Building Shadows in PVSyst

Table of contents

• Why reflecting building shadows in PVSyst becomes important

• Practical point 1: First identify the buildings that cause shadows

• Practical point 2: Do not be vague about building positions and heights

• Practical point 3: Match the distance relationship with the array to reality

• Practical point 4: Observe how building shadows appear by season and time of day

• Practical point 5: Separate partial shading from electrical effects

• Practical point 6: Keep 3D scenes from becoming too complex; focus on the essentials

• Practical point 7: Cross-check results with alternative layouts and on-site verification

• How to turn PVSyst building-shadow assessments into practical outputs

Why reflecting building shadows in PVSyst becomes important

For practitioners running generation simulations in PVSyst, handling building shadows is easy to postpone, yet it is a critical topic that can greatly affect result credibility. Module capacity, azimuth, tilt, PCS conditions, and loss settings are visually easy to compare, so they tend to be examined first. However, in actual sites, building shadows that occur only during certain times of day or seasons can change the apparent annual energy yield and the evaluation of layouts. In other words, building shadows are not a secondary condition but part of the assumptions that determine the validity of system configuration and layout options.

Especially for projects with multiple buildings on site or tall adjacent buildings, how building shadows are handled can change which design proposals are preferable. Even if an array appears to fit visually, long shadows in winter mornings and evenings can reduce generation more than expected. Conversely, layouts that carefully account for shading may seem disadvantaged in terms of number of modules but can be advantageous in annual stability and ease of explanation. The value of reflecting building shadows in PVSyst is that it allows you to grasp early on the gap between an ideal desk-based layout and a layout that actually works.

Also, building-shadow issues are not just a simple matter of whether there is shade. Which building causes the shade, which times of day are affected, and which rows or strings are impacted will change how generation falls. Even a small shaded area can be significant depending on electrical groupings, while a seemingly worrying shadow might have a limited annual effect. PVSyst is a tool to organize those differences—hard to judge by intuition alone—into information that supports design decisions.

In internal reviews and comparison materials, whether the approach to building shadows is well-organized makes a big difference. When explaining why an array was placed here, why row spacing was chosen, or why a proposal’s generation is somewhat conservative, showing assumptions that include building shadows increases overall credibility. Reflecting building shadows in PVSyst is not just about estimating losses; it is about clarifying the basis for the design.

Practical point 1: First identify the buildings that cause shadows

The first thing you should do when reflecting building shadows is to organize which buildings will cause shading. In practice, teams may try to include every visible building on site, or conversely only consider large nearby buildings and omit others. However, what creates a difference in PVSyst is not so much what you modeled as whether you have organized which building is the main cause of shading. Start by listing buildings likely to affect shading and prioritize them.

For example, priority should be given to tall buildings to the south of the array, structures close in the east–west direction, and for rooftop installations the upstands of adjacent roofs, machine rooms, parapets, and roof penthouses or similar structures. On the other hand, trying to include distant low buildings or structures that are unlikely to affect shading based on direction at the outset just increases effort and makes it harder to see the true primary shading causes. PVSyst’s 3D scene can be detailed if desired, but in practice the important thing is to include what is necessary and avoid unnecessary complexity.

Also, building shadows have different meanings for on-site buildings and off-site buildings. If the shade comes from buildings within the site, there may be opportunities to improve the layout by changing array placement or aisle locations. Off-site building shadows, however, often must be accepted as a given. If you look only at shading loss without distinguishing these, problems you can fix and problems you must accept get mixed together, making it hard to see design measures. When reflecting building shadows, you should not only list buildings but also organize what each building means for the design.

As a practical measure, separate candidate shading causes into on-site and off-site, then organize them in order of impact. Also separate building shadows that can be mitigated from those that must be accepted—this makes later comparisons and explanations easier. When handling building shadows in PVSyst, rather than putting in every visible building, the most accurate approach is to first organize which buildings you include and for what purpose.

Practical point 2: Do not be vague about building positions and heights

One major factor that causes differences in building-shadow assessments is how building positions and heights are handled. In practice you may have a general sense of building positions, but height estimates can be vague, or horizontal positions may be slightly off even if you think they’re correct. When you run shading analysis in PVSyst, these small uncertainties can influence when and how shadows appear by time of day and season, and thus have a larger effect than they appear visually.

Be especially careful about entering the heights of adjacent buildings based on intuition. Modeling an adjacent building as only slightly higher than expected can result in more shading than anticipated during winter mornings and evenings. Conversely, overestimating height can lead you to avoid placing arrays where you actually could. Because PVSyst directly reflects position and height in the shadow shape, vagueness here can change not only energy numbers but the ranking of layout proposals.

Moreover, position and height are not useful independently. Understanding the distance and relative position to the array is also important. A building of the same height will have different impacts depending on the distance from the array, and the effect timing varies depending on cardinal orientation even at the same distance. In practice people tend to look at height alone or position alone, but to handle building shadows correctly in PVSyst you need to treat position and height as one set.

As a countermeasure, before modeling building shadows, at a minimum organize baseline position and height information for buildings that are the primary shading causes. Even if you cannot survey everything to perfection, put plausible assumptions in place for the main causes. When reflecting building shadows in PVSyst, don’t be satisfied just to include the building’s existence; ensuring you are not vague about where the building is and how tall it is is what leads to more accurate results.

Practical point 3: Match the distance relationship with the array to reality

When considering building shadows, correctly modeling the building itself is not enough. What matters is matching the distance relationship between the building and the array to reality. In practice there is pressure to fit as much array as possible on the site, but if the separation from buildings is modeled too close or too far, how shadows appear in PVSyst will change significantly. In other words, building shadows are not just a building issue; they are a layout issue.

For example, even if you think you have placed the array sufficiently far from a building, you may later need to secure access aisles or separation conditions, resulting in the array being closer to the building than assumed. Conversely, taking excessive distance from the building reduces site utilization and can make comparison options look harsher than the reality. When dealing with building shadows in PVSyst, build models using a distance relationship that is achievable given site constraints, not a desk-friendly distance.

Distance relationships are also linked to row spacing and passageway layout. Shifting an entire array to avoid building shadows can change row spacing, how edges are left over, and even the access plan. That can affect not only shading but layout efficiency and string configuration coherence. In practice, focusing only on avoiding shading can cause problems elsewhere. PVSyst shows differences because while you seem to be looking at building shadows, you are actually evaluating the balance of the entire layout.

As a measure, before checking building-shadow impact, prepare realistic layout options that reflect building separations, access aisles, edge setbacks, and so on. Evaluate shadows on layouts that could actually be adopted rather than on layouts created solely to avoid shading—this makes results more practical. When reflecting building shadows in PVSyst, remember that the distance relationship between building and array often has a stronger influence on design decisions than the mere presence of the building.

Practical point 4: Observe how building shadows appear by season and time of day

It is risky to finish a shading assessment by looking only at the difference in annual energy. When reading building-shadow impacts in PVSyst, it is essential to look at seasonal and time-of-day biases. Building shadows tend to be stronger in winter and at sunrise/sunset; a difference that looks small annually can be significant in particular periods. Conversely, a worrying building shadow may be limited when viewed annually and acceptable in design terms.

For example, a building to the south tends to have a stronger impact when solar altitude is low in winter, while east–west buildings tend to cause shading biased toward morning or evening. Comparing only annual numbers without looking at these differences makes it easy to misidentify which building is truly important. PVSyst makes it easy to read monthly and time-of-day shading effects, so you should actively use those functions when evaluating building shadows.

Also, looking by season and time changes the priority of mitigation measures. If a shadow occurs only on winter mornings, slightly changing row placement may be sufficient; if a shadow gradually affects generation throughout the year, you may need a more substantial layout change. In practice, when making design decisions, when and where a shadow takes effect is more important than the mere existence of a shadow. PVSyst’s building-shadow simulation is exactly meant to assist that judgment.

As a countermeasure, after evaluating building shadows, always examine seasonal and time-of-day trends in addition to annual values. Determine whether the shading concentrates on winter mornings, appears only in the evenings, or affects a broad period thinly—this helps prioritize layout options and shading countermeasures. When reflecting building shadows in PVSyst, do not conclude based on annual loss numbers alone; reading temporal biases is necessary for practical evaluation.

Practical point 5: Separate partial shading from electrical impacts

A major source of difference when evaluating building shadows is whether visual partial shading and electrical impacts are considered separately. In practice, it is easy to assume that a small amount of building shade will cause only a small drop in generation. However, when dealing with building shadows in PVSyst, if you don’t look at which rows, which strings, and which electrical groupings are affected by the shade, you will misread the meaning of the results. The visible extent of shading alone does not tell you the weight of electrical losses.

Even with similar building shadows, generation declines differ when shading concentrates on parts of a single row versus when it spreads thinly over multiple rows. Furthermore, stringing strategy and sectioning change how far shading effects propagate. The point of evaluating building shadows in PVSyst is not simply to see how much irradiance a building blocks, but to confirm how that blocking affects the electrical system.

This view matters in practice because it changes mitigation directions. If you treat shading as only a matter of shade area, you tend toward a binary choice: move the array away or accept it. But if you view electrical impacts, other design options appear: change string partitioning, rethink how shaded blocks are grouped, or treat arrays near buildings separately. PVSyst is a tool to read building shadows not merely as environmental conditions but as part of system conditions.

As a countermeasure, when reviewing building-shadow results, always check not only the shaded area but which electrical groupings are affected. Doing this reveals whether shading simply makes a proposal less favorable or whether and where design changes are needed. When reflecting building shadows in PVSyst, it is important to read not only building shapes but how the shading propagates electrically.

Practical point 6: Keep 3D scenes from becoming too complex; focus on the essentials

When creating 3D scenes to reflect building shadows, it is also important not to overdo precision and make scenes too complex. In practice, there is a temptation to reproduce building shapes as faithfully as possible, but what really matters in PVSyst is capturing the elements that affect shading without excess or deficiency. If you model fine details that hardly affect shading, you will only increase work time and make comparisons and edits harder.

Especially when comparing multiple proposals, overly complex 3D scenes make it hard to see what differs between them. If you want to examine array-placement differences but the building model details vary by proposal, the axis of comparison becomes blurred. A practical, usable 3D scene is not an elaborate visual model but a model that makes the main shading causes easy to see and organizes the differences you want to compare. PVSyst shows differences not because of detail per se but because of how easy it is to verify.

Also, a complex model makes later updates after site-condition changes heavy. If making small adjustments—revising a building height slightly, moving an aisle, or removing a row—requires rebuilding the entire model, it becomes impractical. PVSyst 3D scenes are not created once and left alone; they are meant to be used for comparisons and revisions. That is why it is more rational to build them focused on what is necessary from the start.

As a countermeasure, prioritize modeling the main shapes that affect shading and defer details. First set the outlines, heights, and relative positions of buildings that strongly influence shadowing, and prioritize ease of comparison and verification. When handling building shadows in PVSyst, creating a model that reads shadows correctly is more important than making a highly detailed 3D model.

Practical point 7: Are you cross-checking results with alternative layouts and site information?

Finally, a key differentiator is whether you reverse-check results using alternative layouts and site information. When PVSyst produces shading simulation results, the numbers can look neatly organized and tempting to accept as is. But in practice, it is safer to confirm validity through relative comparisons with alternative options and by checking against site conditions rather than judging a single proposal by its absolute value alone. Whether this cross-check exists greatly changes how building shadows are handled.

Alternative layouts are useful because by presenting options—wider separation from buildings, slightly different array orientations, different aisle positions—you can see how much shading can be reduced and what is lost in return. Judging single proposals makes it hard to tell whether the loss is large or small. Comparing multiple options clarifies the trade-offs between shading, layout efficiency, capacity, and maintainability. Relative evaluation is indispensable when assessing building shadows in PVSyst.

On the other hand, stopping at comparisons is risky. You must verify that simulation results do not diverge significantly from what is observed on site—building proximity impressions, position relationships, how slopes overlap, and how morning and evening light enters. For example, if the site clearly seems to have long morning shadows but the results show little effect, there may be discrepancies in building height, position, or array settings. Because PVSyst is faithful to its assumptions, it can produce clean but wrong answers if not checked against site information.

As a measure, for projects where building shadows are a concern, always create multiple layout options and then check for inconsistencies against site conditions. Organize the meaning of differences via comparison, and use on-site verification to confirm whether those differences are reasonable. This two-step approach turns building-shadow assessment from desk numbers into design judgment. What distinguishes careful handling of building shadows in PVSyst until the end is this thoroughness of verification.

How to turn PVSyst building-shadow assessments into practical outputs

What the seven practical points above have in common is that building shadows should not be treated as mere environmental losses. Organize buildings that cause shadows, avoid vagueness in position and height, match the distance relationship with arrays to reality, read seasonal and time-of-day biases, separate partial shading from electrical impacts, set 3D scenes to the necessary precision, and finally cross-check with alternative layouts and site information. If you follow this flow, PVSyst’s building-shadow assessment becomes not a supplement to generation simulation but information that demonstrates the validity of the layout design itself.

For practitioners, the goal is not only to minimize building shadows. The real value is being able to explain how far shadows can be reduced, which shadows must be accepted, and why a particular layout is selected. Among multiple objectives—improving site utilization, maintaining constructability, ensuring maintainability, and securing generation—the way you handle building shadows affects design quality. PVSyst should be used as a tool to organize that complex balance numerically and by condition.

Also, improving the accuracy of building-shadow assessments requires not ending at desk simulation. If building positions, heights, site boundaries, slopes, aisles, and existing equipment are ambiguous, the simulation assumptions become weak. To use PVSyst results practically, you need to iterate between site understanding and the 3D scene to continually confirm the meaning of building shadows. Shadows in the model are shadows of the site itself.

In that sense, when you want to improve on-site position confirmation and coordinate acquisition, using high-precision GNSS positioning devices that mount on an iPhone—such as LRTK—can be effective. If on-site positional data and site conditions are easier to organize, the layout assumptions and building conditions used when reflecting building shadows in PVSyst become clearer. If you can raise desk comparison accuracy with PVSyst and support field-accuracy with LRTK, building-shadow assessment becomes not just a check of shading losses but a field-rooted design judgment. Carefully evaluating building shadows not only improves generation forecast accuracy but also strengthens the practical capability that connects desk work and the site.