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.

This is not intended behavior. Can you explain how exactly you created this plot? Is it a simulation result, or were the values obtained with the tools in the bifacial model window?

Differences in the results of less than 0.1% are within the systematic simulation uncertainty and could be due to rounding errors. They are considered as not significant. The other behaviors described for the aging tool are reproducible and will be fixed in one of the next releases.

Hi Ravi, Up to PVsyst V7.3.1 one could only specify the total cell area. In V7.3.2 it became possible to introduce cell width and height. Together with this, there is a mechanism that automatically determines part of the dimensions, based on standard PV cell sizes. This only works for standard crystalline silicon cells, and gives these error messages if you use cell sizes that are not very common, like yours. We will fix this for PVsyst V7.3.3, where it will be possible to freely choose the cell dimensions.

It is the first case in the question of the user that is correct. You import each of the 60 sets of minute-level data as if it were hourly data. You therefore need to use the correct time shift, and since the data will be interpreted as hourly values, you need to specify a multiplier in the conversion format if the data is in energy units. PVsyst will run the simulation as a normal hourly-steps simulation, therefore you need to do a renormalization of the energy variables in the results to get the equivalent of a minute-level simulation. Please note, that this approach does not take into account the thermal inertia of the PV modules. This leads to overestimated temperature fluctuations in the PV modules. In the PVsyst study this was handled by fixing the module temperature for each full hour to a value obtained with a simulation on aggregated hourly weather data, as explained in the paper.

At the WCPEC8 conference of 2022 in Milan, Italy, PVsyst presented a study on sub-hourly clipping effects.: "A model correcting the effect of sub-hourly irradiance fluctuations on overload clipping losses in hourly simulations", 2022, André Mermoud, Bruno Wittmer, Michele Oliosi, Agnès Bridel, Adrien Villoz. In this study, in order to estimate the clipping on a minute-level, a method was used, where minute-level weather data was split into 60 sets, one for each minute in the hour. Each set was then simulated in hourly steps, and the results of the 60 simulations were aggregated to obtain the equivalent of a minute-level simulation. Concerning this procedure, which is also described in the paper, the following question was asked by a PVsyst user:

There are two ways to achieve this: You can do this by changing the number of inverters or MPPT inputs in the 'System' tab. You can change the inverter in the 'System' tab to one with different capacity. You need to supply the filename of the inverter that you can easily find if you open the inverter in the database. If you would like to explore extreme DC/AC ratios, you might consider to increase the maximal tolerated overload losses in 'Project settings' before running the batch, else you risk to get some empty lines in the batch results.

The inverter nominal and maximal power are defined in the OND files. There is also a parameter called 'Power threshold' which defines from which power on the inverter starts converting DC to AC power.

We have added your request to our ticket system.

In PVsyst, right now the load profile is considered to be entirely active power. All reactive power generated by the inverters, which work at a constant power factor in PVsyst, will go to the grid. This is why in systems with self-consumption and/or storage the power factor at the injection point is not constant but varying in every simulation step.

This is most likely an interference between PVsyst settings, Excel/Windows settings and the variant name: For the output file of PVsyst you can select the column separator, which by default is a semicolon. In Excel and Windows you can define the default list separator, which often is a comma. If both separators are the same, double-clicking on the CSV file will open that file in Excel, and detect properly the columns. If the separators are different, you need to do the 'Text to columns' conversion as explained in the original post. If the variant (or project) name contains once ore more times the separator that is recognized by Excel, you will get additional columns when opening the file, with the subsequent warning message. The solution therefore is either to have the same list separators in PVsyst and Execel/Windows, or to avoid having the Excel/Windows separator character in the variant (and/or projec)t name.