What to input into PVSyst? Explaining the 6 required data items

The first thing a practitioner who wants to understand PVSyst should know is that this software is not simply a box that automatically calculates energy production. The official help positions PVSyst as software for the design, capacity assessment, and data analysis of photovoltaic power systems, and for project design it performs detailed simulations based on one year of time series. In other words, what you input directly affects the reliability of the results. In practice, it is important not to judge solely by the energy production figures but to bring the analysis to a state where you can explain the assumptions used for the calculations.

Furthermore, in PVSyst’s design philosophy, projects are managed within a framework called "Project," which includes the installation site and meteorological data, and multiple simulation conditions are compared as "Variants." In other words, the question "What do you input into PVSyst?" is not simply about memorizing field names, but about understanding at what level of granularity to organize design conditions and how far to improve accuracy. If inputs are insufficient, calculations become coarse; conversely, even inputs that appear detailed will produce results that only seem plausible if their assumptions are incorrect.

Table of Contents

• What is PVSyst?

• Required Data 1 Site location and meteorological data

• Required Data 2 Azimuth, tilt angle, and mounting type

• Required Data 3 Photovoltaic module specifications

• Required Data 4 Power conversion equipment and electrical configuration

• Required Data 5 Shading, 3D layout, and array mapping

• Required Data 6 Loss conditions and operational conditions

• Practical points to note before data entry

• Summary

What is PVSyst?

PVSyst is specialized software for designing and evaluating the performance of photovoltaic power systems. According to the official documentation, it can handle not only grid-connected systems but also off-grid and pumping applications; in particular, its core project-design functions evaluate annual behavior by combining meteorology, orientation, equipment configuration, shading, losses, and so on. Many people who search for "PVSyst とは" are not merely looking for what the name means, but want to know what can be done with it in practice and what they need to prepare to use it. In that sense, it is easiest to understand PVSyst as a tool for quantitatively organizing design conditions for power plants and rooftop projects and for comparing how results change with different conditions.

When grasping PVSyst's approach, the important sequence is to first create a Project, include the site location and meteorological data within it, and then compare multiple design proposals. The official help likewise explains that a Project is a container that holds geographic conditions and time-series meteorological data, and that different calculation versions under different conditions are stacked on top of it. Understanding this structure makes it easier to sort out what is a variable and what is a common condition when later adding shading conditions, revising loss rates, or changing equipment configuration. In practice, if this organization is sloppy you will be unable to explain differences in calculation results.

Also, PVSyst offers a simplified design workflow for preliminary studies, but for projects that require detailed design or accountability, detailed simulations that include orientation, equipment, shading, and losses are the baseline. The official help also shows that, while the simplified side allows rough estimates using only a few general conditions, project design can handle surface orientation, equipment selection, series/parallel arrangements, thermal behavior, wiring, mismatch, far shading, and near shading. In other words, PVSyst is software whose result granularity varies with the depth of input, and practitioners should first understand what and how much to include.

Required Data 1: Installation Site and Meteorological Data

What you need first are the installation site details and meteorological data. The official help explains that a site's latitude and longitude are used to calculate the sun's position at each moment throughout the year. In other words, if the coordinates are vague, the assessment of the underlying irradiance conditions will be off even if the azimuth and tilt you enter later are correct. This is especially true when comparing multiple candidate sites or when the actual plot is slightly offset within a wide area—if you set the site location carelessly, it will be difficult to correct later. Placing the correct location first is the starting point for PVSyst input.

Regarding meteorological data, PVSyst is developed assuming time-series weather files. The official help states that there is a function to import external meteorological data, which can read hourly data and convert it into the internal format. The custom import description requires that one line corresponds to one time step and that the time resolution be hourly or finer. Available variables include global horizontal irradiation, diffuse irradiation, temperature, wind speed, and so on, and the recommended variables to import are global horizontal irradiation, diffuse irradiation, and ambient air temperature. In other words, in practice the basic approach is to make sure at least the irradiation and temperature are accurately captured, and to supplement wind speed and additional variables as needed.

Even when creating a site from monthly data, what must be provided at minimum is clearly defined. The current help states that, when importing custom monthly data, the minimum required columns are global horizontal irradiance and ambient air temperature. Diffuse irradiance and wind speed can be added, but without this core data you cannot properly construct the site's meteorological conditions. Conversely, the meteorological data entered into PVSyst cannot be arbitrary; consistency between solar irradiance and temperature is of utmost importance. Whether using on-site measurements, existing datasets, or typical meteorological year data, if you do not pay attention to site representativeness and temporal representativeness, the resulting figures will be taken out of context.

Another easy-to-overlook point is that the installation site and the meteorological observation site are not necessarily the same. The official help also warns that meteorological data are valid only for the observed or interpolated location, and that this location does not necessarily coincide with the project site. In other words, even if you think you are using nearby data, differences in elevation, terrain, coastal versus inland conditions, snowfall or local wind patterns can become error factors if used as-is. What you input into PVSyst should not be just a filename, but the meteorological conditions that can represent that site.

Required Data 2: Azimuth, Tilt Angle, and Installation Method

Next, what is required is the array orientation and the mounting configuration. In the official help, Orientation is treated not as a mere angle setting but as a central concept linked to the electrical-side subarrays. Because it can handle not only fixed racking but also multi-surface arrangements such as opposite-facing layouts and trackers, the input here is the process of defining "which directions, which types of surfaces, and how many of them exist." Much of the reason results change in PVSyst actually comes from proceeding while the placement of azimuth and tilt remains ambiguous. Correctly distinguishing the mounting configuration is as important as the meteorological data.

For fixed installations, the basic inputs are the tilt angle and the azimuth. However, be aware that PVSyst’s definition of azimuth can differ from the conventions used in architecture and drawings. According to the official help, in the Northern Hemisphere PVSyst defines azimuth with south as 0 degrees, west as 90 degrees, east as -90 degrees, and north as 180 degrees. In Japanese practice many people are accustomed to expressing azimuth with north as the reference rather than due south, so getting this conversion wrong can lead to seasonal variations in energy production that look plausible but are incorrect. One common mistake when entering data into PVSyst is reversing the sign of the azimuth.

Also, orientation is not determined solely by how it appears on the drawings. Under the subarray concept, strings that belong to the same subarray should, in principle, have the same orientation, and mixing modules of different orientations within the same string is considered inappropriate because the mismatch caused by differing irradiance conditions becomes significant. Conversely, the approach on the parallel side follows a different logic. In short, the azimuth input in PVSyst is not merely a matter of counting the number of roof surfaces, but also includes how to group modules electrically as homogeneous units. If this is handled carelessly, the resulting discrepancies will propagate through to downstream equipment selection and shading analysis.

Please translate the following input into English.

Required Data 3 Solar photovoltaic module specifications

The third is the specification of the photovoltaic module itself. In PVSyst, a module is not represented solely by its nominal output. The official help organizes basic data such as reference irradiance, reference temperature, short-circuit current, open-circuit voltage, maximum power point current, maximum power point voltage, temperature coefficients, and so on. In other words, the module inputs in PVSyst are not just about the size of the rated capacity but are inputs to reproduce how electrical characteristics change with temperature and irradiance variations. It cannot be handled only by the capacity listed in estimates or overview documents.

Furthermore, module dimensions and cell configuration cannot be ignored. The official help states that module area forms the basis for efficiency calculations, and the number of series cells is an assumption used by the internal model. In addition, the number of bypass diodes and the subdivision into sub-modules are used for electrical shading calculations. This may appear to be intended for advanced users at first glance, but in practice it is precisely the projects where you need to evaluate roof obstructions and inter-row shading rigorously that are most affected. If a module’s outline and internal structure are ambiguous, even the way its output drops under shading becomes inaccurate.

Also, even when using a model already registered in the module database, you should not blindly hand it off. The official help shows that a module definition contains multiple sheets—basic data, dimensions and technology, additional data, measurement data, and so on—and the model is composed of a fairly large number of parameters. You need to verify whether the specifications planned for the project match the conditions in the database, and determine how to handle temperature coefficients, tolerances, and initial degradation. For PVSyst input, what matters is not selecting the module type name but whether the chosen module definition represents the conditions of the current project.

Required Data 4 Conversion Equipment and Electrical Configuration

Fourth is the power conversion equipment and electrical configuration. The official help explains that a grid-connected System is composed of modules, strings, inverters, and the connection to the grid. When defining a sub-array, the basic inputs include the required nominal capacity or available area, the selected module, and the selected inverter; PVSyst then proposes an appropriate configuration based on those conditions. In other words, this step is not just about choosing equipment names, but about designing how much capacity will be arranged in which series/parallel configuration and connected to which power conversion equipment.

The important point here is the consistency between the number of modules connected in series and the input voltage conditions. The official help states that, for a sub-array configuration, the minimum array voltage under worst-case temperature conditions must not fall below the inverter’s MPPT voltage range, and conversely the maximum array voltage and open-circuit voltage at low temperatures must not exceed the upper limit. On the inverter side, key items are also specified, such as minimum MPPT voltage, maximum MPPT voltage, absolute maximum input voltage, and startup power threshold. If you increase or decrease the number of series-connected modules while only worrying about energy yield, this consistency can be lost and the design may become impractical.

Also, inverter efficiency is not a single number. The official help explains that efficiency is treated as a nonlinear characteristic that depends on the instantaneous input or output, with threshold effects appearing at low output and internal losses and output limitations affecting performance at the high-output side. Therefore, PVSyst inputs for power conversion equipment are not satisfied by the rated capacity figure alone, but must also include how efficiency behaves across the operating range. If this is left ambiguous, evaluations of annual conversion losses and clipping will be misaligned.

Furthermore, under the sub-array concept, strings connected to the same input should basically be homogeneous, and mixing different modules or different numbers of series-connected modules should be avoided. Just because it can be calculated in PVSyst does not mean it is reasonable as an actual installation. In practice, the electrical configuration must be determined including wiring plans, combiner box configuration, MPPT allocation, and allowance for future expansion. Inputs to PVSyst are a mapping of that design philosophy, and calculations run under assumptions that do not match the site configuration will only produce figures that are difficult to explain.

Required Data 5: Shadows, 3D Placement, and Array Correspondence

The fifth is data concerning shading and 3D layout. People who are new to PVSyst tend to view shading as “an item where you enter some percentage loss rate,” but in practice that alone is insufficient. The official help explains that there is a Module Layout function to calculate nearby-shading electrical mismatch losses in detail, and that it is necessary there to define each module’s position in 3D space and which string or sub-array it belongs to. In other words, shading input involves incorporating into the design not only the presence of obstacles but also which modules on which surface are shaded and how.

The important point here is that the 3D scene and the electrical system are not separate worlds. The official help states that subarrays are defined in the System menu, and on the 3D scene side you must create 3D fields that correspond to the module counts and orientations. If the module counts per orientation do not match, or if the 3D-side area does not align with the electrical-side module layout, consistency checks will flag issues and in some cases the simulation cannot be run. If the assumptions of the drawing team and the electrical team diverge, PVSyst will likewise show inconsistencies.

Also, Module Layout is normally a task that should be carried out toward the end of the design. The official help also indicates that the 3D construction of shadows and System definition need to be firmly established first, and only after that should module arrangement and electrical assignment be finalized. If orientation or sub-array configuration are changed significantly later, the definition of Module Layout will also need to be revisited. Therefore, for shadow inputs in PVSyst, it is more reasonable to refine them carefully after the basic conditions have been fixed rather than to tinker with them roughly at an early stage. It is important to determine the dominant factors for each project—such as distant horizons, nearby obstacles, inter-row shading, and protrusions of rooftop equipment—before entering them.

Required Data 6: Loss Conditions and Operating Conditions

The sixth is the loss conditions and operational conditions. This is the part that tends to produce the biggest differences when interpreting PVSyst results. In the official help, array losses are listed as shading, incidence angle correction, low-irradiance losses, thermal losses, module quality differences, mismatch, wiring losses, and so on. Other explanations also state that in detailed design you can analyze fine effects such as thermal behavior, wiring, module quality, mismatch, incidence angle losses, and far-field and near-field shading. In other words, PVSyst’s energy generation is not determined solely by equipment capacity, but varies greatly depending on which losses are anticipated and to what extent.

What you should know here is that PVSyst does not require everything to be entered exactly from the start to run. The official help explains that many loss parameters are initialized with typical default values and that the first calculation is designed to produce average results. This is convenient, but it is also risky. That is because those defaults are merely general assumptions and will not automatically account for site-specific soiling, wiring distances, thermal environment, downtime rate, maintenance regime, or voltage constraints. While it can be used at the estimation stage, you should avoid submitting deliverables with the default values unchanged on projects where accountability is required.

Operational conditions can also be important depending on the project. The official help indicates that even for grid-connected systems, you can add and handle items such as self-consumption load profiles, storage, and grid constraints. In other words, the inputs required by PVSyst are not simply the same six items filled in mechanically; the required level of detail varies depending on whether the project is primarily for selling power, primarily for self-consumption, or may be subject to output curtailment. Practitioners need to decide what to enter not just by looking at generation, but by including how the system will be operated.

Please translate the following input into English

Practical considerations to note before providing input

By the time you have reviewed these six items, you may feel that PVSyst requires many input fields. That is indeed the case, but what really matters is not "perfectly filling in every field all at once." The official tutorial also recommends creating the project first by entering the site and meteorological data, then building the basic system configuration, and afterward progressively adding distant shading, near shading, and loss conditions. There is a reason for this order. If the foundational conditions are unclear, focusing first on detailed shading and minor losses will not yield stable results if the base is off. First solidify the basics, then add the dominant factors one by one — that is the shortcut to mastering PVSyst in practice.

Also, for input values, their consistency is more important than their mere presence. For example, if the relationship between site coordinates and the meteorological station is ambiguous, the definition of azimuth is reversed, module specifications and the intended products are mismatched, or the inverter's voltage window and the number of series-connected modules are inconsistent, PVSyst may perform calculations but the results will be difficult to use for design decisions. In practice, coordinates, elevation, azimuth, module datasheets, equipment specifications, single-line diagrams, layout drawings, and obstruction conditions are often stored separately, but at the stage of entering data into PVSyst they need to be bound into a single logical set. If this is done, explaining to stakeholders and keeping up with specification changes becomes markedly easier.

When importing meteorological data from external sources, quality checks are indispensable. The current official help states that when importing a custom weather file there are range checks and quality-control mechanisms, and that the user should review the time periods that trigger warnings and decide whether to correct them externally, exclude them, or use them as-is. This is an important concept. It is not enough to be reassured simply because PVSyst issues warnings; it is the practitioner’s responsibility to understand the cause when a warning appears and to judge whether it is acceptable to adopt the data as a design assumption. Only by including verification of data quality does the input become a design condition.

Finally, adding more detail does not necessarily increase accuracy. For decision-making, a concise input that is organized within a meaningful scope is more useful than detailed inputs of low accuracy. For example, if the shading assessment is still at a rough stage, it makes sense to first fix the site, meteorology, orientation, and basic equipment configuration and perform a sensitivity check, then add shading and losses. PVSyst is strong at comparisons, so using multiple Variants to show differences in assumptions increases the credibility of the results. In practice, it is more valuable to demonstrate how much each assumption affects the outcome than to produce a single “correct” value in one shot.

Summary

The data required for input into PVSyst can be broadly divided into six items: the installation site and meteorological data; the installation method including azimuth and tilt angles; the specifications of the photovoltaic modules; the converters and electrical configuration; shading and 3D layout; and loss conditions and operational conditions. Even in the official documentation, PVSyst treats these not as separate items but as interconnected design conditions. For that reason, the shortest route to understanding what PVSyst is is not to memorize a list of functions, but to grasp which results are supported by which inputs. Only when you can explain not just the generation figures but also the rationale behind those figures will you be able to use PVSyst in practice.

And to improve the accuracy of these inputs, it is essential not only to make settings at the desk but also to reliably capture the site’s position, elevation, azimuth, and obstruction conditions. Especially for ground-mounted installations and large roof projects, if the initial on-site assessment is inadequate you will end up having to revise PVSyst assumptions repeatedly. If you want to increase the accuracy of on-site positioning and layout verification, utilize an iPhone-mounted GNSS high-precision positioning device such as LRTK and establish site coordinates and equipment positions early; doing so makes it easier to improve the reliability of the location information and layout conditions entered into PVSyst. The accuracy of the simulation is determined not only by what is entered on the input screens but also by how accurately you can bring in on-site information.