Summary of PVSyst Error Solutions | Explaining 7 Common Issues

Table of Contents

• Errors in PVSyst indicate inconsistencies in input conditions

• Symptom 1: Unable to run the simulation

• Symptom 2: Weather data or site data cannot be loaded

• Symptom 3: Warnings appear for module and PCS combinations

• Symptom 4: Out-of-range errors for string voltage or current occur

• Symptom 5: Calculation errors occur in shading or 3D scenes

• Symptom 6: Energy production or PR show unrealistic values

• Symptom 7: Report output or result saving fails

• Practical check procedures to verify when troubleshooting errors

• Accurately reflecting on-site conditions improves the accuracy of PVSyst applications

PVSyst errors indicate contradictions in input conditions

Errors and warnings displayed by PVSyst can broadly be classified as occurring when required fields are left blank, input values are not valid for calculation, settings conflict with each other, reference data cannot be found, or the calculation results fall outside the normal range. In practice, because conditions are changed many times during the course of a design, settings that were consistent at first can become misaligned due to later modifications.

For example, cases where the number of modules has been changed but the number of strings has not been updated, the tilt angle has been altered but the racking conditions have not been reviewed, the meteorological data location differs from the actual design location, or the array layout in the 3D scene does not match the array capacity in the system configuration. These may seem like small differences on their own, but they have cascading effects on energy generation, losses, oversizing ratio, shading impacts, and grid-side output.

What is important when using PVSyst is not to make eliminating errors your only goal. If you arbitrarily change values to make warnings disappear, the simulation results may diverge from the actual design intent. Especially when the tool is used for business feasibility assessments, design comparisons, internal approvals, pre-order reviews, or construction planning, you need to be able to explain why you chose those values.

Also, PVSyst reports critical errors that stop calculations and warnings that allow calculations to proceed but prompt verification. Critical errors prevent the simulation from running and therefore must be corrected. Warnings, on the other hand, may be acceptable as intentional design choices depending on the circumstances. However, even in such cases you should not proceed without reviewing the warning; it is important to clarify the design intent, the assumed/adopted conditions, and the risks before handling the results.

The basic rule for handling errors is to remember what you changed most recently. Many problems are caused by the last setting you touched, the data you loaded, the equipment conditions you modified, or the 3D scene you edited. Rather than reviewing everything at once, check items in order starting from those closest in the change history; this lets you narrow down the cause more efficiently.

Symptom 1: Unable to run the simulation

One of the most straightforward problems in PVSyst is the symptom where pressing the simulation button does not advance the calculation. In such cases, common causes include missing required inputs, an incomplete system configuration, omitted equipment selection, unset meteorological data, and configuration inconsistencies within the design variant. Because unset items are often indicated on the screen in red or with warning icons, first check the input fields of the currently selected variant in order, rather than the entire project.

When a simulation cannot be executed, first check that the location and meteorological data are set correctly. In solar power calculations, conditions such as solar irradiance, ambient temperature, and wind speed form the basis. If the location is unset or the weather data are not linked, you cannot start the calculations even if subsequent design conditions are correct. In particular, when duplicating a previously created project, the location name may remain while the data reference is broken.

Next, check the settings for the modules, the PCS, and the array configuration. In PVSyst, the system will not be valid unless the module model, quantity, string configuration, and the PCS input conditions are properly set. For example, if you change the PCS after selecting the modules, the previous string configuration may no longer fit within the input range of the new PCS. Conversely, if you set only the PCS first and later change the module conditions, the voltage and current ranges may shift.

Also, if you configure shading analysis using a 3D scene but the 3D scene remains incomplete, this can cause errors when running the calculation. In PVSyst, the required settings vary depending on whether you enable shading calculation, whether you include the arrays in the 3D scene in the calculation, and whether you model electrical shading effects. Simply saving a 3D scene while it is still under construction may mean it is not linked to the system configuration, so caution is required.

As a countermeasure, begin by checking each warning displayed on the screen immediately before the calculation and filling in any missing fields. If you close the screen without reading the error message, it becomes difficult to identify the cause, so jotting down what was displayed will make it easier to review later. If multiple people in your company use PVSyst, sharing which screen you were on, which action you had just performed, and what error appeared will help prevent the same problem from recurring.

Symptom 2: Weather data and location data cannot be loaded

Errors loading meteorological and site data often occur during PVSyst’s initial setup phase. In solar power generation simulations, site conditions are the basis for the energy yield calculation, so configuration mistakes here can greatly affect the overall results. Possible causes of errors include mismatched file formats, character encoding or delimiter issues, incorrect latitude/longitude or time settings, unit differences, insufficient data periods, etc.

First, you should check whether the meteorological data you are trying to import is organized in a format that PVSyst can handle. When using external data, if the column order, units, date format, or time format differ from what is expected, the data may not be recognized. Be especially careful when monthly, hourly, and daily data are mixed, or when the type of irradiance is not clearly specified. If it is unclear which items are being used — such as global horizontal irradiance, direct irradiance, or diffuse irradiance — it will affect calculations after import.

Next, verify the consistency of the latitude and longitude with the time zone. Even if a location’s coordinates appear correct, mistaking the sign for east/west or north/south can cause it to be treated as an entirely different place. Also, whether the time reference is local time or standard time, or whether adjustments like daylight saving time are included, can shift the temporal distribution of solar irradiance. Even if no loading errors occur, if the monthly trends in generation look unnatural, you should suspect an inconsistency between the location and the time.

A lack of sufficient meteorological data for the required period is also a common cause. When performing annual simulations, if you do not have a full year of data, have many missing values, or are missing specific months, the reliability of the calculation results will be low. Even if the data can be loaded into PVSyst, the results can change depending on how missing values are filled and how anomalous values are handled, so it is important to check the source data before importing.

As a troubleshooting workflow, first create a project using standard site data and verify that the simulation runs. After that, import external weather data; this makes it easier to determine whether the problem lies in the project settings or in the data. If the import fails, simplify the file name, storage location, column names, units, and date format, and check that there are no extraneous spaces or symbols.

In practice, it is also important to clearly state the source of the meteorological data and any correction conditions. Even with the same design, changing the meteorological data used will alter the annual and monthly power generation. Not only for error handling but so you can explain it in the final report, it is reassuring to record which site conditions were adopted and how you assessed the distance to the site and the elevation difference.

Symptom 3: Warnings appear when modules and PCS are combined

In PVSyst, warnings may appear when the combination of PV modules and the PCS is inappropriate. This relates to conditions such as module capacity, PCS capacity, input voltage range, maximum input current, MPPT range, and the number of strings. A warning does not necessarily mean the design is infeasible, but it is an important sign to check whether the electrical design is valid.

A common issue is that the DC-side capacity is either too large or too small relative to the PCS capacity. In solar power systems, a certain degree of oversizing is sometimes applied, but if the setting is excessively large it can increase output curtailment at peak times and cause losses that differ from the design intent. PVSyst can represent the oversizing itself, but it is necessary to verify that the adopted values match the actual equipment conditions, grid conditions, contractual conditions, and construction conditions.

Also, warnings are likely to appear when the number of PCS inputs and the string configuration do not match. For example, cases such as exceeding the number of strings or current limits that can be connected per MPPT, a mismatch between the number of input circuits and the number of parallel strings, or the array capacity being skewed toward some inputs. Even if the overall capacity looks acceptable on the screen, it may exceed the limits when viewed at the input-unit level.

When addressing this, first confirm the input conditions specified in the equipment datasheet. Organize items such as the maximum input voltage, start-up voltage, MPPT voltage range, maximum input current, how short-circuit current is handled, and the number of strings that can be connected, and compare them with the settings in PVSyst. Even if you are using information registered in the equipment database, it may not exactly match the specifications actually adopted, so it is important to verify the input values as necessary.

Particular attention should be paid to the module temperature conditions. Module voltage changes with temperature, and at low temperatures the open-circuit voltage increases. Therefore, even if there is no problem under standard conditions, considering low-temperature conditions can cause the PCS maximum input voltage to be exceeded. Conversely, at high temperatures the operating voltage falls and may drop below the MPPT range. PVSyst warnings may prompt you to check the voltage range taking these temperature changes into account.

To clear the warning, you can change the number of modules in series, adjust the number in parallel, review the PCS input configuration, or reconsider the selected equipment. However, even if the warning disappears in PVSyst, on-site constructability, cable routing, protective devices, and switchboard configuration will not be automatically optimized. The simulation consistency and the feasibility in the detailed design must be checked separately.

Symptom 4: String voltage or current out-of-range errors occur

Out-of-range errors for string voltage or current are very common symptoms in PVSyst system design. The voltage and current input to the PCS are determined by how many photovoltaic modules are connected in series and how many strings are connected in parallel. If this combination exceeds the equipment’s allowable range, it will be displayed as a warning or error.

If the number of modules in series is too high, the open-circuit voltage at low temperatures can become high and may exceed the PCS's maximum input voltage. This is an important safety check. If PVSyst displays an error, you should not simply relax the temperature conditions to avoid it; instead, you need to review the number of modules in series taking into account the area's minimum temperature, design standards, and equipment specifications. In cold regions or at high elevations, the voltage rise at low temperatures is greater, so a standard number of modules may not be feasible.

On the other hand, if the number of modules connected in series is too low, the operating voltage at high temperatures may fall below the PCS's MPPT range. In this case, even during periods with sufficient solar irradiance, the PCS may have difficulty tracking the optimum operating point, which can affect power generation. Special attention is required in high-temperature regions, rooftop installations, and installations with poor ventilation, where module temperatures tend to become high.

A typical error on the current side is having too many parallel strings. If the PCS input current limit is exceeded, it affects not only warnings in the calculations but also protective devices and wiring design in the actual system. You need to verify how short-circuit current is taken into account, how temperature correction is handled, and whether the current for each input stays within the per-input current limits.

The basic approach is to consider the number of modules in series and the number in parallel separately. First establish the voltage range with the number in series, then adjust capacity and current with the number in parallel. If you change both the series and parallel counts at the same time to match capacity, it becomes difficult to tell which change fixed the error. In PVSyst, changing one condition at a time and checking the results is the quickest way to troubleshoot.

Also, even with the same total capacity, losses and limitations vary depending on the string configuration. On the PVSyst results screen, check output limitations, mismatch, wiring losses, temperature losses, etc., and choose a configuration that is reasonable in terms of both energy yield and detailed design, rather than one that simply makes the errors disappear.

Symptom 5: Calculation errors occur in shading and 3D scenes

In PVSyst's 3D scene and shading settings you can represent buildings, terrain, obstacles, and array layouts, but that also makes errors more likely to occur. Common symptoms include being unable to save the 3D scene, being unable to run shadow calculations, arrays not being recognized, the placement on the scene not matching the system settings, and extremely large near-shadow losses.

The first thing to check is whether the array in the 3D scene corresponds to the array in the system configuration. In PVSyst, the panel layout visible in 3D and the electrical system configuration can sometimes be managed separately. As a result, even if panels appear to be aligned in the 3D view, they may not be correctly assigned as calculation targets. When performing shading calculations, confirm that the array surface in the 3D scene, the number of modules in the system, and the string configuration all match.

Next, check the placement of obstacles and terrain models. When placing buildings, walls, trees, equipment, and so on, incorrect dimensions or coordinates can produce shadows larger than in reality. Errors in the vertical dimension in particular have a large effect, and using the wrong units can cause shading loss to increase dramatically. Even if a 3D scene looks natural visually, if the origin position or height reference is offset, the calculations may treat the shadows as unrealistic.

Also, using overly complex 3D models can make calculations unstable. In practice you may want to reproduce every detail of the on-site geometry, but what is required for shadow analysis is an appropriate representation of the main elements that cast shadows onto the power-generating surfaces. Overly detailed geometry, unnecessary faces, duplicated objects, and extremely thin members can increase computational load and cause errors. It is effective to start with a simple model to check the impacts and refine it as needed.

When dealing with electrical shading, it's important to consider not only simple solar shading but also how it relates to the string configuration. Even with the same shadow, the impact on energy production varies depending on which module is shaded and which string it belongs to. If shading losses in PVSyst appear unnaturally large, check not only the positions of obstacles but also the module grouping and string assignment.

As a countermeasure, first run the simulation without shadow calculations to confirm that the basic conditions are met. After that, enable proximity shadows, and if necessary proceed to reflect electrical effects. Enabling all shadow settings from the start makes it difficult to determine where the cause lies. It is important to add features incrementally and check at which point an error occurs.

Symptom 6: Power generation or PR shows abnormal values

Even though the simulation itself in PVSyst has completed, the values for annual energy production, monthly energy production, PR, and the loss diagram may appear unnatural. In such cases, because there is no clear error message, the issue can be easily overlooked. If the energy production is extremely high or conversely too low, if the monthly trends do not match the region's solar radiation conditions, or if the PR deviates greatly from normally expected values, you should recheck the input conditions.

The first thing to suspect is the unit or an input error for system capacity. Check that the number of modules, module capacity, PCS capacity, number of arrays, and subarray settings are the intended values. Mistakes such as mistyping a digit, confusing kW and W, or registering the same array twice directly affect generation output. In particular, when duplicating design proposals for comparison, some conditions from the previous proposal may remain.

Next, review the azimuth, tilt angle, and mounting method. Errors such as the azimuth being reversed, the tilt angle differing significantly from what was assumed, confusing fixed racks with tracking racks, or intending a roof-mounted installation but using ground-mounted thermal conditions can greatly affect the results. If the power generation is too low, it is important to check not only shadows and losses but also whether the solar panel surface is facing the correct direction.

If the PR looks abnormal, check the loss settings. Verify whether any one of the temperature loss, wiring loss, mismatch loss, soiling loss, IAM loss, PCS loss, output limitation, etc., is abnormally large. The PVSyst loss diagram is very useful for tracing causes when the results are off. Rather than only looking at the final energy yield, it is important to go through, step by step, which stage the energy is being reduced.

If the monthly power generation trend appears unnatural, review the meteorological data and time settings. If the summer and winter trends do not match regional characteristics, a particular month is extremely low, or the relationship between solar irradiance and generation is inconsistent, possible causes include missing meteorological data, differences in units, or misalignment of monthly data. Do not judge based only on the results screen; also check the monthly trends of the input solar irradiance and temperature.

Also, if the PCS output curtailment is too large, check the oversizing ratio and PCS capacity settings. Increasing the oversizing increases energy production, but it can also increase peak-time curtailment. How much to allow depends on design policy, grid conditions, and business viability assessment. In PVSyst, it is advisable to compare multiple cases and evaluate not only annual energy production but also curtailment losses and monthly generation characteristics.

When you find an unexpected result, don't immediately question the details; instead, confirm the major conditions in this order: capacity, site, orientation, tilt, equipment, losses, and shading. If the major assumptions are off, adjusting small loss coefficients will not bring you closer to the correct result.

Symptom 7: Report output and result saving are not working properly

When using PVSyst calculation results for internal sharing or submission documents, problems with report output and result saving frequently occur in practice. Typical symptoms include being unable to generate reports, no file being created at the save destination, past results being overwritten, not being able to find the cases you want to compare, and discrepancies between what is displayed and what is output.

First, check the project name, the variant name, and the management of the save location. In PVSyst, you may create multiple variants within the same project to compare them. When duplicating design proposals, if variant names remain similar it becomes difficult to tell under which conditions the results were calculated. Before generating the report, include information in the variant name that indicates the differences in design conditions to make later verification easier.

Next, check the permissions and path of the destination folder. On business computers, output can fail for reasons such as the destination folder not having write permission, files being locked in a synced folder, or the path containing special characters. If an error occurs, first try saving to a simple, easy-to-find local folder — this makes it easier to determine whether the problem is on the PVSyst side or the saving environment side.

If the report contents differ from expectations, check whether you selected the wrong variant for output. It is not uncommon for the result you were just viewing on the screen to differ from the conditions used to generate the report. Especially when comparing multiple options, verify which variant is selected, when the simulation was last run, and whether you recalculated after changing settings. If you only changed the conditions without recalculating, the display and the report may remain showing outdated results.

Also, when using a report as submission material, it is important to check not only whether the output was produced but also whether the assumptions are communicated to the reader. If you cannot explain the site, capacity, module conditions, PCS conditions, azimuth, tilt angle, loss settings, whether shade analysis was performed, and how the meteorological data were treated, the energy generation figures will end up being taken out of context. PVSyst reports are convenient, but in practice it is safer to manage them together with supplementary materials and internal memos.

To prevent problems saving results, it's effective to establish a naming convention before starting work. Including the date, project name, design option, and key conditions in file names or variant names makes it easier to trace the content when reviewing later. If you recompute after handling errors, saving the pre- and post-correction results separately makes it easier to explain which changes affected power generation or losses.

Operational check procedures to verify when handling errors

When troubleshooting PVSyst errors, it's important not only to investigate the cause of each individual symptom but also to have a habit of checking in the same order every time. If procedures aren't defined, the checkpoints vary by person in charge, causing variation in the quality of responses even for the same error. In practice, it's easier to stay organized if you first verify the project's assumptions, then review equipment settings, electrical design, shading settings, loss settings, and results output in that order.

First, check the location and meteorological data. However accurately equipment conditions are set, if the site conditions are off the results cannot be trusted. Verify latitude and longitude, elevation, the types of meteorological data, the data period, and time conditions to ensure they do not differ significantly from the project's target site. In particular, if substituting data from a nearby location, you must be able to explain why that data was selected.

Next, check the system capacity and equipment configuration. Verify that module capacity, number of modules, PCS capacity, DC/AC ratio, string configuration, and sub-array configuration match the design documents. The important point here is not to judge solely by the input values in PVSyst. Cross-check with the estimate documents, single-line wiring diagrams, layout drawings, equipment specifications, and so on to confirm that the design intent is correctly reflected.

After that, check the validity of the voltages and currents. Review the open-circuit voltage at low temperatures, the operating voltage at high temperatures, the MPPT range, the maximum input current, and the upper limit on the number of parallel strings. Even if PVSyst does not show any warnings, you still need to separately confirm whether the results align with the actual design criteria and the approach to safety margins. In particular, make sure you can later explain how you set the design temperature conditions.

Next, check the shading and loss settings. If you are using a 3D scene, inspect the positions and heights of obstacles, their relationship to the array, and the array assignments in the scene. In the loss settings, verify that temperature, wiring, mismatch, soiling, PCS, output limits, etc. are not set excessively high or low. If the power generation seems off, read the loss diagram from the top in order and trace at which stage the unexpected drop is occurring.

Finally, review the results and the report. Check whether the annual generation, monthly generation, PR, loss breakdown, output limitations, and shading losses are reasonable relative to the design conditions. When comparing multiple cases, verify that the conditions you changed correspond to the changes in the results. If you change conditions but the results hardly change, it may mean the settings you intended to alter were not actually reflected in the calculations.

Recording how errors were handled is also important. Keeping a record of which errors occurred, which conditions were adjusted, and how the results changed will be useful for internal reviews and when explaining to customers. Although PVSyst can perform detailed simulations, it has many input items, so operators’ judgments tend to be reflected in the results. For that reason, standardizing verification procedures rather than relying on individual operators’ actions leads to improved accuracy.

Correctly reflecting on-site conditions improves the accuracy of PVSyst analyses

When dealing with PVSyst errors, it's easy to focus on clearing the on-screen warnings, but what really matters is whether the simulation conditions match the actual conditions at the site. In photovoltaic system design, many site-specific factors affect the results—not only meteorological conditions such as solar irradiance and temperature, but also terrain, orientation, tilt, nearby obstructions, installation height, racking conditions, wiring distances, and how shadows fall.

For example, even if the azimuth and tilt angles are entered correctly in PVSyst, if the actual on-site measurements are inaccurate, the simulation results will still diverge from the field. In shading analysis, if the positions and heights of obstacles remain ambiguous, creating a 3D scene will not produce a reliable assessment of losses. Creating a model that produces no errors is not the same as creating a model that accurately represents the site.

Therefore, when using PVSyst in practical work, it is important to improve the accuracy of site surveys. By accurately recording the location and boundaries of the planned installation area, ground elevation, surrounding structures, existing equipment, and objects that may cause shading, you can make the input conditions in PVSyst closer to reality. In particular, for projects with complex terrain and obstacle conditions, whether data containing on-site coordinate information is available can greatly affect the credibility of the simulation.

A helpful tool here is LRTK, an iPhone-mounted GNSS high-precision positioning device. By using LRTK, you can record on-site positional information with high accuracy, making it easier to retain the positioning data and on-site verification information needed for design studies of solar power installations. If you can link and manage installation area, obstacles, existing site topography, and verification photos with positional information, it becomes easier to organize the rationale for the assumptions to be entered into PVSyst.

To reduce errors in PVSyst and enhance the reliability of simulation results, it is important to consider not only the software settings but also how on-site data are collected. Rather than simply adjusting the numbers on the screen, properly measuring the site, correctly entering the conditions, and being able to explain the results with supporting evidence leads to power generation simulations that are useful in practice. By leveraging high-precision positioning such as LRTK, you can more reliably gather the on-site information needed for PVSyst analyses and smoothly carry out the process from design and verification to sharing and explanation.