6 Steps to Compare Differences Between Projects in PVSyst

When you want to compare multiple projects using PVSyst, simply lining up numbers such as energy generation or loss rates does not always lead to actionable decisions in practice. This is because differences between projects arise from a combination of factors: site conditions, weather, equipment configuration, shading effects, loss settings, design policies, and more. To compare correctly, you must first standardize the assumptions, then organize the comparison axes, and decide the order in which to interpret the results.

In practice, PVSyst’s comparison features and the ability to view multiple simulations side-by-side are important in scenarios such as prioritizing candidate sites, comparing design proposals within the same project, or organizing the basis for estimates and proposals. If you get the comparison method wrong, you may make an otherwise advantageous option look unfavorable, or conversely overestimate an option with lax assumptions.

This article organizes and explains the key concepts to keep in mind when comparing differences between projects in PVSyst in six steps. It walks through preparing for comparison, unifying assumptions, deciding comparison axes, interpreting results, cautionary points, and how to apply the results in practice. If you plan to evaluate multiple projects or want to use comparison results for internal explanations or customer proposals, please refer to this guide.

Table of Contents

• Why project comparisons in PVSyst become important

• Step 1: Decide the purpose of the comparison first

• Step 2: Organize and prepare the conditions of the comparison targets

• Step 3: Unify the assumptions so the items can be compared

• Step 4: Decide the comparison axes and standardize the viewing order

• Step 5: Correctly read the differences in simulation results

• Step 6: Use comparison results in a way that leads to practical decisions

• Common mistakes and caveats in project comparison

• Ways of thinking to streamline comparison work

• Summary

Why project comparisons in PVSyst become important

PVSyst is not simply a tool for calculating energy generation. It is also a tool for examining, while changing multiple conditions, which option is more rational. In solar PV projects, even if the rated capacity looks the same, results can differ greatly depending on land conditions and equipment configuration. Conversely, if you standardize equipment conditions across different locations, you can more clearly see differences due to site. By consciously deciding what to fix and what to vary, the meaning of the comparison becomes clearer.

In practice, the targets you want to compare fall broadly into two categories. One is comparing different projects with each other—e.g., when you have multiple candidate sites and want to determine which land is more promising. The other is comparing design proposals within the same project—e.g., changing tilt angle, altering string configuration, or rearranging shading countermeasures. Though similar, the emphasis differs slightly between these two types.

When comparing different projects, site and weather differences have a large impact, so a key question is how much of the natural differences to accept as-is. When comparing design options within the same project, weather and land conditions are the same, making it easier to isolate differences in equipment and design policy. If you compare both types with the same mindset without understanding this difference, you can easily misinterpret results.

Project comparisons also directly affect decisions both inside and outside the company. Internally, they are used for deciding development priorities, setting design policies, and reexamining quotation conditions. Externally, they are used for explaining to clients, supporting investment decisions, and backing up proposals. In other words, PVSyst comparison results are not just technical evaluations; they are important information related to business decisions and accountability. Therefore, the comparison approach must be reproducible and explainable.

Step 1: Decide the purpose of the comparison first

The first thing to do in project comparison is not to decide which numbers to compare, but to decide why you are comparing. If the purpose is unclear and you start comparing, the comparison axes can drift, or you may cherry-pick convenient figures.

For example, what you should focus on depends on whether the purpose is site selection, design optimization, or investment decision. For site selection, you need to evaluate not only annual energy and specific yield but also terrain conditions, shading effects, and construction difficulty. For design optimization, design-centered perspectives such as the breakdown of losses, alignment with the PCS, and string feasibility are important. For investment decisions, in addition to energy, the reliability of assumptions and whether settings are conservative are important.

Deciding the purpose also makes it easier to determine what to fix and what to vary. If you want to evaluate site superiority, standardize equipment conditions; if you want to compare equipment configurations, standardize weather and site conditions. Without this organization, differences due to site and design will mix, and you won’t know which one drives the results.

Also be mindful from the start who you will explain the comparison results to. How you summarize results differs if you explain them to internal technical staff, sales, customers, or investors. Technical staff need loss breakdowns and assumption differences; decision-makers need concise conclusions and main causes. Interpretation and communication are often harder than calculation, so designing with the intended audience in mind is important.

Writing down the comparison purpose reduces ambiguity in the work. For example: “The purpose of this comparison is to prioritize three candidate sites; equipment configuration will be standardized; evaluation metrics are annual energy, specific yield, loss tendencies, and shading influence.” Organizing it this way prevents the work from drifting. Clarifying the purpose is the first step to succeed in PVSyst comparisons.

Step 2: Organize and prepare the conditions of the comparison targets

Once the purpose is decided, next organize the conditions of the projects or proposals to be compared. The precision of this preparation greatly affects the accuracy of the comparison. Don’t wait until you input data into PVSyst to look for differences; do the condition organization first.

First, organize site-related conditions: location, irradiation conditions, availability of meteorological data, elevation, surrounding obstructions, and terrain slope direction. Even within the same region, shading patterns and temperature conditions vary depending on terrain and surroundings. When comparing candidate sites, you need to clarify not just different addresses but how the conditions that affect generation differ.

Next, organize equipment conditions: module capacity, number of modules, PCS capacity, string configuration, tilt angle, azimuth, racking conditions, and initial loss-setting policies. It is important to list what is the same and what differs for each comparison target. When creating separate projects in PVSyst, it is easy to lose track of what was changed. Preparing a list that separates fixed and variable conditions in advance makes interpreting comparison results easier.

Also verify the quality of the input data used for comparison. If meteorological data sources differ, shading data precision differs, or the basis for loss rate settings differs, you can’t tell whether result differences come from project differences or input quality. Especially when comparing multiple projects in a short time, the diligence of data entry may vary across projects. If you compare while this variation remains, you can’t achieve a fair evaluation.

In practice, creating an organization sheet for comparison is useful. It doesn’t have to be a table; text is fine. For each project, list site conditions, equipment conditions, common conditions, undecided items, and assumed conditions to improve transparency. When asked to explain PVSyst numbers after the fact, this organization will serve as supporting evidence.

At the preparation stage, don’t force undecided items to be fixed. In practice, information is often incomplete in early stages. In such cases, clearly state which items are undecided and adopt common assumptions for comparison. The important thing is not to input ambiguous values, but to visualize assumptions and compare under those visible assumptions.

Step 3: Unify the assumptions so the items can be compared

The most important aspect of project comparison is unifying the assumptions. Whether the comparison results are persuasive is largely decided at this stage. Lining up numbers is easy, but making them comparable requires care.

First, decide which items are excluded from the comparison. For example, if you want to see differences between candidate sites, keep equipment configurations as identical as possible. Standardizing module type, PCS approach, initial loss values, and azimuth approach makes site-derived differences easier to see. Conversely, if you want to evaluate equipment proposals, keep meteorological data and site conditions identical. Ambiguity about what is fixed leads to misaligned comparison targets.

Next, unify input rules. For example, decide whether you will apply a uniformly conservative assumption for shading when conditions are unknown, or treat unmodeled shading as excluded from the comparison. If judgment criteria differ by project, results can incorporate subjectivity. When the amount of site information differs among projects, unifying input rules becomes even more important.

Also align how losses are set. If wiring losses, soiling, mismatch, temperature conditions, and utilization assumptions differ across projects, result differences may reflect differing modeling philosophies rather than design superiority. Of course, there are cases where certain loss items should legitimately vary due to project characteristics; in such cases, document why they were changed.

A commonly overlooked point in assumption unification is differences in project maturity. If one project has detailed site surveys and another only initial desk-study values, the latter may appear better. This is a common practical phenomenon where increased detail can reveal stricter conditions. In such cases, don’t just compare numbers; consider differences in information confidence as well.

When comparing in PVSyst, a stable approach is to base new cases on a duplicated set of assumptions. Choose a base project and create variants by changing only the differences, making it easy to track what was changed. Starting from scratch for each project can cause multiple unnoticed discrepancies. Differential management of assumptions is crucial for simulation comparisons.

Step 4: Decide the comparison axes and standardize the viewing order

After aligning assumptions, decide what to compare. Don’t increase the number of comparison axes too much. PVSyst outputs many figures, but treating them all equally makes decisions harder. Choose main axes that match the comparison purpose.

Fundamental metrics are annual energy and specific yield. Annual energy conveys the overall scale but includes differences in installed capacity. Specific yield (energy per capacity) shows per-capacity efficiency and is suitable for pure performance comparisons. Which to use depends on the purpose, but in practice it is useful to look at both to separate scale from efficiency.

Next, the breakdown of losses is important. Looking only at final generation differences doesn’t tell you why they occurred. By tracing whether the difference stems from weather, temperature losses, shading, or PCS constraints, you can distinguish differences that can be improved from those that are hard to change. This turns a simple comparison into one that informs improvement proposals and design adjustments.

Monthly trends are also important. Annual totals can understate differences that are pronounced in specific seasons—e.g., winter shading impacts or summer temperature losses. Viewing monthly trends helps identify operational characteristics or revenue skewing that annual values hide.

Comparison axes should include not only quantitative values but also the stability of assumptions. Even if a case shows higher generation, overly optimistic assumptions may make it impractical. Conversely, a slightly lower but well-founded, conservative case may be easier to get approved internally or explained to clients. Comparison is not about finding the maximum value but about finding a reasonable option relative to the purpose.

Standardizing the viewing order also aids interpretation. A recommended flow is: first view overall results to grasp the magnitude of differences; then check the loss breakdown to confirm causes; afterward check monthly trends and assumption differences. Starting with details risks losing the big picture, while stopping at annual values leaves the cause analysis shallow. Fixing the order improves reproducibility of the comparison process.

Step 5: Correctly read the differences in simulation results

Once the comparison axes are set, read the results. The most important distinction to make is between a difference existing and a difference being meaningful. PVSyst will always show numerical differences between projects, but not all of them are relevant to practical decisions.

First, consider not just the absolute difference but the cause. If annual generation differs, determine whether it’s due to inherent weather differences or design-improvable factors. The former should be accepted as a site characteristic; the latter should be treated as potential for design change. Use comparison results not only for ranking but to identify whether actionable measures exist.

Next, separate causal factors one by one. Even if Project A yields more energy, the reason may be a combination of factors—slightly better irradiation, less shading, and marginally better temperature conditions. Drawing conclusions from a single factor can lead to misreading the scope for improvement. PVSyst comparisons require looking at aggregate results and then decomposing causes.

Also evaluate differences in relation to project scale. In large projects, a small percentage difference can translate into a large absolute amount. Conversely, in small projects, a large percentage difference may have limited practical impact. Don’t equate result differences directly to quality; include project scale, business viability, and ease of explanation in your judgment.

Remember that simulation results are estimates based on assumptions, not definitive values. A common pitfall is overemphasizing small differences. When input assumptions or site information accuracy is uncertain, deciding priorities based on marginal differences is risky. In early-stage studies, capturing the direction of difference and main causes is often more valuable than ranking small deltas.

A helpful way to interpret results is to be able to state the conclusion in one sentence. For example: “Project A outperforms Project B in annual generation; the main causes are irradiation and shading differences, and with equipment constant there is limited room for improvement.” If you can form such a sentence, the numbers and interpretations connect and the comparison becomes easier to explain.

Step 6: Use comparison results in a way that leads to practical decisions

PVSyst comparisons don’t end with producing numbers. Ultimately, you must convert comparison results into usable decision material. Important here is not just listing results but translating them into a form that supports decisions.

For candidate site comparisons, don’t simply list annual energy in descending order. Organize by energy, contributing factors, confidence in assumptions, and whether there’s scope for design changes—this makes prioritization easier. For design proposal comparisons, combine energy differences, loss differences, technical feasibility, constructability, and ease of explanation to clarify which proposal to adopt.

Also treat comparison results as an iterative basis for study, not a one-off final. If the initial comparison reveals major contributing factors, re-run focused comparisons on those factors for higher-precision decisions. For example, if shading is influential, improve the shading model’s precision and reassess; if PCS constraints matter, try different capacity allocations. Comparison is not a single evaluation but a process for refining design.

How you present the results matters. Simply showing PVSyst screens or outputs may not convey the message to stakeholders. Organize presentations by comparison purpose, unified assumptions, differing items, main differences, and conclusion so non-technical audiences can understand. Rather than presenting many numbers, clearly show where differences come from and what decision points are.

Project comparisons can also drive future standardization. As you compare multiple projects, you’ll identify items that repeatedly cause differences or create confusion. Incorporating those into your company’s comparison templates and input rules raises the quality of future comparisons. PVSyst comparison work is useful not only for one-off studies but also for improving reproducibility of design workflows.

Common mistakes and caveats in project comparison

There are several typical mistakes in project comparison. The most common is comparing results while overlooking assumption differences. Even subtle differences in module conditions or loss settings change outcomes. The person who entered the data may think everything is the same, but discrepancies often creep into the details. Always check what is common and what differs before comparing.

Another common mistake is deciding superiority based only on annual energy. Annual values are easy to understand but can lead you to skip factor analysis. If there’s a difference, determine whether it’s improvable or inherent to the site. Skipping this step can lead to misdirected improvement efforts.

Misattributing differences caused by input quality to project differences also occurs. Detailed-survey projects tend to reflect stricter conditions, while early-stage projects tend to be more optimistic. Ignoring maturity differences leads to comparing the incomparable. In practice, incorporate information confidence into your evaluation.

Having too many comparison axes can also prevent conclusions. You can examine energy, loss rate, monthly trends, temperature, shading, design flexibility, and more—but treating all of them with equal weight complicates decision-making. Clarify the objective and narrow the primary axes.

Finally, don’t treat comparison results as absolute. PVSyst is a powerful tool but depends on input assumptions. Especially in early stages, the value lies more in understanding the structure of differences than in numerical precision. Avoid overconfidence in marginal differences; identify main causes and be prepared to reexamine assumptions.

Ways of thinking to streamline comparison work

When dealing with multiple projects, starting from scratch each time is time-consuming. So think about streamlining the comparison work itself. A useful first step is to have common rules for comparison: which items to fix, how to assume undecided items, and which indicators are main comparison axes. Predefining these reduces project-by-project variability.

Next, operate by duplicating a base project and changing only differences. This prevents omission and misalignment of settings. In comparison work, it’s more important to clearly record what changed than to create something new each time. A record of differences makes it easier to respond when asked to explain later.

Fixing the order of viewpoints when reading comparison results also increases efficiency. If you always review overall results, loss factors, monthly trends, assumption differences, and then the conclusion, you will overlook less. As the number of projects grows, formalizing the checklist reduces reliance on individual intuition.

Comparison accuracy also improves by linking with field and design information. If drawings, location data, shading info, and surrounding conditions are organized, PVSyst comparisons become more stable. Conversely, when site conditions are vague, no matter how carefully you simulate, the persuasive power of comparisons weakens. Streamlining comparison work requires organizing the upstream information as well as PVSyst itself.

Summary

Comparing differences between projects in PVSyst requires more than just lining up multiple results. First clarify the comparison purpose, organize the conditions of the comparison targets, unify assumptions, and set appropriate comparison axes. Then carefully interpret the causes of result differences and organize them into a form that supports practical decision-making.

By following the six steps presented here, you can greatly improve the accuracy and explanatory power of comparisons. Key points are careful preparation, visualizing assumption differences, checking not only annual values but also loss factors and monthly trends, and summarizing conclusions in a way that leads to practical decisions. PVSyst comparison is not merely number checking; it is a crucial process for raising the quality of design and project decisions.

Improving comparison accuracy also requires not only desk simulations but precise field and location information. If candidate site understanding, installation point confirmation, and surrounding environment organization are insufficient, the reliability of comparison results declines. Therefore, building a system to capture site information accurately before and after simulation is important.

In this regard, LRTK (iPhone-mounted GNSS high-precision positioning device) is a good fit as a means to support organizing comparison assumptions by improving on-site position confirmation and positioning accuracy. If you can better clarify candidate site location data and installation conditions, you can ensure more consistency in PVSyst comparisons. If you want to improve not only simulation precision but also the accuracy of the underlying site information, consider using LRTK as well.