Why isn't PVSyst running? 6 things beginners should check

Table of Contents

• When PVSyst doesn't run, isolating the cause is important

• Check item 1: Verify the startup environment and the computer's condition

• Check item 2: Verify the project file and its save location

• Check item 3: Verify loading of meteorological data and site conditions

• Check item 4: Verify missing inputs or inconsistencies in the system design

• Check item 5: Verify that shadow analysis and 3D scenes are not too heavy

• Check item 6: Verify report output and display conditions for calculation results

• Common judgment mistakes beginners should avoid when encountering PVSyst troubles

• Daily operational points for using PVSyst reliably

• Summary

When PVSyst isn't running, it's important to isolate the cause

When you feel PVSyst is not working, the first important thing is to think separately about at which stage it is stopping. If it cannot start at all, if it starts but cannot open a project, if it can open a project but cannot run a simulation, or if it can run a simulation but cannot output the report, the places you should check are different.

What beginners often get confused about is treating everything as a single problem — “PVSyst won’t run.” However, in practice you can reach the cause more quickly by checking separately for startup issues, data issues, input-condition issues, calculation-condition issues, and output issues. For example, if the program window won’t open, it’s often related to the PC environment, license status, or permission settings. On the other hand, if an error occurs after the simulation starts, it is often due to mismatches in conditions such as meteorological data, module configuration, PCS selection, string design, or loss settings.

Also, PVSyst is not software that can be completed with a single input. You must set the plant location, select meteorological data, determine the azimuth and tilt angles, combine modules and the PCS, configure shading and losses as needed, and finally read the simulation results. If a condition is missing at any point along the way, it will affect subsequent calculations and report output. Therefore, instead of judging based only on the error messages on the screen, it is important to be aware of and review the entire input workflow.

In particular, when using PVSyst for design work, deadlines and internal approvals often make you want to identify the cause quickly. However, if you rush to recreate the project, move related files, or change settings repeatedly, it can actually make it harder to determine the cause. First, check whether the program launches at all, whether only existing files cannot be opened, whether the same symptom occurs with a new project, or whether it stops only on a specific settings screen. Even this kind of isolation will considerably narrow down the range you need to address.

When PVSyst won't run, the basic approach is not to immediately suspect advanced settings but to proceed step by step starting with simple environment checks. There are many cases where such basic steps—restarting the computer, verifying the save location, checking file names, confirming required input fields, simplifying heavy 3D data, and so on—solve the problem. Below, we explain in order the six items that beginners should check first.

Check Item 1: Confirm the startup environment and the PC's status

If PVSyst does not start, freezes immediately after launching, or the screen remains white and does not progress, first check the state of your computer. Simulation software performs screen rendering, calculations, file loading, and database access simultaneously, so if the computer’s condition is unstable it may not operate correctly. In particular, if you are working with multiple other heavy applications open or your system is close to running out of memory, startup and screen transitions can become slow and it may appear as if the program is not responding.

The first thing to check is whether the computer is being excessively loaded by processes other than PVSyst. If you have many browser tabs, spreadsheet files, large drawings, 3D data, image-processing software, etc. open at the same time, the resources required to launch and run calculations in PVSyst can easily become insufficient. Before starting work, close unnecessary applications and restart the computer once before launching PVSyst; this can resolve simple temporary issues.

Next, verify that the version of PVSyst you are using and your computer’s basic environment are not significantly mismatched. Trying to work on a new project in an old environment, or conversely opening an old project in a new environment, can cause display or loading problems. When multiple people handle the same project in a work setting, also check that the creator and viewers are not using different versions. If there are version differences, the same file’s screen display and the way settings items are handled can change.

Display-related issues are another easy-to-overlook point. When switching from an environment using an external monitor to a standalone computer, settings screens and dialogs may appear to be displayed off-screen. In this case, PVSyst itself may be running, but you cannot operate it because the confirmation dialog is not visible. Immediately after changing the screen resolution or display scaling, buttons and input fields may be cut off. It is especially worth considering the effects of window position and display scaling for people who frequently switch between a laptop and an external display.

Security settings and internal management environments should also be checked. On company PCs, execution of applications, loading of external files, and saving to specific folders may be restricted. Such restrictions can prevent PVSyst from starting, accessing its database, or generating reports. In particular, be careful if you save projects to company shared folders, synchronized folders, or locations with limited access permissions. As an initial troubleshooting step, create a new project in a local folder where you have permissions and check whether the same symptoms occur; this will make it easier to determine whether the problem is caused by the save location.

Also, when PVSyst fails to start, before immediately considering a reinstall, check whether the symptoms are reproducible. It is important to determine whether it stops with the same operation every time, whether it stops only on specific projects, or whether it stops even with a new project. If it runs normally with a new project but freezes only on a specific project, the cause is more likely to be files or input data than the software itself. Conversely, if startup or screen operations are unstable even with a new project, you should prioritize checking for environmental issues.

Checklist Item 2: Confirm the Project File and Save Location

In PVSyst, project files, meteorological data, system settings, report output data, and other pieces of information are handled in combination. For this reason, the file storage location or the method of moving files can cause situations where it may seem to "not work." In particular, caution is required when you move a previously created project to another computer, open it from a shared folder, or change the folder structure.

A common situation is moving only the project file while the associated data and reference information remain in their original locations. A PVSyst project appears as a single project on the screen, but in reality it may reference multiple pieces of configuration information. If you move only part of the files or change folder names, a project that previously opened may fail to load correctly. When handing data over to another person, it is important to verify that the complete set of files related to the project is present.

If the destination path is too long or contains special characters, it can lead to unexpected problems. A Japanese folder name itself does not necessarily cause issues, but when long hierarchies, symbols, environment-dependent characters, or folders that are currently syncing combine, loading or saving can become unstable. When a beginner is isolating the cause, a practical approach is to first copy the file to a location with a short, easy-to-understand folder name and open it from there. For example, keeping a simple structure that shows the project name, date, and case name makes it easier to manage later.

Be careful when working in shared folders or synchronized folders. If you save a file while it is synchronizing, or if multiple people open the same file at the same time, save conflicts may occur. This applies not only to PVSyst; for design simulation files it is safer to separate files you are actively editing from finalized files meant for sharing. Edit in a local working folder while you are working, and only place verified files in the shared location to reduce file corruption and accidental overwrites.

Also, if you cannot save, overwrite, or generate reports, check the folder's write permissions. In read-only folders, company-managed folders, external media, or locations with access restrictions, PVSyst may be unable to save calculation results or reports. In such cases, the software may appear to be frozen, but the save operation may actually have failed. Create a new folder and verify whether you can save a test project there to determine whether the issue is permission-related.

Project file naming rules are also important. When similarly named files accumulate for each project, you may open an old case or accidentally overwrite a case with different conditions. There have been instances where we thought PVSyst wasn’t working, but in reality we had opened a different file than intended and the necessary settings were not included. Including the project name, system capacity, primary orientation and tilt conditions, analysis date, and version number in the filename makes it easier to verify things when problems occur.

Checklist Item 3: Confirm loading of meteorological data and site conditions

In PVSyst simulations, meteorological data and site conditions are critically important. Solar power output varies greatly with irradiance, temperature, installation location, azimuth, tilt, and other conditions, so if these are not set correctly you can encounter problems such as calculations failing to run, unrealistic results, or error messages. If PVSyst seems not to be working, check as part of the project's basic settings that the site and meteorological data are correctly linked.

The first thing to check is the installation site information. If conditions such as latitude, longitude, elevation, or time zone are incorrect, they will affect solar radiation and solar position calculations. In particular, when dealing with overseas projects or projects across multiple regions, selecting the wrong site can make a project appear to have been created while being inconsistent as calculation input. Don’t judge by the site name alone; it’s important to verify the coordinate values and regional conditions.

Next, check the loading status of the meteorological data. If you proceed with the system design while the meteorological data remains unset, you may encounter errors in later simulations or required calculations may not be executed. Also, when using meteorological data imported from external sources, pay attention to the format, units, time handling, and missing values. If data columns are not correctly recognized or the units for solar irradiance differ from what was expected, calculation results can become extremely large or small. It is not so much that PVSyst stops partway as that the input data are not being interpreted correctly.

What beginners often overlook is that, even when it appears that weather data has been loaded, it may not actually match the target location. For example, if you proceed with a design while provisionally using data from a nearby site, or if you reuse weather data from another project, the calculations themselves may still run. However, the reliability of the results will be reduced. In practice, it is important to verify not only whether the calculations run, but also whether the data being used is appropriate for the project.

Missing meteorological data is another item that should be checked. If parts of the annual dataset are missing, the time sequence is discontinuous, or abnormal values are included, warnings or errors may appear during the simulation. In particular, when importing data obtained from external sources or processed data, check column names, units, missing values, and time intervals in advance. When editing in spreadsheet software, date formats and the handling of decimal points can change. What appears to be an error in PVSyst is often actually a problem that occurred during data processing.

For site conditions, entering the azimuth and tilt angles is fundamental. If you misdefine the azimuth direction, the calculation results will appear incorrect. When you are not yet familiar with how to use PVSyst, it is easy to confuse the meaning of north on the drawings, the on-site orientation, and the orientation on the input screen. For tilt angles as well, if you mix roof pitch, racking angle, and terrain slope, the conditions become unclear. Even if this is not the direct cause of an operational failure, it can make the results seem wrong, so carefully check these basic conditions.

Checklist Item 4: Check for missing inputs or inconsistencies in the system design

If PVSyst launches and the project can be opened but you cannot run the simulation, suspect missing inputs or contradictory conditions in the system design. In photovoltaic system simulations, modules, PCS, number of strings, number of parallel connections, DC capacity, AC capacity, voltage range, loss conditions, and so on are interrelated. If any single condition is inconsistent or unreasonable, the calculation may not proceed or warnings may be displayed.

What beginners should check first is the combination of the modules and the PCS. If the number of modules, the number in series, the number of parallel strings, the number of PCS inputs, the voltage range, and the current conditions are not consistent, warnings may appear in PVSyst. For example, too few modules in series can lead to insufficient operating voltage, while too many can cause the voltage to exceed the upper limit at low temperatures. If an excessively large DC capacity is set relative to the PCS, you should verify whether the oversizing is an intentional design choice or an input error.

In string design, changing a single input can disrupt the consistency of the entire system. Examples include changing the number of modules without updating the number of parallel strings, changing the number of PCS units while leaving the array partitioning unchanged, or duplicating a design proposal but leaving some conditions intact. In such cases, rather than looking at only a few values on the screen, you need to check the entire installation to ensure the DC capacity, AC capacity, string configuration, and PCS inputs are properly connected.

Also, if required fields on the input screen remain unset, you may not be able to proceed to the simulation. Because PVSyst has many configuration items, even if you think you are moving through the screens in order, some items may be left unfilled. In particular, first-time users should not only pay attention to red text and warning indicators but also carefully read the confirmation screens and messages that appear before running the calculation. Error messages can contain clues indicating which conditions are missing or which ranges are unrealistic.

Loss settings also require careful attention. Temperature loss, wiring loss, mismatch loss, soiling loss, shading loss, degradation rate, and similar items are important factors that affect energy production. If these setting values are left blank, set to extreme values, or remain as values from another project, the calculation results can become unrealistic and design comparisons may not be done correctly. This may not always cause PVSyst to stop completely, but it can be a reason it feels like it is not working — in the sense of "the results are strange" or "the post-calculation values differ from expectations."

When checking system design, it is more important to first verify overall consistency than to immediately tweak detailed loss values. Confirm in order whether the system capacity is close to the assumed value, whether the number of modules matches the drawings, whether the number of PCS units aligns with the design intent, whether the azimuth and tilt correspond to the target surface, and whether the meteorological data are for the target location. If the big picture is correct, detailed loss settings can be adjusted later. Conversely, if the big picture is wrong, finely tuning only the losses will not produce a correct simulation.

Checklist item 5: Check that shadow analysis and 3D scenes are not too heavy

If the PVSyst screen freezes, a 3D scene won’t open, or a shadow analysis calculation does not progress, check the amount of data in the shadow analysis and 3D scene. In photovoltaic system design, surrounding buildings, terrain, trees, rows of racking, and obstacles are sometimes represented in 3D to evaluate shading effects. However, if the 3D data is too detailed or there are too many unnecessary objects, the software can become slow, making beginners feel that “PVSyst doesn’t run.”

In a 3D scene, what matters is representing only the shapes required for the simulation at an appropriate level of accuracy. Although you may want to reproduce the on-site conditions as precisely as possible, importing overly detailed geometry as-is increases the processing load. For shadow analysis, what is needed are the position, height, and shape of elements that could cast shadows onto the power-generating surface. Excessively modeling window frames, fine ornamentation, or distant minor details that have little impact not only increases computational load but also makes management more difficult.

Especially when importing 3D data or drawing data created externally, caution is required. The original data is often made with design or visualization purposes in mind and may include details that are unnecessary for shadow analysis. If imported as-is, file sizes can become large, leading to longer display times and sluggish operation. For shadow analysis, it is more practical to organize the data by simplifying it to include only the necessary obstacles and terrain.

In large-scale projects with many rows of mounting frames, the way the array is represented also affects performance. If every module is modeled as a separate detailed geometry, the 3D scene can easily become heavy. During the design review phase, it is important to adjust the model’s level of detail according to the purpose. The required level of detail varies depending on whether you are examining inter-row shading trends, the impact of a specific obstacle, or verifying final conditions for reporting.

If shadow analysis results do not appear, check not only the geometry's weight but also the settings for the target surfaces and obstacles. If the surface designated as the power-generating surface is not set correctly, if an obstacle is positioned extremely far away, if the relative heights of the ground and the racking are unrealistic, or if the orientation (azimuth) is shifted from what you expect, the calculation results may not be as intended. Even if something is visible in the 3D view, it may not be correctly recognized as an analysis target, so it is important to perform a quick check after input.

To avoid trouble with shadow analysis as a beginner, don’t create a complex 3D scene from the start. First, check whether the simulation runs with simple geometry, and then add the necessary obstacles. If you immediately include buildings, terrain, surrounding obstacles, and the entire array in detail, you won’t be able to tell which element is causing the problem. By adding elements step by step, it’s easier to find whether the model became slow when a particular dataset was added or whether calculations fail under specific conditions.

Checklist Item 6: Verify Report Output and Conditions for Displaying Calculation Results

If the simulation ran but the results screen won't open, a PDF report cannot be generated, graphs do not display, or a report you expected to have saved cannot be found, check the report output and display settings. In PVSyst work, because results are often used for internal sharing and in deliverables as well as for the calculations themselves, output-stage problems become a significant practical issue.

The first thing to check is whether the simulation has actually completed. If warnings appeared midway or the calculation was interrupted, results may not have been produced. Even if information that looks like results is visible on the screen, it may not be in a state that can be output as a final report. Check the post-calculation messages, warnings, and error indications to confirm whether it is in a completed state.

Next, check the report's save destination. If the folder you specified when exporting the report is in a hard-to-find location or is still set to a previous project's folder, it may appear that the report wasn't generated. Also, if you don't have write permission for the destination folder, the export process may fail. Be especially careful when attempting to save to a shared folder, a sync folder, external media, or a read-only location.

Also check the file name. If you try to save with the same name as an existing report and an overwrite confirmation appears, or if the file name contains characters that cannot be used, the output may stop. Putting the project name directly into the file name can include symbols or make the name too long. When exporting the report, it's safest to include the project name, the case name, the date, and the version number while keeping the file name as simple as possible.

The display conditions for results are another easy-to-overlook point. In PVSyst, you check results from multiple perspectives such as annual values, monthly values, loss diagrams, PR, energy production, and grid feed-in. If the indicator you want isn't displayed, it may not be that the calculation failed but that you are viewing a different screen or output item. For beginners, it is easier to understand if you first review the typical result screens for annual energy production, the flow of losses, PR, and monthly trends, and then look at the detailed items as needed.

Also, when comparing options, it’s important to confirm which case’s results you are viewing. If you produce multiple design proposals, you may have opened an older case’s results or be looking at simulation outputs from before conditions were changed. In such situations the problem is not that PVSyst isn’t running, but that you haven’t recalculated using the latest conditions. Whenever you change conditions, always rerun the simulation, and include version numbers and dates in the names of exported reports to keep them organized.

Common Judgment Mistakes Beginners Should Avoid When Troubleshooting PVSyst

When PVSyst won't run, one common mistake beginners make is immediately assuming the problem is with the software itself. Of course, issues caused by the environment or settings can occur. However, in practice the more frequent causes are insufficient input conditions, problems with the save location, moved files, data inconsistencies, or overly heavy 3D scenes. First, it's important to determine whether the issue is specific to your project or occurs with any project.

Another mistake is closing the window without reading the error message. If it includes English or technical terms, you might be tempted to avoid reading it. However, error messages can contain hints such as missing fields, abnormal values, inconsistent conditions, or files that cannot be loaded. Even if you don’t understand the message right away, recording it will make it easier to investigate the cause later.

Repeatedly duplicating a project and thereby making the cause harder to identify is an action to avoid. Simply because something isn't working, creating multiple copies of the same case and changing the conditions bit by bit will make it unclear which one is the latest and under which conditions the error occurred. If you do duplicate, record the purpose of the duplication and the changes made in the file name or in a note. For example, making the purpose of the separation clear—such as for shadow-free verification, meteorological data verification, or PCS configuration verification—will make management easier.

Also, be careful about reusing settings from past projects as-is. Copying a previous PVSyst file and using it for a new project is efficient, but the location, meteorological data, azimuth, tilt angle, modules, PCS, losses, and shading conditions may remain from the previous project. This can not only cause it not to run, but even if it does run it may produce incorrect results. If you reuse it as a template, it is important to decide up front which items should be changed.

Furthermore, when the results differ from expectations, you should avoid trying to match them by adjusting only the loss values. If generation is low or high, or the PR looks unnatural, the causes can be diverse: meteorological data, azimuth, tilt, shading, capacity ratio, temperature conditions, wiring conditions, and so on. If you change loss values subjectively to make the results fit, the numbers may look consistent but the design justification becomes weak. First verify the correctness of the input conditions, and then clarify how losses are being accounted for.

Daily operational points for the stable use of PVSyst

To reduce troubles with PVSyst, it is important not only to respond when problems occur but also to keep routine operations well organized. In practice, you compare multiple design proposals for a single project, update conditions after internal reviews, and prepare reports for submission. To prevent files and conditions from becoming confused during that process, deciding on management rules from the outset will reduce the causes of failures.

First, create a dedicated folder for each project and organize and store the PVSyst project, input data, drawings, study notes, and output reports. Rather than putting everything haphazardly into a single folder, it is clearer to create categories such as input data, working files, output reports, and previous versions. In particular, meteorological data and 3D data are often checked later, so it is important to store them in a way that makes clear which data were used.

Next, keep a record of changes to conditions. Simply changing settings in PVSyst can make it unclear later why a particular value was chosen. Important changes — for example changing the azimuth, adjusting the tilt angle, modifying the PCS configuration, adding shading conditions, or revising loss values — should be recorded as brief notes, as they will be helpful for internal reviews and recalculations. In particular, when comparing design proposals, if the differences between cases are not clear you will not be able to explain the differences in the results.

Regularly verifying operation with a new project is also useful. To determine whether the problem is occurring only with a specific case or across the entire environment, it is helpful to create a simple test project. If calculations work correctly in the new project, the issue is more likely to lie with existing files or input conditions. Conversely, if the same malfunction occurs even in a new project, prioritize checking the computer environment, storage location, permissions, and software settings.

Also, when multiple people within a company use PVSyst, it is important to share basic input rules. Standardizing how to handle azimuth, how to enter tilt angles, how to select meteorological data, standard approaches to loss values, how to name reports, and so on will reduce variation between staff. With fewer inconsistencies, it becomes easier to trace the cause when problems occur.

Finally, improving the accuracy of on-site information also contributes to the stable use of PVSyst. Even if the settings in PVSyst are correct, if the underlying site conditions are ambiguous, the reliability of the simulation will decrease. By accurately understanding the planned installation site’s location, orientation, topography, obstructions, existing structures, shading factors, and so on, you reduce uncertainty in the input conditions and make the results easier to interpret.

Summary

When PVSyst isn't working, it is important to first isolate the cause step by step. Depending on whether it fails to start, a project cannot be opened, a simulation cannot be run, the shading analysis is slow, or a report cannot be generated, the areas to check will differ. Beginners tend to treat everything as a single fault, but in practice, checking the startup environment, the save location, the weather data, the system design, the 3D scene, and the output conditions in that order makes it easier to find the cause.

It is especially important to first check the computer environment and the state of the project files. Simply closing unnecessary applications, restarting the computer, trying a new project in an easy-to-find local folder, or checking the permissions of the save destination can sometimes resolve the issue. Next, verify that the weather data and site conditions are set correctly, that there are no inconsistencies in the module and PCS configurations, and that the string design is valid. If you are using shadow analysis, also check whether the 3D scene is too heavy or whether you have included too many unnecessary shapes.

PVSyst is not merely software for producing energy yield; it is a practical tool for organizing design conditions, comparing multiple scenarios, reviewing the breakdown of losses, and sharing results as reports. Therefore, troubleshooting why it won’t run is not just resolving an operational issue—it also affects design quality and the credibility of explanatory materials. By rigorously maintaining file management, input rules, records of condition changes, and the organization of on-site information on a regular basis, you can respond calmly when problems occur.

Also, to improve PVSyst input accuracy, it is essential not only to organize desk-based conditions but also to accurately grasp on-site location information and surrounding conditions. If the coordinates of the planned installation site, the positions of structures, terrain undulations, and obstacles that cast shadows remain ambiguous, there will be uncertainty in the simulation settings. If information obtained from on-site surveys can be reflected in the design conditions, analyses in PVSyst will more closely match reality.

Using an LRTK—a high-precision GNSS positioning device that can be attached to an iPhone—is also effective for obtaining such on-site information. By acquiring high-precision position data in the field and combining it with equipment planning, current-condition assessment, point cloud acquisition, and photographic records, it becomes easier to organize the site conditions before entering data into PVSyst. Not only can you evaluate energy yield and losses in PVSyst, but by accurately capturing the site’s coordinates and geometry you can also more smoothly connect photovoltaic system design review, internal sharing, and pre-construction checks.