Michele Oliosi

Hi, Yes, indeed, the “All trackers” option will average the shading factor tables on all the trackers in your scene. This is evaluated at 7 different tracker angles, integrated over sky directions, and then interpolation profiles are then generated. In the end, you have a profile that takes in a tracker angle and gets out a shading factor for the diffuse and albedo components. In general, the best is to use the “All trackers” option. Since it takes the whole scene into account, it is the most representative. Besides, the “central tracker” may or may not choose the neighbors properly, i.e., it is good to check the selection automatically made by PVsyst when using this latter option. The only downside to the “All trackers” option, is the long calculation time at the “simulation initialization” stage.

It's difficult to say whether it's useable or not, there could be some cloud enhancement effect for example. Some locations also have higher extreme Ktcc values. But at the very least, it raises the question of the calibration of your sensors. If possible, I would suggest looking at possible problems on the hardware and data collection side. But before this, I would suggest correcting the time shift (as noted 61 minutes of time shift are found) directly in the file. As noted here: https://www.pvsyst.com/help/meteo-database/import-meteo-data/pvsyst-standard-format/index.html you can use the tags: “#Hour Shift;" and “#Time Shift;” to apply the time shift when importing. This may improve the results of the import.

@Edwin Tellez In this case, you should define two "identical" orientations. Assigning one sub-array to the first and another to the second, corresponding to the 2V and 3V arrangements respectively, will let you combine the two geometries. In v8, it is possible to work with different backside geometries in the same variant ("Bifacial models") provided they are in different orientations.

@Vamsee Since v8, it is now possible to have multiple bifacial orientations, or a mix of bifacial and monofacial orientations (the latter do not require defining a backside geometry). As long as they belong to different orientations, you can have a sub-array with bifacial modules, and another sub-array with monofacial modules. However, it is not possible to define spectral corrections sub-array by sub-array. It is therefore not really recommended mixing CdTe and Bifacial modules, at the moment. I will add this feature to our request list.

Originally I thought your pyranometer may not have been at the top of the row. This means that it would have “seen” other PV rows in its zenithal hemisphere, even in hours without direct shadings (which you could filter out). This is accounted for in the diffuse shadings. But in your case, the diffuse contribution to the measured irradiance is unshaded by mutual shadings.

2) Ah yes, this makes sense. I agree with your suggestion.

Hi, at the moment PVsyst cannot simulate the backside irradiance for domes. Note that in general the bifacial gain of dome structures is negligible, unless they are installed very high above the ground.

There can be some differences between 7.4.8 and 8.0.5, these are explained by improvements of the modeling. However, in your case they seem a bit large (still about 0.5% or so in total). This might be normal or not, to be sure we would need to take a detailed look at your project. For this you would need to send it to support@pvsyst.com (mentioning this forum post). Note that the zip archive should be made to contain all necessary files, for example by using the "Export" functionality in the projet window.

Can you go to Near shadings > Table, and click on “recompute” ? This should update the shading factor table. Let us know if the issue persists.

2) I suspect that this pyranometer placement is biased towards higher irradiance than what is actually incident on the backside on average. Indeed, because of mutual shadings, the irradiance is not homogeneous on the backside. The lower end receives less light than the top. For the front side, PVsyst outputs GlobInc, which is the irradiance in the plane of array, without yet applying mutual shadings. For the backside, this is not the case, mutual shadings are already accounted for in the different irradiance contributions. For the sake of the comparison with the measurements, I would suggest defining a different variant in PVsyst that exchanges the front and backside. In this way, you can compare with BeamInc + CircInc + DifSInc + ReflFrt +( - HrzBLss - HrzCLss - HrzDLss), the latter parenthesis if a horizon exists, of this variant with the real backside measurements. Note that because the backside pyranometer sees other rows, the albedo contribution should be removed. For the front side, since it is in the front row, there is a far albedo contribution: BeamInc + CircInc + DifSInc + AlbInc+ ReflFrt +( - HrzBLss - HrzCLss - HrzDLss - HrzALss). 3) I am a little surprised by the low backside to front side irradiance ratio. Is the azimuth not 90°?

Hi ! We have unfortunately discovered two bugs that plagued version 8.0.4 and previous. This affected in prevalence average orientations on a complex topography, or whenever there were mesh shading objects such as the fences. We fixed these in version 8.0.5. Please let us know if this fixes the issue, thanks in advance !

Thank you for reporting this issue. If you compare the loss diagrams, this seems to be related to a discrepancy in the maximum voltage threshold loss of the inverter. This might be related to the degradation definitions. Can you check whether the checkbox “Keeps calculated Mismatch values” in Detailed losses > Aging has been checked ? If not, this may be an explanation, as the array voltage point may be slightly different between the two runs.

Yes. A bug was corrected in update 8.0.5, that afflicted cases where an averaged orientation had a large orientation spread. In these cases, the shading factors were pessimistic for low sun heights. Now things should work properly.

Dear Luis, Regarding the albedo, did you enter it in the bifacial model? For the purpose of backside irradiance calculation (and also for the light reflected from ground to front) the albedo should be entered in system > Bifacial system > first tab. Other than that, I wonder about your pyranometer placement. Do you have some images/details on that ? There could be some differences depending on the height at which they are placed (and also the pitch between your rows). Finally, could you share a screenshot of your loss diagram ?

1) I think this depends on how the 3D scene was defined. If they are defined as individual tables, they will be turned each around their own center. Each “array of tables” will be turned as one object with a common center to the whole array. 2) No, the azimuth is overridden. In general, when you have such questions on “what does PVsyst do in the optimization tool / batch mode” the best way to check is to use the batch mode. In the batch mode, you can modify the same parameters as in the optimization tool, and more. It has one interesting additional option, which is to store a variant corresponding to the batch modification: This allows to check whether the modifications make sense, afterward.