Bruno Wittmer

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.

You can create a weather file with measured module temperature and have this value fixed at 25°C. To get this weather file (.MET file), you need first to create a corresponding CSV file with the additional column giving the module temperature. The easiest way is to stick to the PVsyst standard format as described in: https://www.pvsyst.com/help/meteo_pvsyst_standard_format.htm If you don't have a starting point for the CSV file, you can run a simulation and create an hourly ASCII output files containing the variables GlobHor, DiffHor and T_Amb. Then rename the column headers according to the PVsyst standard format. Add a column with the module temperature, and which should be named 'TArray'. Fill the column with constant values at 25°C. You can now import the csv file as 'Known format'. Alternatively, you can use the 'custom' weather import and define manually which column contains which variable. Once you are using a weather file containing the variable TArray, you will have the option to use the module temperature from the MET file instead of applying the thermal model that calculates the module temperature during the simulation. This option is found in 'Detailed losses -> Thermal parameters'. Note that the option is hidden if the MET file does not contain the measured module temperature. If you run the simulation like this, the 'PV loss due to temperature' will vanish.

It is enough to set the length to zero. In this case the cross section will not matter.

Where do the irradiance values come from, and what do the negative irradiance values mean exactly? With the formula you are using, negative irradiance leads to negative generation.