Michele Oliosi

Hi, LID is a degradation pathway, which you can see as a definitive change in the module performance. It occurs in the first hours of exposure to sunlight, but then the effect remains. Degradation is modeled as a fixed ratio for the whole year, but in reality this loss should increase throughout the year. This is why we choose the mid-year mark as representative for the yearly degradation loss factor. Hence the 50% applied on the first year. Module array mismatch loss is different from degradation, you find its value in "Detailed losses > Module quality, LID, mismatch"

As you can see in the frames above what you have highlighted ("Number of rectangle-strings"), on your table there is a non-integer number of partitions. This means that either your tables are not consistent with the string length (can be an integer multiple or a simple fraction), or the length 31.75 is not exactly correct as a string length. The difference in length you are seeing is probably just the 0.54 and 0.34 remainder of the partitions that has shifted the partitions on the table. If your tables are just a multiple of a string length, the easiest is to use "Number of rectanlge-strings" on the tables to simply divide the string in the correct number of partitions.

I see ! I just remembered that in this version (7.2) there is a bug for trackers. In the object management window, the number of partitions is not affected to the right variable. It is connected to the size of the partitions instead which in turn makes it not work. Please use option 3 or update the PVsyst version.

Hi, There is no object management window in PVsyst 6, so I assume you are using a more recent version. Which version are you using ? I have tried to see if solution 1 had a bug in version 8.0.19, but everything works fine. You are probably correct that solution 2 may have an issue sometimes. The zone tool is rather old and sometimes misbehaves. Solutions 1 and 3 should be equivalent.

No the tracker angles are the same. The interpolation profile is only a profile Shading factor = f(tracker angle). Therefore the only changes are in shading factors (for diffuse and albedo).

Hi the reason is in the calculation of diffuse and albedo shadings. For more information you can see here: https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html This calculation creates an interpolation profile based on the available tracker positions. By changing the tracker limit, the support pointss of the interpolation profile are shifted, thus leading to (in principle slightly) different shading values.

Dear @PranavK, this is new to us and unfortunately I cannot say much without looking at the project. Can you send it over at support@pvsyst.com ?

Indeed, to model the front side irradiance (useful for monofacial) the height above ground is not used. There is therefore no problem in your comparison, even if you cannot enter the height above ground. One table = one module in your example. Therefore collector band width = 2382mm when in portrait and 1134mm when in landscape. If you check among all inverter manufacturers, there should be at least a few microinverters. However you can also define a new microinverter on your own, by modifying an existing one. You can therefore make a very low power one.

You can set up the module layout tool in one of your projects for a sample visualization in a concrete case. The impact of inverter limits is displayed and is similar to the simulation so it will help understand. Other than that there are some explanations in our help, for example: https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-operating-limits.html However, there is no visual representation of what actually happens during a simulation. You could check the output variables IArray and UArray though. Together these represent the DC array's operating point.

You are correct about width / length, although a shed may be several modules tall... this means that the collector band width could be 2, 3 or more times the size of a module. About your system: the best way to model this in PVsyst is not via the "unlimited sheds" orientation. The unlimited sheds is useful when you have multiple rows of tables. Instead, your system is basically one table (with a gap). As far as the front side irradiance goes, the best is to do a 3D drawing and use the module layout shading calculation mode. Unfortunately PVsyst does not model the backside irradiance in 3D, which means that in your case the backside irradiance model (bifacial model) would be quite wrong. Indeed, there are multiple 3D specificities in your system: the raised part of the roof, the gap in the modules, the different albedo, and the mounting structure. All of these cannot be modeled in PVsyst. You could use the unlimited sheds as an approximation. In this case, please set the number of rows to 1, and the collector band width to 5 times the length of a module (+ gaps). The hole in the middle and differences in roof height cannot be modeled. Then you can use the bifacial model, but note that the results will be approximative.

@AHSAN ALI An important point here is understanding what "shed" means. A "shed" in PVsyst is one row of PV tables in a row arrangement. A "shed" is not the same as a module: Because one table may have several PV modules. Because one row of tables has several tables in it. In the diagram of the "Orientation" window, you can see three (generally) such rows depicted in blue. This is a cross-section or side view of the row arrangement. This also means that the size of the tables is what you will enter in the parameters "coll. band width" and "top/bottom inactive bands". What matters is the vertical size, in other words the "height" or "width" depending on your perspective, but usually the short side of a table. The "Orientation" window is not where you will define the total number of modules. Here only the geometry matters. The "System" window is where you will define the number of modules properly. In your example with 8 + 8 modules, you should define "Nb. of sheds" as 2.

Hi, PVsyst will use the operating range to displace the operating point on the IV curve. This displacement away from the MPP will cause losses, captured in the variables IL_..., e.g. IL_Vmax for the maximum voltage. The parameters here are the Vmax and Vmin parameters. Note that a different yet related loss, the derate at very high or low voltage levels (or more generally as a function of voltage), is not captured by PVsyst. We do only model a voltage dependence by means of three caracteristic efficiency curves based on three ordinary voltage points. However this may not capture the full voltage derating curve.

@sauld no you are right, there could be some losses that would be missed by this approximation. Unfortunately this is a compromise, because currently MPPTs can only receive identical strings in the System definition in PVsyst. However for most cases these losses are rather small. The most important is the string to string mismatch (usually shading effects are even smaller because you need a very specific shading pattern for the multi-MPPT to help). You could add an estimate of these losses to the mismatch losses manually. You can estimate them using a tool found from Home window > Tools. There is a similar discussion here (see the last answer by my colleague Luca):

Unfortunately, it is not possible to put two different types of string on the same MPPT in PVsyst. You must either approximate the module rated power so that the MPPT are homogeneous, or you should redefine the inverter as having 6 MPPT, although this could somewhat affect the inverter losses.

No currently only a partial selection of variables can be added as monthly tables. However EUseful is actually a composite variable, it is equal to other variables depending on the case. For example, here it should be equal to "Energy from the sun".