7 Common Input Mistakes in PVSyst and How to Prevent Them

Table of Contents

• Why input mistakes easily occur in PVSyst

• Input mistake 1: Proceeding with the project while its assumptions remain ambiguous

• Input mistake 2: Entering data without verifying consistency between the site and meteorological conditions

• Input mistake 3: Setting azimuth and tilt divorced from on-site conditions

• Input mistake 4: Running calculations without ensuring consistency of the system configuration

• Input mistake 5: Oversimplifying shading conditions to the point of disconnect from reality

• Input mistake 6: Setting loss conditions too optimistically

• Input mistake 7: Failing to notice input mistakes due to insufficient review of calculation results

• A mindset to connect PVSyst input accuracy to practical-quality work

Why input mistakes easily occur in PVSyst

While PVSyst is convenient for practical photovoltaic studies, it has many input items and strong interdependencies between conditions, so small assumptions can easily affect the overall results. Not only beginners but also moderately experienced users sometimes input settings based on impressions from past projects and fail to notice deviations in assumptions. In other words, input mistakes in PVSyst often arise less from simple typing errors and more from inadequate organization of conditions or skipped verification steps.

In practice, it is not uncommon to be asked for rough estimates at an early project stage. There are many situations where multiple candidate sites exist and design conditions are not finalized, yet simulations are run to get an initial sense of direction. In such situations, using provisional assumptions is not a problem per se, but if you input data without clarifying what is provisional and what is confirmed, the meaning of results becomes unclear later. Input mistakes are more likely to occur when insufficient information is left unaddressed and calculations proceed regardless.

Also, because PVSyst tends to reflect entered conditions directly in the results, the quality of input largely determines the quality of the output, for better or worse. Even if the numbers look attractive, if they are not based on correct assumptions they become difficult to use in practical work. Conversely, knowing common mistakes at the input stage helps reduce rework from the start and produce simulations that can withstand internal review.

Here we organize seven common PVSyst input mistakes, explain the causes and countermeasures from a practitioner’s perspective. Rather than simply listing error-prone spots, we go deeper into why the mistakes occur and how to prevent recurrence.

Input mistake 1: Proceeding with the project while its assumptions remain ambiguous

A common initial mistake in PVSyst is starting to input data without sufficiently organizing the project’s assumptions. It is not unusual to begin work after only naming the project, and later, after capacity, site conditions, or design policy change, no one knows what the simulation was originally based on. This is less an operational error and more an input mistake caused by inadequate project organization.

In practice, multiple proposals often run in parallel for the same project: options with different capacities, different layout concepts, proposals prioritizing constructability or maximizing generation, etc. Unless differences between proposals are made explicit, numbers can easily be taken out of context later. In PVSyst, if you do not create a state in which it is clear which proposal you are calculating, the inputs may be correct yet the basis for comparison will collapse.

The countermeasure is to clarify the project objective before inputting data. Simply deciding whether the simulation is for a rough feasibility check, layout comparison, or a near-detailed study clarifies how deep the inputs need to be. Managing provisional and confirmed conditions separately makes it easier to track which values should be updated when conditions change.

Additionally, standardizing rules for PVSyst project names and proposal organization helps prevent recurrence. If you manage proposals so their differences are visible, you are less likely to be confused when you revisit them later. Before carefully entering numbers, first organizing assumptions is the most basic and effective measure.

Input mistake 2: Entering data without verifying consistency between the site and meteorological conditions

Another common mistake is entering data without sufficiently confirming consistency between the site and meteorological conditions. Proceeding based on a rough regional impression or reusing similar conditions without acknowledging differences between candidate sites shifts the foundation of generation estimates. Since this part forms the basis of the entire simulation in PVSyst, no matter how carefully you adjust later settings, an incorrect starting point reduces result reliability.

Practitioners often treat site conditions as mere location information. However, the installation site affects not only generation but also seasonal trends, temperature impacts, and the validity of design policies. Even if candidate sites are geographically close, different understandings of on-site conditions can change result interpretation. Especially when creating comparative proposals, if site conditions are not handled uniformly you might end up comparing differences in assumptions rather than design choices.

The countermeasure is to treat site confirmation as part of the initial input and not take it lightly. For each project, clearly define which site is the reference and which environmental conditions are assumed. When comparing multiple proposals, align how you handle site and meteorological data as much as possible so differences unrelated to the point of comparison do not creep in.

Also, when results seem odd, it is effective practice to review the assumptions about site and meteorological conditions before checking equipment or losses. PVSyst draws attention to numerical results, but unexpected high or low generation can hide differences in understanding of site conditions. Treating site conditions carefully not only improves input accuracy but helps avoid misreading results.

Input mistake 3: Setting azimuth and tilt divorced from on-site conditions

A frequent PVSyst input mistake is leaving azimuth and tilt at ideal values without aligning them to on-site conditions. When there is a desire to make calculated generation look as high as possible, there can be a tendency to assume orientations or tilts that are impractical to achieve. But such simulations won’t reflect reality and may require major revisions later.

In practice, you often cannot adopt ideal installation conditions because of land shape, earthworks, slope directions, constructability, surrounding environment, and other constraints. Still, if you assume the most favorable conditions on a desktop, the figures may look good but the design will be unstable. PVSyst requires assumptions that are reasonable for the project, not the absolute maximum. In other words, azimuth and tilt should be set based not only on efficiency but also on actual site constraints.

The countermeasure is always to check correspondence with on-site conditions when inputting azimuth and tilt. If you can explain why you chose a particular azimuth or tilt, it makes later judgments easier when looking back at results. When creating comparative proposals, decide whether you want to see how azimuth and tilt differences affect results or whether you want to compare other variables.

Also, azimuth and tilt relate to shading and layout conditions. If you input them independently without awareness of those links, apparent consistency can mask contradictions in the overall setup. In PVSyst, being mindful of interlinked conditions is more important than preventing simple errors. Not divorcing azimuth and tilt from on-site conditions is a shortcut to simulations that are useful in practice.

Input mistake 4: Running calculations without ensuring consistency of the system configuration

Input mistakes regarding system configuration are also very common. If you decide the capacity first and proceed, or if management of configuration conditions becomes vague while comparing multiple proposals, you can end up with numbers whose underlying assumptions are unclear. Because system configuration directly affects results in PVSyst, a lack of consistency here directly undermines simulation reliability.

What is difficult for practitioners is that information is often incomplete at the project’s initial stage and configurations tend to be provisional. A provisional state itself is not the problem; the problem is treating provisional values as if they were confirmed. A common PVSyst mistake is copying settings from a previous project and thereby leaving configuration parameters that do not match the current project. That leaves results whose improvement points are hard to discern.

The countermeasure is to first create a basic configuration that is reasonable given the project objective when entering system parameters. It is more practical to clearly indicate which parts are provisional and which are confirmed, and to adjust iteratively than to try to perfect every detail from the start. For comparative proposals, align configuration parameters not under investigation so it is easier to interpret the causes of differences.

Also, when results feel off, instead of focusing only on the final numbers, return to check whether the system configuration is natural. PVSyst makes it easy to trace relationships between inputs and results, but if configurations are vague you won’t see clear directions for correction. Carefully confirming configuration consistency is essential not only to prevent input mistakes but also to identify improvements from the results.

Input mistake 5: Oversimplifying shading conditions to the point of disconnect from reality

Oversimplifying shading conditions is another frequent PVSyst input mistake. Judging that a wide site must be fine or that few tall objects nearby means there’s no issue, and estimating shading impact shallowly, can make annual generation look better than reality. Pay special attention on projects with restrictive site conditions, where shading treatment can significantly change results.

In practice, wanting to use area efficiently can encourage narrowing equipment spacing. But if that choice doesn't account for shading effects over the year, you may later need to revise generation estimates or layouts. Because results change character depending on how shading is reflected in PVSyst, this is an item to consider carefully from the initial stage.

The countermeasure is to think about shading not only as present or absent but in terms of which time slots and seasons it will affect and to what extent. You do not need excessive detail for every project, but for those where shading is a concern, cautious treatment from the start reduces rework. When comparing proposals, check that only the proposals intended to differ have different shading assumptions.

Additionally, shading input mistakes can show up as oddities in the results screen. If monthly drops or differences between proposals look unnatural, suspect overlooked shading conditions. Even if PVSyst shows shading impact as small, if that diverges from on-site intuition it’s worth rechecking. Treating shading carefully improves accuracy and helps select designs with higher feasibility.

Input mistake 6: Setting loss conditions too optimistically

Input mistakes regarding loss conditions are also very common in PVSyst. With a desire to estimate higher generation, people tend to set losses lower than realistic or downplay items that are significant in practice. While that produces attractive numbers, it does not yield simulations close to reality. If you intend to use PVSyst results in practice, think in terms of reasonable values, not ideal ones.

In practice, loss conditions are often set roughly at the project’s early stage. That alone is not bad, but it is risky to use rough values as the basis for decisions. Especially in projects that tend to face tighter conditions as design progresses, initially optimistic loss settings make later explanations difficult when numbers fall. A typical PVSyst mistake is carefully entering equipment data but leaving loss values idealized.

The countermeasure is not to make loss settings stricter per se but to aim for values closer to practical expectations. Even when using provisional values according to project stage, ensure you can explain why you chose them so that later corrections are easier to organize. When comparing multiple proposals, confirm the consistency of loss assumptions so evaluations do not fluctuate by proposal.

Moreover, when reviewing results, habitually checking not only the final generation but where and how much losses occur makes optimistic loss assumptions more apparent. PVSyst makes losses easy to visualize, so use that strength to validate input values from the results. Avoiding optimistic loss settings is crucial to maintaining simulation reliability.

Input mistake 7: Failing to notice input mistakes due to insufficient review of calculation results

Finally, a common issue is failing to thoroughly review results after inputting data and thus missing input mistakes. Because PVSyst shows results immediately after input, people can become complacent by looking only at annual generation. However, the results screen is not merely the end point but an important place to verify whether inputs were appropriate. If you don’t review it carefully, small input deviations will remain.

In practice, due to deadlines or workload, running a calculation can be treated as a milestone. But what really matters is confirming that the results align with project expectations. If you only look at annual generation without checking monthly trends, unnatural drops, how losses appear, or reasons for differences between proposals, you are likely to miss input mistakes. In particular, when numbers look too good, adopt a skeptical stance and check for optimistic inputs or oversights.

The countermeasure is to predefine post-calculation check items. Decide an order for reviewing assumptions, annual value reasonableness, monthly distribution, loss breakdown, and differences between proposals to reduce omissions. Even for a single proposal, slightly varying conditions and observing result changes helps detect input anomalies.

In addition, don’t rely solely on individual judgment for result review—establish simple internal check rules. If minimum checks are standardized, you reduce person-dependent oversights. In PVSyst, repeatedly checking inputs and results rather than treating input as final connects to practical-quality work. Insufficient result review is not just a final-step issue but a serious mistake that affects overall input accuracy.

A mindset to connect PVSyst input accuracy to practical-quality work

The seven input mistakes covered so far stem not from simple operational slips but from insufficient organization of assumptions and omitted verification steps. Issues such as ambiguous project conditions, inconsistencies between site and meteorological data, optimistic azimuth and tilt settings, configuration mismatches, overlooked shading and losses, and insufficient result review may seem independent, but in reality they interact. One mistake can blunt other checks and distort interpretation of the final result.

For practitioners, the important thing is not to eliminate all input mistakes perfectly but to build a workflow that detects mistakes quickly when they occur. Given the many input items in PVSyst, rather than aiming for perfection in a single run, it is easier to work iteratively: organize assumptions, run calculations, review results, and revise as needed. Thus, improving input accuracy means not only careful data entry but organizing projects so they are easy to review.

Furthermore, raising PVSyst input accuracy in a meaningful way requires not confining effort to desk work alone. If on-site understanding is insufficient, inputs remain unstable—whether it’s understanding the site, grasping site geometry, validating azimuth and tilt, or assessing potential shading. No matter how carefully you input data in software, ambiguous field assumptions limit result reliability.

In that sense, when you want to efficiently confirm positions and coordinates on site, using high-accuracy GNSS positioning devices that can be attached to an iPhone, like LRTK, is an effective approach. If it becomes easier to organize positional information and site conditions obtained in the field, the accuracy of PVSyst inputs improves before you enter them. Creating a workflow that combines PVSyst simulations with LRTK-supported site surveys reduces mismatch between desktop input and on-site reality. The essential way to reduce input mistakes is not merely to operate carefully but to seamlessly connect design and field information.