Six Checkpoints for Comparing Result Differences in PVSyst

Table of contents

• Why comparing result differences in PVSyst becomes important

• Checkpoint 1: Are you limiting the variables being compared to one?

• Checkpoint 2: Have you decided in advance which indicator’s difference you are looking at?

• Checkpoint 3: Can you trace where in the loss tree the difference arises?

• Checkpoint 4: Are you avoiding mixing differences in meteorological assumptions and installation assumptions?

• Checkpoint 5: Have you organized differences in string configuration and PCS conditions?

• Checkpoint 6: Are you returning result differences to site conditions for reverse-checking?

• How to translate PVSyst result-difference comparisons into practical decisions

Why comparing result differences in PVSyst becomes important

For practitioners running simulations with PVSyst, the final annual yield and PR numbers are naturally of great interest. However, in real-world design decisions, the real value lies less in the absolute values of a single option and more in how accurately you can interpret the differences between options. This is because yield simulations always rest on many assumptions, and even small changes in those assumptions can alter how the final results look.

In practice, when comparing two options people often rush to decide: this one has a higher annual yield so choose it, or this one has a lower PR so reject it. But that way of looking at things doesn’t tell you why the difference occurred. If it’s unclear whether the cause is azimuth, meteodata, shading assumptions, PCS handling, or the way loss coefficients are set, the quality of the comparison is low.

Being able to read result differences properly also speeds up design improvements. Once you know the reason for a difference, it becomes clear what to review next. Conversely, if you change many settings without understanding why the numbers moved, you won’t know what actually had an effect and the comparison loses meaning. Mastering PVSyst in practice isn’t about producing many variants; it’s about being able to read the meaning of differences even from a small number of variants.

Moreover, the ability to explain result differences is a strong asset in internal presentations and proposals. Saying “the annual yield differs by X kWh” is less persuasive than explaining “changing shading assumptions widened the winter difference” or “changing PCS settings reduced summer output clipping.” Comparing result differences in PVSyst is not just about declaring numerical winners; it is about turning design intent into words.

Checkpoint 1: Are you limiting the variables being compared to one?

The first thing to confirm for a correct comparison of result differences is whether you are limiting the variable being compared to just one. In practice, while improving a design you may inadvertently change azimuth, tilt, PCS, and loss coefficients simultaneously. Comparing two options in that state will show a difference, but you won’t know what caused it. The important aim of comparison is not to find a single “good” option but to keep the situation such that the cause of the difference can be identified.

For example, if you want to see the effect of azimuth differences, you should keep meteodata, module conditions, PCS conditions, shading settings, and loss coefficients consistent. If you want to see the effect of PCS settings, fix the array layout, azimuth, tilt, and shading conditions. This sounds obvious but is easily violated in practice, because when people try to improve an option they tend to change multiple settings at once.

If you change multiple elements at once, you may succeed in improving the numbers but lose reproducibility: you won’t know whether the improvement was accidental or truly due to a specific setting. The strength of PVSyst comparisons is that you can observe how results move when a single variable is changed. To increase comparison accuracy, focus on one variable and keep other assumptions as fixed as possible.

In practice, before creating comparison options it is effective to state in one sentence what you will change and what you will fix in this comparison. If you organize whether this is a shading comparison, azimuth comparison, or PCS comparison in words up front, the meaning of differences will be clearer when you later look at the results. When comparing result differences in PVSyst, careful variable management makes the difference.

Checkpoint 2: Have you decided in advance which indicator’s difference you are looking at?

The second thing to confirm is whether you have decided in advance which indicator’s difference you are looking at. In practice there are many numbers you might care about—annual yield, PR, monthly yield, loss rates, output clipping, etc. As a result, the indicator you examine may change during the comparison and it can become unclear which metric ultimately determined your judgment. To read PVSyst result differences correctly, it is important to decide the primary indicator for the comparison first.

For example, when comparing candidate sites the primary indicator might be annual yield; when reviewing PCS capacity the primary indicators might be PR or output clipping differences. For shading comparisons you might put weight not only on annual totals but also on monthly winter differences. In other words, what you should look at depends on the kind of difference between options. Without that perspective up front, an option that is best by annual totals might show concerning monthly behavior, and you may end up oscillating in your judgment based on different metrics.

Also, deciding indicators up front helps you avoid being distracted by unnecessary information during the comparison. PVSyst displays results from many angles, so many numbers can catch your attention. But if you treat them all with equal weight, the essence of the options becomes muddy. In practice, the important thing is not to collect many numbers but to clarify the indicator that will be the protagonist for this decision and to dig into the reason for its difference.

As a countermeasure, decide before starting the comparison which metric will be the primary indicator. If needed, separate main and auxiliary indicators. For example, you could set annual yield as the primary indicator and PR plus monthly differences as secondary indicators. When comparing result differences in PVSyst, being clear about what you are going to look at prevents decisions from being swayed by the abundance of numbers.

Checkpoint 3: Can you trace where in the loss tree the difference arises?

The third checkpoint is whether you can trace where in the loss tree the difference arises. It is a waste to look only at the final annual yield difference and stop there. If you can see at which stage the difference occurred, the settings that need improvement become much clearer. The loss tree shows how yield is eroded at each step, so it is very effective for locating the origin of differences.

For example, if a large difference appears at the shading-loss stage, the main causes may be the 3D scene, Near Shading, row spacing, or the way building shadows are modeled. If the difference is at the temperature-loss stage, you should review ventilation conditions, array density, or temperature assumptions. If differences appear around wiring or PCS, they may relate to string configuration, DC/AC ratio, or how PCS accepts the inputs. The loss tree reveals such differences that annual totals alone cannot show.

Looking at the loss tree also reveals not just the magnitude but the nature of differences. One option might suppress shading but have larger wiring losses; another might have lower temperature losses but noticeable output clipping. This shows which loss structure is more natural given site conditions. In practice, the option with the highest annual yield is not always the best; it’s important to see which loss structure best fits the site.

As a practice, always go back to the loss tree after seeing result differences and check the items with large differences from the top down. Once you can trace where differences occur, comparison shifts from mere ranking to root-cause analysis. To compare PVSyst results practically, reading differences in loss structure rather than only annual totals is indispensable.

Checkpoint 4: Are you avoiding mixing differences in meteorological assumptions and installation assumptions?

The fourth checkpoint is whether you are avoiding mixing differences in meteorological assumptions and installation assumptions. In practice, when comparing options meteodata sourcing, representativeness of the installation point, azimuth, tilt, and layout conditions can all change at once. Then it becomes unclear whether result differences are meteorological or installation-based. Since both strongly affect PVSyst results, being able to separate them determines comparison quality.

For example, if differences are large only in winter, it might be due to differences in monthly distribution of the meteodata or due to shading and azimuth effects at low solar elevations. If differences appear in summer, they might be due to temperature assumptions or array density and PCS differences. If an option changes both meteo and installation conditions simultaneously, you can’t tell which is dominant. In practice, if causal layers are mixed you will likely incur more rework when trying to find improvement points.

Also, keeping meteorology and installation separate is useful for explanations. If the numbers changed mainly due to meteodata differences but you present them as design differences, the results will be hard to validate later. Conversely, if it’s really an installation-driven difference but you treat it as meteorology, you’ll miss an opportunity to improve the design. To link PVSyst result differences to design decisions, organize whether meteorological assumptions or installation assumptions are driving the result.

As a countermeasure, when creating comparison options separate them into those that fix meteorology and only change installation conditions, and those that fix installation and only change meteorology. Even when monthly differences appear, this separation makes causal layers easier to see. When comparing result differences in PVSyst, do not put meteorology and installation into the same box.

Checkpoint 5: Have you organized differences in string configuration and PCS conditions?

The fifth checkpoint is whether you have organized differences in string configuration and PCS conditions. In practice, when creating comparison options people often think it is enough that the number of modules and PCS capacity are achievable. However, in PVSyst how those elements are grouped has a strong effect on yield, PR, and loss structure. To read result differences correctly you must look not only at capacity differences but at whether the way capacity is allocated and received is natural.

For example, even with the same DC capacity, different stringing approaches change mismatch behavior. An option that forces rows with different shading to be grouped together versus an option that naturally groups like-conditioned blocks can produce annual yield differences. On the PCS side, a slight change in DC/AC ratio can alter the visibility of output clipping, which may appear as summer monthly yield or PR differences. To read differences correctly in practice, organizing these configuration differences is essential.

Differences in stringing and PCS conditions affect both the loss tree and monthly graphs. Even if annual totals are close, large differences in specific seasons or loss items can result from how the system is grouped and handled. If you only compare equipment ratings, you can easily miss these system-level grouping differences.

As a countermeasure, for each comparison option document in words how strings are grouped, how the PCS receives the strings, and the DC/AC ratio philosophy, and then observe how those differences appear in results. This organization is particularly important in projects with mixed shading or temperature conditions; without it your interpretation will be shallow. When comparing result differences in PVSyst, focusing on configuration differences rather than only equipment differences makes the comparison much more practical.

Checkpoint 6: Are you returning result differences to site conditions for reverse-checking?

The final checkpoint is whether you return result differences to site conditions and perform reverse-checking. When PVSyst comparison results look neat, the numbers can seem convincing and you may be tempted to proceed to decision-making. But in practice it is important to confirm that the differences do not contradict site conditions or layout intuition. Even a well-ordered desk comparison can have unrealistic assumptions when examined on site, and conversely a modest-looking difference on paper can be very meaningful in the field.

For example, if differences are large only in winter, check whether obstacles really seem likely to affect those time periods and whether slope or building orientations align with the results. If differences are large only in summer, verify whether ventilation conditions, PCS placement, and perceived array density match site intuition. If your site impressions diverge greatly from PVSyst differences, there may be an input assumption mismatch. Always validate result differences against the site.

Also, this reverse-checking often makes the next improvement steps obvious. You’ll see which rows to shift slightly, which building-shadow models to revise, or which access conditions to adjust. PVSyst comparison results are not only for ranking numbers but also provide information to feed back to the site. In practice, the presence of differences that matter comes down to whether you can return results to the field.

As a countermeasure, after reviewing comparison results always recheck site boundaries, slopes, buildings, access paths, maintenance routes, and existing conditions to confirm whether the differences align with site intuition. If necessary, add comparison options to further narrow where differences are originating. To make PVSyst result differences truly usable, always return to the site at the end.

How to translate PVSyst result-difference comparisons into practical decisions

What ties the six checkpoints together is not treating result differences as mere numerical deltas. Narrow variables, decide the primary indicator, trace differences in the loss tree, separate meteorological and installation assumptions, organize configuration differences, and finally return results to site conditions for reverse-checking. If you can follow this flow, PVSyst comparisons become practical design documents rather than mere simulation outputs.

For practitioners, what matters is not knowing which option is X percent higher. The real value is being able to explain why the difference occurred. If you can distinguish shading differences from temperature differences, PCS handling differences, or meteorological assumption differences, the numerical differences become material for design decisions. If you cannot, even large differences are unlikely to lead to improvements.

Also, strengthening the way you read result differences requires not ending at desk simulations. If site information—site layout, access, slopes, buildings, trees, maintenance routes, existing conditions—is vague, every difference tends to look idealized. To turn PVSyst results into practical outcomes, repeatedly iterate between site understanding and comparison simulations to judge which differences are real and which stem from assumption mismatches.

In that sense, when you want to make site coordinate confirmation and acquisition more reliable, using iPhone-mounted high-precision GNSS positioning devices like LRTK can be effective. If site position data and site-condition documentation are easier to organize, the placement assumptions and obstacle conditions used in PVSyst comparisons become clearer. By improving desk comparison accuracy with PVSyst and supporting site-data accuracy with LRTK, comparing result differences becomes not just a number comparison but a site-grounded design decision process. Carefully interpreting result differences not only improves simulation accuracy but also strengthens the practical capability to connect desk work with the field.