Bruno Wittmer

Currently PVsyst handles PV modules with IBC cells in the same way as other crystalline Si modules. We have looked into this issue, and to our understanding, the shading advantage of this technology is limited to situations where only a few (1-4) PV cells of a substring in a PV module are shaded, while the other cells are fully illuminated. We estimate, that these situations happen so rarely, that neglecting this effect will not lead to significant errors in the yearly yield calculation. Nevertheless, we intend to include the special behavior of IBC cells into our models, in order to account for this small improvement. The current roadmap foresees the availability of this feature by end of this year.

Dear Simon-Pierre, Please note, that in order to reach a larger audience, the forum language is English. Your question is probably meaningful for many other PVsyst users, and therefore I will answer in English. The generation of the single line diagram (SLD) in PVsyst has some limitations. As an example, some power optimizer architectures or ambiguous MPPT/inverter assignments can lead to this situation where the program is not able to build the SLD. The sub-array in the screen shot you posted does not contain anything special that would prevent the generation of the SLD, but I see that there are other sub-arrays, and maybe the problem is coming from one of them. You can send a copy of your project to support@pvsyst.com, and we will have a closer look on why this happens. To export the project, please go to 'Files-> Export projects' in the main window. Select the project and click on 'Export'. This will create a single file with .zip extension, that you can e-mail to us. We are continuously improving the generation of the SLD, to cover more and more of the cases that are currently not handled. Additionally we will also foresee messages for the case that the generation fails, to give some feedback to the user rather than just disabling the button. I have added a corresponding ticket to our development pipeline.

There are several possible reasons why a non-zero azimuth could be the optimum. In general, an optimum at -5° means that on average there is more direct beam irradiation in the morning than in the afternoon. As you mention already, a significant horizon effect can be at the origin of this. Another possibility are systematic differences in cloud cover between morning and afternoon. In the optimization tool you can choose to display the variables 'GlobInc' and 'GlobEff', to get some hints on the origin of the effect. The GlobInc variable describes only the transposition and will therefore display effects that are already present in the Meteo data (like different direct/diffuse ratios in the morning and afternoon). The GlobEff variable contains shading effects and will therefore add effects coming from the horizon line.

The problem has been fixed in PVsyst V7.4.6 that will be published in the coming weeks.

This is a numerical imprecision in the calculation. This plot should indeed be flat, since the global light reaching the ground does not depend on the mounting height. The calculation is based on the 2D-section of the rows, and therefore does not consider border effects as suggested by chuang. It is only the light coming through the gaps in the rows that will be accounted for. The numerical imprecision leads to a variation of around 2% in this example. This is quite extreme and probably due to a rather small pitch (high ground coverage ratio GCR). More common GCR values in the range of 0.4 - 0.6 lead to an imprecision of less than 1% in this calculation. This extreme example will translate to an error of 2% in the total bifacial irradiance contribution. For a bifacial irradiance gain of around 10% , this would lead to an imprecision of 0.2% in the total PV generation of the system, which is a rather small uncertainty for a bifacial simulation. Most likely the bifacial irradiance gain is much smaller than 10% in this high GCR example, making the error that arises from this numerical uncertainty negligible.

The detailed calculation of the rear side irradiance is described in the help under https://www.pvsyst.com/help/index.html?bifacial_systems.htm In short, PVsyst calculates first the irradiance on the ground, accounting for direct and diffuse components. The scattered irradiance is given by the albedo value and the part reaching the rear side of the PV modules is calculated with the view factors. To this contribution of scattered light PVsyst will also add the light coming directly from the sun to the rear side as well as the diffuse sky irradiance reaching the rear side.

The tracker will always stay within the mechanical limit, in your example this would be +- 60°. If the backtracking limit angle is larger, this just means that the trackers will stay at + or - 60° until the sun is so low that they need to backtrack to avoid mutual shadings.

The shadings losses depend on the details of the PV system layout and on the sun paths, which in turn are a function of the geographical location. Furthermore the losses will depend on the specific weather, since the shading of direct and diffuse light needs to be calculated differently. There is no simple formula to calculate these losses, this has to be done by the software.

The hourly output files in PVsyst contain one line per hour, and the timestamp labels the beginning of the time interval. For example the hour labeled '10:00' is the hour from 10:00 to 11:00. In the hourly output files no aggregation at all is performed, each line represents an individual hour.

The pitch of the trackers has no optimum point in terms of energy yield. The shading losses will always decrease as you increase the pitch. Therefore the optimal pitch is the result of a financial optimization, that takes into account the decreasing gain with the associated system and land costs that increase if you move to larger spacing. You can use the 'economic evaluation' in PVsyst to set up a financial model that includes al the expenses and costs. Then you can use the 'batch mode' or the 'optimization tool' to find minimal values for LCOE (levelized cost of electricity) or maximal values for NPV (net present value) or ROI (return on investment). These tools are describred in the corresponding help pages of PVsyst.

The concept of sub-array in PVsyst is linked to the string configurations on the MPPT inputs of the inverters. If the inputs differ in string length, PV module type, PV module orientation or number of strings per MPPT input, then you should put these configurations in separate sub-arrays and use 'multi-MPPT feature' together with 'Power sharing'. The 'Power sharing' tool will allow you to tell PVsyst which sub-arrays belong to the same inverter. You can also use different sub-arrays to just group your inverters or MPPT inputs into logical units. However be aware that if you have a large number of MPPT inputs and are using the 'multi-MPPT feature', that this might slow down the simulation. If in your floating PV system the strings have all the same length and are all connected to the same inverter, you can keep them in a single sub-array even if physically they are in different floating islands.

Currently there is no specific snow model in PVsyst. The recommended way to account for snow coverage, is to use the monthly soiling losses. You need to estimate these monthly values outside PVsyst, either by simply using weather data on snow coverage, or by using some more sophisticated snow coverage modeling. You might also consider to increase the monthly albedo values in the 'Project settings' to account for increased ground reflection due to the snow cover.

Please make sure that the location for which the 23 meteo files are valid, is close enough to the site of the project. If that is not the case, the files will not show up in this tool. You can check this already in the project dashboard. If the meteo files can be selected from the dropdown list, they will also be visible in the 'Aging tool'. By default PVsyst will discard meteo files for locations that are further away than 10 km. You can change this threshold in the 'Advanced parameters'.

This is indeed an error that slipped into PVsyst V7.4.1, this will be fixed as soon as possible. In the meanwhile, please go to the report options and set this manually:

kWp means 'KiloWatt peak' and refers to the nominal power of the PV modules, which is given for 1000 W/m2 of irradiance. This is close to the maximum power you would expect at full sun, therefore the term 'peak'. This is used in the context of the PV modules, meaning the DC part of the PV system. If you are talking about the inverter nominal output you will see kWac or kVA being used.