What to Do When PVSyst Can't Perform Calculations｜5 Cause-Specific Patterns

Table of Contents

• What to check first when PVSyst cannot perform a calculation

• Pattern 1: Problems with meteorological data or site settings

• Pattern 2: Array configuration and PCS conditions are not satisfied

• Pattern 3: Inconsistencies in shading analysis or 3D scene settings

• Pattern 4: Loss conditions or detailed parameter input values are unrealistic

• Pattern 5: Inconsistencies among project, variant, and report settings

• Practical procedures to prevent calculation failures

• Improving the accuracy of on-site conditions contributes to simulation stability

What to check first when PVSyst cannot perform calculations

When PVSyst cannot perform a calculation, the first important thing is not to immediately change all the detailed settings. If you hastily fix multiple items at the same time, you won't know which change resolved the error, and you're likely to repeat the same trouble on the next project. First, it's important to isolate at which stage the calculation failure is occurring.

For example, if you cannot proceed immediately after creating a project, there may be problems with the site settings or loading of meteorological data. If a warning appears after entering the array configuration, it may indicate inconsistencies in the combination of photovoltaic modules and the PCS, the number of strings, the voltage range, the number of inputs, and so on. If calculations stop after creating the 3D scene, the cause may be the shadow analysis settings, object placement, assignment of array surfaces, or similar issues.

Also, in PVSyst, even if warnings or errors appear on the screen, their wording alone can make the cause hard to intuitively understand. In practice, rather than translating and reading error messages one by one, it’s faster to understand which input categories are prone to inconsistencies. The causes that prevent calculation can be broadly grouped into five categories: meteorological data, electrical design, shading analysis, loss settings, and project management.

The basic check is to first see whether the calculation runs with the minimal configuration. If it is stuck when complex shading analysis or detailed loss settings are applied, remove those and verify whether it computes under simplified conditions. If it computes under the simplified conditions, the cause is likely the detailed options added later rather than PVSyst’s basic settings or the meteorological data. Conversely, if it still cannot compute under simplified conditions, there is a high probability of an issue in fundamental settings such as location, meteorology, the array, or the PCS.

By isolating issues in this way, you can reduce unnecessary adjustments. Because PVSyst has many input fields, if you question everything at once your work time will increase significantly. When calculations fail, it's especially important to clarify the symptoms and then revert settings in reverse order from the items you changed most recently. In practice, the closer the submission deadline, the less time you can spend on root-cause investigations. Understanding calculation-error causes as patterns can greatly speed up troubleshooting.

Pattern 1 Issues with meteorological data or site settings

The first thing to check when PVSyst cannot perform calculations is the meteorological data and site settings. In photovoltaic simulation, meteorological information such as solar irradiance, ambient temperature, and wind speed is required as a prerequisite for energy output calculations. If these are not loaded correctly, the energy output calculation itself cannot be performed. If you have created a project but cannot proceed to calculation, or if warnings appear at an early stage, first verify the consistency between the site and the meteorological data.

A common problem when setting up a site is discrepancies in latitude/longitude, elevation, time zone, and the location information in weather files. For example, if the project site is in Japan but the loaded weather data are for a different region, the calculation conditions become inconsistent. Even if calculations are not rendered completely impossible, the results may no longer match reality, so caution is required. Don’t judge by the site name alone; it’s important to check the latitude and longitude as well as the weather data’s period, units, and time step.

When importing meteorological data from external files, you also need to pay attention to the column mapping. If the columns for irradiance, temperature, wind speed, or date/time are not correctly recognized, PVSyst may treat the data as missing or as anomalous values. In particular, when importing data processed in spreadsheet software, delimiters, date formats, decimal notation, and unit handling can be altered. Even if the data looks fine visually, the software may not have read it correctly, so it is important to check the data ranges and graphs on the post-import verification screen.

Insufficient periods of meteorological data can also lead to calculation problems. If you want to calculate annual energy output but the data only covers some months, contains duplicate timestamps, or has gaps in specific periods, the calculation can stop or the reliability of the results can decline. When you feel that PVSyst cannot perform the calculation, first check whether the data constitutes one continuous year of meteorological data. If there are many missing values, imputation may be necessary, but casually filling them with zeros or mean values will distort the results, so in practice it is important to retain the data's source and processing history.

When defining the location point, it is also important whether the project's site and the location of the meteorological data coincide. Even if they are not exactly the same point and representative nearby location data may be used, in mountainous areas, coastal areas, urban areas, or snowy regions, even small differences in distance can cause large changes in meteorological conditions. Not only in terms of whether calculations can be performed, but also from the perspective of being able to explain the calculation results to colleagues or clients, it is necessary to clearly establish the correspondence between the site and the meteorological data.

As a countermeasure, first open the site information in PVSyst and confirm that the latitude, longitude, elevation, and time zone match the intended site. Next, verify that the meteorological data are correctly associated. If you are using external data, recheck the original file and check the column names, units, date/time format, and for any missing values. If the cause is unclear, try running the calculation once with standard meteorological data or another representative dataset; this makes it easier to determine whether the issue lies with the meteorological data or with another setting.

Pattern 2 Array configuration and PCS conditions are not satisfied

A very common reason PVSyst cannot perform a calculation is a mismatch between the PV array and the PCS settings. When you are not yet familiar with PVSyst, even if you think you have entered the number of modules, number of strings, modules in series, PCS capacity, number of inputs, voltage range, etc. individually, the overall configuration can end up being electrically invalid. In such cases, warnings will appear on the screen or the pre-calculation check may stop.

A typical case is when the string voltage falls outside the PCS input range. The open-circuit voltage of a solar module increases at low temperatures, and the operating voltage decreases at high temperatures. Therefore, if you determine the number of modules in series based only on standard conditions, the string can exceed the PCS allowable range when actual temperature conditions are considered. PVSyst checks including such temperature corrections, so it may issue a warning even when the number of modules appears acceptable at first glance.

On the other hand, if the number of modules connected in series is too small, the operating voltage may not reach the PCS's operating range. In particular, because module voltage drops at high temperatures, a configuration that cannot secure sufficient voltage under summer conditions can also be unstable in calculations. If you cannot perform the calculation, you need to check not only the module ratings but also the relationship between the minimum temperature, the maximum temperature, and the operating voltage range.

There are also cases where the number of PCS inputs or the maximum current is exceeded. If you increase the number of strings to match capacity, you may exceed the allowable current for each input. In PVSyst, not only the ratio of array capacity to PCS capacity but also the number of strings and the current conditions connected to each input are subject to consistency checks. Even if it appears acceptable based on capacity alone, it may not be valid at the input-circuit level, so caution is required.

Care must also be taken with the database entries for modules and PCS. If the equipment information you want to use is not registered accurately, values such as voltage, current, temperature coefficient, and capacity may differ from the actual equipment and trigger unexpected warnings. When adding equipment data yourself, don’t just copy catalog values verbatim—confirm that the units and test conditions are correct. A single mistake in an input field can invalidate the entire string design.

As a countermeasure, first check, in PVSyst’s system settings screen, the number of modules, the number in series, the number in parallel, the PCS capacity, and the number of PCS units, in that order. If a warning appears, don’t judge based solely on the capacity ratio; focus on reviewing the voltage range and the current range. Search for an electrically viable range by, for example, increasing or decreasing the series module count by one, adjusting the number of PCS units or input assignments, or revising the number of strings.

In practice, rather than trying to perfectly reproduce the final design from the outset, it is effective to first create a basic configuration that allows the calculations to run. After that, adjust the string configuration to match the actual design drawings and eliminate each warning one by one. When a calculation cannot be completed in PVSyst, checking which condition is exceeding its upper or lower limit—rather than randomly changing the array configuration—is the key to resolving the issue quickly.

Pattern 3: Inconsistencies in shadow analysis and 3D scene settings

When performing shading analysis in PVSyst, creating the 3D scene and positioning obstructions have a major impact on the calculation results. However, 3D scenes include many configuration items, and if the assignment of array surfaces or the positional relationships between objects are incorrect, this can cause the calculation to fail. In particular, if the basic simulation could run but the calculation stops as soon as shading analysis is added, you should suspect this pattern.

A common issue is when the array surfaces in the 3D scene do not correspond to the array configuration in the system settings. For example, if the system settings specify a fixed module capacity but the number or area of array surfaces placed in the 3D scene does not match that, PVSyst may be unable to reconcile them and will display a warning. Because the 3D scene is not just a visual diagram but is treated as an input for calculating shading losses, it needs to correspond to the system settings.

Calculations can become unstable when the height or position of obstructions takes extreme values. If you enter the wrong units and set what should be a building of several meters (several ft) to tens of meters (tens of ft) or hundreds of meters (hundreds of ft), the shadow extent will expand abnormally. Conversely, if an object is placed below the ground or the array and an obstruction overlap, you may get unintended shadow determinations. Even if not shown as a calculation error, results can become extremely poor, so it is important to check the positional relationships in the 3D display.

In projects that involve terrain and slopes, the orientation and elevation of array surfaces also tend to become an issue. When racking tilt angle, azimuth, row spacing, and ground elevation become complex, the placement in the 3D scene can deviate from the intended layout. Especially on sites with arrays facing multiple azimuths or with stepped terrain, you must verify which array group each surface belongs to. Check for misassignments in the 3D scene not only when calculations cannot be performed, but also when shading losses are larger than expected.

Also, depending on the shadow analysis mode and accuracy settings, the computational load can become large. Importing a large number of very detailed 3D shapes or creating unnecessarily complex occluding objects can increase computation time and make the process appear to stop midway. In practice, it is important to simplify unnecessarily detailed geometry while ensuring sufficient accuracy for assessing shadow impacts. Reproducing every detail of utility poles, fences, surrounding buildings, trees, and so on will make both the work and the computations heavier.

As a countermeasure, first temporarily disable shadow analysis and check whether the calculation can run. If it can be calculated without shadow analysis, the 3D scene is likely the cause. Next, check the assignment of array faces, the heights of obstructions, coordinates, units, and their relationship to the ground. If you are creating a complex scene, first run the calculation on a simplified scene limited to the main obstructions to confirm there are no problems before adding detail.

PVSyst's shading analysis is effective for improving the validity of predicted energy yield, but it depends heavily on the accuracy of site-condition inputs. When calculations cannot be completed, you need to review not only your operations in the software but also whether you have correctly captured the site's dimensions and positional relationships. If you create a 3D scene while the site's elevation, distances, orientation, and ground undulations are unclear, even if the calculation completes it will be difficult to explain the results.

Pattern 4: Input values for loss conditions and detailed parameters are unrealistic

PVSyst allows you to set many loss conditions such as temperature loss, wiring loss, mismatch loss, soiling loss, degradation, auxiliary consumption, and downtime rate. These are important for improving the accuracy of energy production, but if input values are unnatural or units are incorrect, they can cause calculations to fail. In particular, when reusing settings from another project or copying past internal files, unexpected values may remain in detailed parameters.

A common mistake in loss settings is entering a percentage incorrectly. For example, a value that should be entered as a few percent can be entered much larger because of a misplaced digit. Even if it looks like a simple number on the screen, it is treated in calculations as a condition that greatly reduces power generation, which can lead to abnormal results or warnings. You should check the loss conditions not only when calculations fail but also when the generated power is extremely low.

With wiring losses, the relationships among cable length, cross-sectional area, current, voltage, and loss rate can sometimes appear inconsistent. If settings for the DC and AC sides are confused, or if the distance units are mistaken, the loss values can become unrealistic. In PVSyst there are two methods—directly entering the loss rate or calculating it from wiring conditions—and if you don’t know which one you’re using, you can end up counting losses twice. Even if no calculation error occurs, caution is required because this undermines the reliability of the results.

Regarding temperature losses, thermal conditions that do not match the installation method are sometimes selected. The way module temperature rises varies depending on differences such as rooftop mounting, ground mounting, and ventilation conditions. Setting thermal conditions that differ from the actual site conditions affects the estimated power generation. It is not often the direct cause of calculation failure, but combined with other conditions it can trigger warnings. In particular, for special racking conditions or dense layouts, the temperature conditions should be reviewed.

Settings related to degradation rates and long-term calculations also need to be checked. When entering first-year degradation, age-related degradation, warranty period, evaluation years, and so on, entering extreme or inconsistent values can make long-term simulation results unrealistic. Even if single-year generation calculations are fine, the calculation may stop when you move on to multi-year evaluations or economic assessments. It is important to organize the required setting items according to whether the project’s purpose is a single-year design comparison or a long-term financial review.

Also, excessively tweaking detailed parameters can cause problems. While PVSyst allows you to enter very specific conditions, you do not need to force adjustments to every field. Rather than entering values without justification, it is safer to start from standard conditions and only change items for which you have measured data or design justification. If you find yourself unable to run calculations, check the detailed settings one by one and look for any items that deviate significantly from the default values.

As a remedy, first open the loss settings screen and check whether any extreme values have been entered. Next, clarify which losses are being entered directly and which are being calculated from conditions. If you are using a file copied from a past project, be sure to check that site-specific conditions from the old project have not been left behind. If you cannot determine why the calculation fails, temporarily revert the loss settings to standard values, confirm that the calculation runs, and then add the necessary conditions step by step.

Pattern 5: Inconsistency between project, variant, and report conditions

In PVSyst, you can create multiple variants within a single project to compare design proposals. This is very useful in practice, but creating multiple proposals can lead to inconsistencies in settings that cause calculations to fail. In particular, when you make a new proposal by copying a past variant, some items—site, weather, array configuration, shading analysis, and some loss conditions—may remain old.

For example, there are cases where something that had been configured as a ground-mounted installation in one variant was changed to a roof installation in another variant, yet the shading analysis and racking conditions remained as ground-mounted. Or, even though the PCS capacity was changed, the string configuration and array surface assignments were not updated. Such inconsistencies are difficult to notice just by looking at the screen and may only become apparent during pre-calculation checks.

Post-processing after calculation can fail due to report conditions or output items. Even if the power generation calculation itself has been completed, if required information is missing when creating the result report, output may stop. In particular, if project information, system name, installation location, author information, reporting period, etc. are left blank, the report may be inadequate for internal submission. It's not so much that the calculation cannot be performed, but that the calculation results cannot be output; however, to operational staff it appears to be the same problem.

File management issues should not be overlooked. When project files are moved to a different environment, related weather data, equipment data, 3D scenes, and external reference files may not be transferred correctly. If calculations that worked in the original environment fail on another computer, suspect missing file paths or related data. When multiple people in the company handle the same project, you need to manage not only the project data but also the weather data used and any additional equipment data together.

Also, differences in software versions can cause some settings in past files not to be reproduced correctly. When opening and recalculating an old project, the settings at that time may not completely match the current specifications. If calculations cannot be performed, it is important not only to reopen the file but also to reconfirm the key settings on the current screen. Rather than using an old variant as-is, it may be safer to duplicate it as a new variant and reconfigure the necessary items.

As a countermeasure, first confirm which project, which location, and which meteorological data the target variant is linked to. Next, in the order of system settings, shading analysis, loss settings, and report settings, check whether any old conditions or alternative conditions remain. When comparing multiple scenarios, recording the items you changed and those you did not change makes it easier to trace the cause later.

In practice, variant names also need to be chosen carefully. Simply naming them "Option 1" and "Option 2" will make it unclear later what was changed. Naming them so the changes are obvious — for example, a variant that changes the azimuth angle, a variant that changes the tilt angle, a variant that changes the PCS capacity, or a variant that changes the shading conditions — makes it easier to trace the cause when a calculation cannot be performed. When using PVSyst, it is important not only to handle input operations but also to establish rules for project management.

Practical Steps to Prevent Situations Where Calculations Cannot Be Performed

To reduce incidents where PVSyst cannot complete a calculation, it is important not to try to enter all complex conditions from the start. In practice, an effective approach is to first create a state where the calculation runs with the minimum required inputs, and then add site-specific conditions and detailed losses afterward. Initially set the meteorological data, installation azimuth, tilt angle, module, PCS, and the basic array configuration, and run the calculation once without including shading analysis or minor losses. If the calculation succeeds at this stage, you can judge that the basic design framework is established.

Next, add shadow analysis. If the calculation fails at this stage, you can narrow the cause down to the 3D scene or the assignment of the array surface. Then add the loss conditions and run the calculation; if problems occur, check the loss settings. Proceeding step by step like this makes it clear where the calculation became impossible. Conversely, if you input all conditions at once and then run the calculation, there will be too many potential causes and it will take longer to resolve.

It is also important to keep a record of configuration changes. In particular, when comparing design proposals or conducting internal reviews, it becomes difficult to explain calculation results if you don’t know who changed which conditions and when. Rather than relying solely on PVSyst file names or variant names, it is useful to organize, in a separate note, the meteorological data, azimuth, tilt angle, array capacity, PCS capacity, major losses, and whether shadow analysis was performed. In the event of issues, this note will help trace the cause.

When addressing situations where calculations cannot be completed, it is important not to focus solely on eliminating errors. For example, forcibly changing the number of strings to avoid warnings or lowering loss values without justification may allow the calculation to run, but will take it away from the actual design. PVSyst is, above all, a tool to support design decisions, and getting a calculation to run is not the same as the design being valid. If you change input values, you need to be able to explain why you made those changes.

Also, when site conditions have not yet been confirmed, it is important to treat provisional conditions and confirmed conditions separately. In preliminary assessments before on-site surveys, calculations are sometimes performed using typical tilt and azimuth angles and approximate shading conditions. However, when using those results for detailed design or for submission documents, they need to be revised based on on-site measured information. If detailed simulation results are treated as final while still based on provisional conditions, it will be difficult to explain later discrepancies in power generation.

Until you become familiar with using PVSyst, it’s effective to prepare a checklist. By checking in the following order — whether the site and meteorological data are correct, whether the array configuration fits the PCS conditions, whether the shading analysis corresponds to the system settings, whether the loss values are not extreme, and whether the variant name matches the changes — you can prevent many calculation problems in advance. Checking in the same order for every project helps stabilize the quality of your work.

Improving the accuracy of site conditions leads to more stable simulations

The causes of PVSyst being unable to perform calculations can arise not only from input mistakes on the screen but also from insufficient understanding of on-site conditions. In solar PV simulations, not only irradiance and equipment parameters but also field information such as site location, terrain, orientation, tilt, obstructions, mounting height, and the surrounding environment are important. If these are entered ambiguously, it becomes difficult to ensure consistency of conditions in PVSyst, which can lead to calculation errors or unrealistic results.

In shading analysis in particular, accurately grasping the on-site positional relationships is essential. If you create a 3D scene while the heights and distances of buildings, trees, slopes, and nearby equipment are unclear, the evaluation of shading losses can be greatly off. Even if calculations can be performed, results based on shapes that differ from the actual site will be difficult to use for design decisions and internal explanations. For stable calculations in PVSyst, the quality of the on-site data you input is as important as the operations performed in the software.

Furthermore, for projects with undulating terrain, simple flat‑plane assumptions can make it difficult to reproduce real conditions. At sites where the mounting surface height varies by location, there are multiple orientations or tilts, or there are steps and slopes nearby, calculating based only on approximate conditions will lead to discrepancies with actual construction conditions and shading. In such cases, acquiring on‑site coordinates and elevations with high accuracy and reflecting them in the design conditions makes it easier to organize the settings in PVSyst.

For acquiring on-site information, in addition to traditional surveying work and checking drawings, high-accuracy positioning using a smartphone is also effective. LRTK is a high-precision GNSS positioning device that can be attached to an iPhone, allowing easy capture of local position information and use in point cloud measurement, photo documentation, coordinate management, and similar tasks. In design studies for photovoltaic systems, recording the site's shape, the locations of obstructions, the planned installation area, and the surrounding environment on site can help organize the assumptions for design and simulation.

When PVSyst calculations fail, it is important not to suspect only the software settings but to review whether the site conditions you entered are actually correct. Check the meteorological data, array configuration, shading analysis, loss conditions, and project management in order, and you can reduce calculation issues by bringing the site’s location, elevation, and obstruction information to high accuracy. Simulation reliability is directly tied to the accuracy of the input conditions. To use PVSyst reliably in practice, it is important not only to learn the on‑screen operations but also to measure the site correctly and establish a workflow for entering conditions based on sound justification.