Linda Thoren

Hello and welcome ! The first steps of how to import custom weather data into PVsyst is explained in our Help in the following link: https://www.pvsyst.com/help/meteo-database/import-meteo-data/custom-meteo-files/index.html Kind regards

Sorry I don't really understand what you want to. The Ohmic losses can be defined in the Detailed losses window

Bonjour, Dans vos exemples, l’inclinaison du toit est de 30° et 10° respectivement, et les panneaux sont-ils installés directement sur le toit incliné ? Dans ce cas, il n’est pas possible de réaliser une simulation bifaciale, car peu ou pas de lumière atteindra l’arrière des panneaux. Si les panneaux sont installés sur un toit plat avec des tables inclinées à 30° ou 10°, la simulation bifaciale est possible. Dans ce cas, l’espacement entre les rangées devrait être supérieur à 1 m si la table mesure près de 4 m.

Dear, indeed, the total current should be considered.

In a project you can create multiple variants (both in version 7 and 8). Since the results will be for the complete system, you have to define your sub-system (for instance one inverter at the time) in separate variants. Thus, in the system window etc., define only 1 inverter and run the simulation. You can then make another variant of your project with the second inverter etc.

Hello, At the moment, PVsyst only provides yield and performance results for the complete system as a whole. Viewing results per inverter is not yet available (though it is on our roadmap). If you need results for each inverter separately, the current workaround is to simulate each inverter as its own variant.

Hi, The execution of the shading factor calculation may take some time, and has to be evaluated at each simulation hour. For speeding-up the simulation execution, we calculate a table of shading factors for specific sky orientations (every 10° in tilt and 20° in azimuth). Then at each step, the simulation can calculate the exact sun's position, and interpolate in this table ("Fast" shadings calculation"). This table is also used for the elaboration of the shading factor on diffuse and on albedo integrals. You find more details in our help, for instance the treatment of the Beam component: https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/treatment-of-the-beam-component.html and the shading factor table: https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/shading-factor-table.html Kind regards

Hi, A near shading loss of 2.8% for the system layout shown in your screenshot is within a reasonable range and you probably have to increase the pitch by a lot to see an effect on the near shading losses. The most accurate diffuse shading calculation will be obtained by using the "All trackers" option, as in your current example. For an exercise to better understand the impact of diffuse losses, you can instead select the "Custom tracker" option and choose a set of tables located at the very edges of the system. This option calculates shading only for the selected tables, then applies the same shading pattern to the rest of the system. If you run the simulation with "Custom tracker" selected for tables that have fewer surrounding obstacles, you should observe a decrease in near shading losses. Note that this method is only for testing and exploring the effect of table placement on diffuse shading—it is not the recommended approach for an accurate production estimate.

Hello, If you have no shading object or topography and have activated the backtracking, the near shading losses likely stem from the diffuse shading. The diffuse shading definition for trackers can be found in the Near shading window, Tools, Tracker diffuse shading definition. By for instance increasing the pitch, the diffuse shadings will be reduced.

Hi, The idea behind the unlimited sheds field type, is to allow for simulation of the shadings without the complexity of the 3D scene. Thus you are always simulating the mutual shading between the rows in a 2D representation (compared to the 3D scene). One simplification with this 2D representation is that the edge effect is neglected, that the rows are unlimited long. The number of sheds are important to define since the first and last row does not have the same shadings as the rest of the rows. Thus if you have 5 rows, 4 of the rows experience mutual shadings. If you have 500 rows, 499 rows will experience mutual shadings and thus this will impact the simulation results. Note that the unlimited sheds always include mutual shadings. To run a simulation completely without shadings, you should define fixed tilted planes and not define a 3D scene (though you can then define a bifacial project since the pitch and table size are needed for the bifacial calculation). You can read more about the unlimited sheds in the following help page: https://www.pvsyst.com/help/glossary/3d-editor/shed.html?h=unlimited+sheds

Hello, Currently, results such as generated energy and plane-of-array irradiance can only be produced for the complete system as a whole. If you wish to obtain results for a specific sub-system, you would need to simulate that sub-system separately and generate a dedicated output file for each one.

Good morning, I would think it is linked to the separator options. Double check the fields format and the decimal separator before exporting the output file and verify the format in your excel settings so that they match.

Hello Aidenn, I first notice that the power sharing has not been equalized in your print screen. All sub-arrays has the same Pnom/MPPT, though different installed PV power in each sub-array. This results in unequal Pnom ratios across the sub-arrays. You can toggle the "Auto-equal. Pnom option", or clicking on the weight icon for the specific configurations concerned. This will distribute the Pnom/MPPT values proportionally according to the installed PV power in each sub-array, thus equalizing the Pnom ratios. The production begins as soon as the MPP power is over the power threshold Pthresh of the inverter. The MPP power below this threshold is accounted as IL_Pmin loss. The Pthresh power may be understood as the power required for the Inverter internal circuits consumption. These losses might be reduced if activating the power sharing, since certain sub-arrays have rather low Pnom ratios. You can read further about in the following help pages: https://www.pvsyst.com/help/project-design/grid-connected-system-definition/inverter-array-sizing.html#difference-with-the-hourly-simulation https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-operating-limits.html

The number of rows is only used for the bifacial calculation for the backside irradiance, where the simplified 2D cross section view is needed. For the front side, the electrical shading is fully simulated as defined in the 3D scene.

The number of rows refers to the number of rows in the 2D cross-sectional representation of the system, assuming "unlimited long tables", and is relevant for the calculation of the effect of the first and last row of the array. In your case it would rather correspond to 38 rows, imagining the view in 2D. Number of sheds (rows) and accuracy - PVsyst documentation

Hello, In general it is fully possible to continue a project made in 7.4 in version 8.0.

Indeed, the hours where the wind exceeds the given threshold, the simulation will be done with the trackers in the defined wind stow position. You will not directly see any losses in the diagram though indeed it will result in a less optimized Global Incidence Irradiation. To properly evaluate the impact from the wind stow, you would have to run one simulation without activating this functionality and compare the two simulations.

Hello, In general, far shading affects the entire PV field uniformly — at any given moment, the sun is or is not visible on the field. As a result, it can potentially reduce the impact of near shading, since far shading may occur during times when near shading would otherwise be present, typically when the sun is low on the horizon.

With the option "Load values from a CSV hourly file" you have full liberty to define the load profile exactly how you wish.

Hello, In the version 8.0.13 we corrected a bug and a daily hourly profile is now normalized and saved properly. You also have the possibility to import a .csv file with hourly values for the full year. The different ways of defining a self-consumption profile are further described in this youtube tutorial:

The global irradiance in the plane of the array (GlobInc)depends on the tilt and azimuth of your system. In general, one would choose an orientation of the panels in a way that maximizes this irradiance, which is why the GlobInc is usually higher than the irradiance on a horizontal plane. When defining a fix tilted plane, you find a "quick optimization tool", illustrating in an order of magnitude what you could expect to gain (or lose) compared to a horizontal configuration at your site.

Hello, By importing irradiance data in the plane, PVsyst applies a reverse transposition to determine the global and diffuse horizontal irradiation required for the simulation. For the simulation, PVsyst will utilize the Global on horizontal plane as starting point. This is necessary as the optical treatment (shadings, IAM, etc) requires the beam, diffuse and albedo components. The reverse transposition and re-transposition can indeed cause some discrepancies with the original data. Verify that you in the Simulation use the Hay transposition. You define this is the project settings. You can read more about the transposition model in the following help pages: Transposition model - PVsyst documentation The Hay transposition model - PVsyst documentation

Hello, I suggest that you run a simulation with the bifacial parameters and export an hourly output file with all the relevant parameters, such as overload losses etc. This can not be done for individual strings but for the full system. Running several iterations should give you a good estimate of the losses.

Hello, The most straightforward way to evaluate bifacial gain is to run two simulations: one with bifacial parameters activated and one without. While the current itself does not differ between the front and rear sides, the rear side does contribute to the overall energy production. In PVsyst, the results are presented for the entire system and not broken down per string.

Hello, PVsyst is calculating the sun position based on the exact year accounting for leap years, when specific years are simulated. Thus, if you import a specific year that is a leap year though the 29th is missing in the data set, it will be considered as missing data and values will be 0 (similar to as if any other date of the year was missing). So values for February 29th will be zero (e.g., no irradiance), but the date will still be included in the simulation. March 1st will correctly follow as the next day.