Michele Oliosi

It depends on the layout of the strings in the field. We don't have a rule of thumb, but you could do something along these lines: you can make some simple assumptions concerning your field. For example, if your trackers are 2P (two in portrait), then you could assume that there are two strings per tracker, i.e. 1529 strings total. Then you could also assume that the trackers are roughly arranged in a square terrain, with GCR 0.4. And that modules are 1x2 m^2. Let's say x is the number of trackers on a single line along the axis and y is the number of rows. Roughly, y * 2 (# modules in table height) * 2m (module height) / 0.4 (GCR) = 24 (# modules in table length) * x * 1m (module width), i.e., y = 2.4 x. The total number of trackers is 1529 = y * x = 2.4 * x^2. Solving, that you get roughly x ~ 25 and y ~ 60. So 60 rows should be roughly it. Note that above 10-20 rows, the impact of the number of rows becomes quite small, so for systems of this size the exact values are not important at all.

We have calibrated the number of partitions based on the module layout calculation. Therefore, all these effects are taken into account in the partition model. The partition model per se is an approximation that will not always reflect the details of the electrical effect of partial shadings, but that should recover a plausible loss value for a long term (e.g. a year) simulation. However, for the case of the 2x14 structure, it should not be a partition that traces through the middle of the modules. That would be correct for the case 2T. Instead, this 2x14 structure is in the case 2TU, which has two partitions with size 1x14.

Hi ! Which version are you using? I am asking this because in the current version this is not stated, as far as I know. The unlimited orientations do always include mutual shadings. The shadings calculation is inherent and is not related to choices in the "Near shadings" window. The number of rows (with the frenchism "sheds") is actually quite important for the evaluation of mutual shadings: it does affect simulation results.

Hi ! Yes, in general it is necessary to define partitions whenever you want to perform electrical shading calculations using the option "according to module strings". However, if you use the mode "Module layout" then the partitioning is not necessay as the submodule and structure is defined in the PAN file. No, in general the partitioning is not = to 1 string, sometimes you should count several partitions per string. For example, the half-cell parallel structure usually means doubling the number of partitions. You can find various examples here: https://www.pvsyst.com/help/project-design/shadings/electrical-shadings-module-strings/partition-in-strings-of-modules.html. Your cases are the 2TU and 2T respectively.

Hello ! This is normal. Since there is very little irradiance as a total on the PV cells, the efficiency derate is on the low end of the curve that Luca showed. You also must take into account that the loss diagram is an average over many irradiance conditions (probably ranging between 0 and 200 W/m^2). Once you put everything together, the average loss of efficiency may well be 11% (below what you would get by just examining the loss of efficiency at (21 + 0.75*168.1) W/m^2.

UPDATE and correction to the previous answer. The "far" albedo (AlbInc, AlbHrz, AlbShd) and the "near" albedo (between PV rows, i.e. ReflFrt) should not be included in the same quantity to compare to POA measurements. The exception to this rule is the case of POA measurements that are made at the end of a row (such as in your case Luis). The problem with including both is that there is a risk of overcounting. For example in the case of a single row, AlbShd and ReflFrt do somwehat overlap. What this means is the following: if you measure POA away from the PV rows, or on the front row of the system, you can compare your measurements with GlobInc, or GlobHrz (which is like GlobInc but using the horizon profile as a shading). Between both, I'd rather use GlobHrz. Do not add ReflFrt. Instead, if you are measuring between the rows, the "far" albedo contribution should not be counted, and you should use ReflFrt instead. This means that you can compare to, e.g., GlobHrz - AlbHrz + ReflFrt. Note that if the POA measurement between rows is well below the top of the PV rows, then you should at least shade diffuse light, i.e., BeamHrz (horizon shaded beam) + CircHrz (horizon shaded circumsolar) + DiffShd (fully shaded diffuse) + ReflFrt (reflected irradiance between the rows). @Luis Zimmermann Sorry for the imprecise previous answers. This interaction between models is always a bit tricky. For your example, instead of BeamInc + CircInc + DifSInc + ReflFrt + AlbInc/2 + ( - HrzBLss - HrzCLss - HrzDLss - HrzALss/2) I would suggest now BeamInc + CircInc + DifSInc + ReflFrt/2 + AlbInc/2 + ( - HrzBLss - HrzCLss - HrzDLss - HrzALss/2)

BNPI conditions cannot be used as input in PVsyst. You could use the BNPI test report to re-evaluate the bifaciality factor. But per se the BNPI result will not be used in the simulation (in which irradiance and temperature conditions vary at every step). To calculate the bifaciality factor the approach would be as follows. The basic equation is Pmeas(BNPI) = P(1000+phi * 135), and solve for phi (bifaciality factor). This could be solved by trial and error using the PAN file interface to evaluate P(irradiance, 25°C), but it will involve manual steps. Once you find which irradiance yields P(BNPI), you can easily find phi.

Yes, actually the irradiance of front side + backside*bifaciality factor are put together, which gives an effective irradiance evaluation. Only after that, the PV conversion model applies. Indeed, the light reaches the same cells, be it from the front or the back. The same low-light performance is therefore taken into account for front and back (up to the bifaciality factor).

Regularity is defined vaguely by PVsyst. If the system is approximately regular, e.g., patches of trackers or tables that are more or less evenly spaced, then this can be considered “regular” in the PVsyst sense. In that case, you can use the 2D bifacial model jointly with the 3D scene. PVsyst will check the following points: The RMSD of the pitch distribution. If the RMSD is too large, PVsyst will throw an error. You can change the threshold of the error in the advanced parameters. Whether the tables are the same height. If there are differently tall tables, PVsyst will throw an error. Whether orientations have more than 2 rows. If there is only one row of tables, PVsyst will throw an error. The average axis tilt of the trackers in each tracker orientation. If the average axis tilt is too large, PVsyst will throw an error. You can change the threshold of the error in the advanced parameters.

Currently, the rear-side model of irradiance is two-dimensional (cross-section). However, it is compatible with a 3D drawing. If you have a 3D drawing with a regular arrangement of tables, you can activate the 2D bifacial model to compute the rear side irradiance.

Automatic mode will select the tracker with the highest GCR as reference. It is an alternative way to select the tracker pair. If you deselect the tracker pair, the parameters shown in Pitch, collector width, etc. can be manually adjusted.

This is a bug, I have created a ticket to address it. In past versions, it used to be present in the report.

Sorry, this warning is not appropriate in your setting, we still need to address the way it is triggered so that it becomes more relevant. I think it was added with the case of different nominal orientations in mind. But currently, for your case, i.e., one nominal orientation with many variations due to the topography, the way to go is: use only one orientation. This has one drawback: the averaging error and the mismatch caused by the individual orientations are not taken into account, i.e., on this end the calculation is a bit optimistic. But since our calculation is already conservative in other ways (e.g., backtracking modeling), I do not think this small underestimation of losses is critical. In the future, we want to account for these two losses we are yet missing.

Hi @Cole Noble, If you import hourly GHI data into PVsyst meteonorm or DirInt are not used for DHI. Instead, the Erbs model is used. However, the meteonorm generation is likely used for the ambient temperature if it is not present in your data?

Hi @tommm, no indeed, as you have understood, there is no way to organize per inverters in this interface. However, the solution you hinted at should work. I.e., you can define different inverters and open the window “Multi-orientation daily sharing” from sub-arrays with the three different inverters respectively. Make sure everything is checked.