Five basic items when handling terrain and obstacles in PVSyst

Table of contents

• Why handling terrain and obstacles becomes important in PVSyst

• Basic item 1: Gather the site reference information first

• Basic item 2: Organize terrain and obstacles as sources of shading

• Basic item 3: Build the 3D scene without excess or omission

• Basic item 4: View array layout and electrical groupings together

• Basic item 5: Back-check comparison results against site conditions

• A mindset to turn PVSyst terrain and obstacle handling into practical outcomes

Why handling terrain and obstacles becomes important in PVSyst

When performing energy yield simulations in PVSyst, something practitioners often overlook is how to handle terrain and obstacles. Module capacity, azimuth, tilt, and PCS conditions are easy to compare numerically and tend to be the focus of studies, while terrain and obstacles are often treated as just part of the input work. In reality, however, actual energy yield and the feasibility of a layout are influenced not only by the quality of equipment choices but also significantly by how accurately site elevation differences, slopes, retaining walls, adjacent buildings, trees, and similar features are reflected. In other words, handling terrain and obstacles is not a supplementary task but the foundation of the design.

This difference becomes especially apparent in projects that want to make the most of the site. On paper, arrays may look neatly arranged, but in reality the effective area can shrink because of slope crests and toes, drainage strips, access paths, and existing structures. Furthermore, while tighter row spacing can make site utilization look better, terrain conditions and surrounding obstacles can concentrate impacts in certain seasons or times of day, resulting in less annual energy than expected. The point of handling terrain and obstacles in PVSyst is to visualize early the gap between desk-based expectations and site conditions.

Terrain and obstacles affect more than just whether shadows exist. They influence array layout, maintenance access, ease of construction, how strings are grouped, and how to interpret alternative designs. For example, small differences in elevation or obstacle position can change array alignment, and that can cascade into string configuration and PCS handling. As a result, differences in energy yield may appear not simply as terrain or obstacle differences but as differences in the overall system design. If you use PVSyst in practice, terrain and obstacles should be treated not as material for making a 3D scene but as preconditions that link energy yield prediction and design decisions.

This topic is also important for internal explanations and comparison materials. When explaining why a particular layout was chosen, why a given row spacing was used, or why one option’s energy yield is somewhat conservative, having the terrain and obstacle handling clearly organized strengthens the rationale. Conversely, if this is vague, annual energy numbers can take on a life of their own and the proposal’s persuasiveness weakens. Handling terrain and obstacles correctly in PVSyst is not only about improving simulation accuracy but also about shaping design proposals into a form that can be explained.

Basic item 1: Gather the site reference information first

To handle terrain and obstacles correctly, the first task is to gather the site reference information. In practice, people are often tempted to start modeling in PVSyst and begin placing arrays and obstacles right away. However, if site boundaries, the positions of slopes, the locations of slope crests and toes, the position of roads and drainage strips, and where to secure access paths remain unclear, the subsequent 3D scene and layout—no matter how tidy they look—tend to be hard to implement on site. In PVSyst, the initial reference information propagates through all subsequent settings.

For example, if you start placing arrays without distinguishing usable and unusable areas, you may later need to secure edge clearances and maintenance pathways, requiring a full layout redo. Likewise, if you do not understand the general direction and level of terrain, judgments about where to place obstacles, which rows are prone to shading, and which areas to avoid will be inconsistent. When site conditions are ambiguous, the shading simulation results may come out, but it will be hard to interpret what those numbers actually mean.

Gathering reference information is not only about improving model accuracy. It also helps separate provisional conditions from confirmed ones. In practice, you often only know an approximate site extent initially and later update conditions with drawings or site checks. If you have organized which conditions are confirmed and which are provisional, it becomes easier to know what to modify in PVSyst. If this is not done, you may lose track of where differences originate, making comparisons and explanations difficult.

As a countermeasure, before creating 3D scenes or shading conditions in PVSyst, organize site boundaries, slopes, drainage strips, maintenance paths, and the positions of existing equipment on paper or drawings, and predefine usable and unusable areas. You do not need everything perfect from the start, but at least fix the reference information that affects shading evaluation. When handling terrain and obstacles in PVSyst, what matters more than operational skill is whether you can spend time organizing this reference information.

Basic item 2: Organize terrain and obstacles as sources of shading

When dealing with terrain and obstacles, it is important to organize them not as mere background information but as sources of shading. In practice, people may vaguely recognize slopes, retaining walls, buildings, trees, fences, and nearby structures as obstacles and feed them into PVSyst without clarifying which are the primary causes of shading. As a result, you may get loss figures but not know what to improve or what must be accepted.

For example, retaining walls or slopes near arrays can locally affect some rows. By contrast, tall off-site buildings or trees can cast long shadows over wide areas at certain seasons or times of day. Although both appear as “causes of shading,” their design significance differs. The former may be mitigated by rearranging layouts or access paths, while the latter often must be accepted as a precondition. Because PVSyst aggregates these into losses, failing to organize inputs beforehand makes it easy to overlook these differences.

Organizing shading sources also strongly affects how you read alternative options. One option might prioritize suppressing self-shading; another might concentrate arrays in zones less affected by off-site obstacles. Looking only at annual energy differences without organizing this distinction makes it hard to explain which design choices were effective. In practice, what matters more than the percentage of shading loss is understanding which sources those losses originate from.

As a countermeasure, before inputting into PVSyst, divide terrain and obstacles into on-site factors and off-site factors, and then classify them into shading that can be improved and shading that must be accepted as a precondition. Even if you cannot classify everything in detail, identifying the primary shading causes will greatly change how you interpret results. When handling terrain and obstacles in PVSyst, it is important to organize them from the perspective of “what kind of shadow each item creates,” not merely “what exists.”

Basic item 3: Build the 3D scene without excess or omission

When creating a 3D scene in PVSyst, having no excess or omission is more important than extreme precision. In practice, you may try to faithfully reproduce the site and be tempted to include every small obstacle and shape. But including elements that have little effect on shading makes the model overly complex and harder to verify and compare. Conversely, omitting terrain or obstacles that are primary shading causes yields neat numbers that are not useful in practice.

For example, elements that significantly affect shading include slopes and retaining walls near arrays, tall off-site buildings, large trees, and terrain undulations that influence row spacing. These should be prioritized, while small structures that hardly affect shading do not need to be modeled in detail from the start. In PVSyst, practical differences come not from how precisely you can model shapes but from whether you include the elements necessary to estimate shading while avoiding unnecessary complexity.

Also, overly complex 3D scenes weaken the meaning of comparative simulations. If you want to compare options that change row spacing, array orientation, or add paths, but the model’s fine details vary between options, it becomes hard to see what the differences mean. In practice, it is more important to be clear about what you want to compare. Think of PVSyst’s 3D scene not as a tool for producing a beautiful rendering but as a way to organize the main shading causes and clarify the axes of comparison; this perspective makes the appropriate level of detail clear.

As a practical step, model the most important shading sources first, align common elements needed for comparisons, and postpone the details. Prioritize elements that affect shading and omit or simplify those that do not. This approach balances work efficiency in PVSyst with readability of results. What makes a difference in 3D scenes is not the amount of detail but whether the model is designed to address the issues you want to verify.

Basic item 4: View array layout and electrical groupings together

When handling terrain and obstacles, it is also important not to separate array layout from electrical groupings. In practice, people often think about how to place arrays on the site first and then adapt string configurations and PCS conditions afterward. That sequence is natural, but if you stop at layout alone when considering terrain and obstacle impacts, you will not fully understand the significance of shading. Shadows do not only affect layout; the way a layout is electrically grouped changes how shading impacts power generation.

For example, if you force rows that are prone to shading and rows that are not into the same electrical grouping, the meaning of the resulting losses becomes ambiguous. It becomes hard to see which blocks are design weak points and which groupings, if separated, could improve performance. Conversely, if areas with similar terrain and obstacle conditions are grouped naturally, the shading behavior becomes easier to read. Correctly handling terrain and obstacles in PVSyst means thinking not just about placing obstacles but about what electrical groupings the arrays will result in.

Viewing layout and electrical groupings together also makes design revisions easier. If you slightly change a layout to avoid an obstacle, you can simultaneously check how that affects string configuration and PCS reception. Looking only at layout changes can later create infeasibilities in electrical design. Although PVSyst may appear to treat layout and electrical design separately, in practice the boundary is blurred. When thinking from the perspective of terrain and obstacles, it is even more necessary to read both together.

As a countermeasure, when placing arrays, be conscious of which blocks naturally share similar conditions and where it makes sense to cut divisions. Simply avoiding forcing areas with different obstacle or terrain impacts into one grouping will make PVSyst results easier to read. The differences that arise when handling terrain and obstacles are not only in the visual layout but in how naturally that layout maps to the electrical design.

Basic item 5: Back-check comparison results against site conditions

What ultimately makes a difference in handling terrain and obstacles in PVSyst is whether you back-check comparison results against site conditions. When results come out of a desk model, the numbers can look plausible and give a false sense of security. What is truly important in practice is confirming that those results do not contradict the site sense, the spatial relationships of obstacles, slope directions, and access plans. Even if the numbers look neat, if they are weakly connected to site conditions, the results are fragile as a design basis.

For example, if on site the obstacle impacts appear clearly large in the morning but PVSyst shows a small impact, there may be discrepancies in building or tree positions and heights, site boundaries, or how slopes were modeled. Conversely, an apparently large shading loss in a desk model may not be as significant once actual distances and elevation differences are considered. Because PVSyst is a tool that is faithful to its input assumptions, without cross-checking with site conditions, a model can be internally consistent yet lead practice in the wrong direction.

Back-checking also deepens understanding of comparison options. Returning to site conditions to ask why one option shows small terrain impact and another shows strong obstacle impact reveals directions for design revision. You can determine whether to move rows slightly, change path locations, or revisit comparison assumptions. PVSyst comparison results are valuable when used as hints for design improvement.

As a countermeasure, after reviewing simulation results, always compare them against site boundaries, slopes, paths, surrounding buildings, trees, and existing structures to check for inconsistencies. If possible, place multiple options side-by-side to see which differences align with the site sense. The final step needed when handling terrain and obstacles in PVSyst is this back-check that reconnects the desk model with field realities.

A mindset to turn PVSyst terrain and obstacle handling into practical outcomes

A common thread across the five basic items above is not to end with terrain and obstacles as mere input information. Gather site reference information first, organize shading sources, build 3D scenes without excess or omission, view array layout and electrical groupings together, and finally back-check comparison results against site conditions. When you can follow this flow, handling terrain and obstacles in PVSyst becomes not just a modeling task but a practical judgement that supports the feasibility of design proposals.

What matters for practitioners is not just entering terrain and obstacles accurately. It is important to be able to explain, given those conditions, why this layout, why this row spacing, and why this option is chosen. Balancing multiple factors—site utilization, energy yield, constructability, maintainability, and exposure to impacts—is the essence of handling terrain and obstacles. Use PVSyst as a tool to check, compare, and distill that balance into explainable form.

Also, to strengthen terrain and obstacle handling in practice, do not let desk simulations be the end point. If site information such as site boundaries, slope directions, existing structures, surrounding buildings, trees, and access conditions are ambiguous, no matter how well you model things in PVSyst, the assumptions remain weak. A usable simulation in practice is not one that simply yields neat numbers but one that moves closer to assumptions you can accept by iterating with site information.

In that sense, when you want to make on-site position confirmation and coordinate acquisition more reliable, it can be effective to use iPhone-mounted GNSS high-precision positioning devices such as LRTK. When on-site positional information and site conditions are easier to organize, the reference information and layout assumptions for handling terrain and obstacles in PVSyst become clearer. If you can improve desk-based comparison accuracy with PVSyst and support field survey accuracy with LRTK, handling terrain and obstacles shifts from a simple input task to design decisions rooted in the field. Treating terrain and obstacles carefully not only improves energy yield prediction accuracy but also enhances the practical capability to connect desk work and on-site reality.