Michele Oliosi

Indeed !

This post aims to present the main differences an user can encounter when using PVsyst 8.0.7 compared to PVsyst 8.0.6. Thin objects In versions 8.0.0 to 8.0.6, PVsyst did not calculate correctly the electrical shading losses for thin objects. This problem could be identified by inspecting the shading factor tables, showing inconsistent values when selecting “Thin objects table”: The calculation in PVsyst 8.0.7 now takes these properly into account. Electrical shading losses may be modified in your projects with thin objects because of this. Bifacial systems Several changes will affect projects with bifacial modules. No fundamental changes were made to the model, but default values and parameter labels have been updated. PVsyst 8.0.0 introduced the possibility of defining the number of rows and pitch used in the backside geometry model manually. Previous to that, the number of rows and pitch were automatically extracted from the orientation definitions, or from the 3D scene when available. This automatic evaluation was not always correct. For unlimited orientations, the number of rows used in the bifacial model is now forced equal to the number of rows in the orientation menu. Related fields in the bifacial menu cannot be edited anymore. See below in 'New Warning' for the behavior when opening a variant with simulation results that were using a user choice for the number of rows. Default number of rows The estimate for the number of rows has been improved. For example, in version 8.0.6, the number of rows returned the total number of trackers. This is now fixed. Note that with complex 3D layouts, this estimation could still be not fully representative of your system. This is why it is possible to override the number of rows manually. Reading PVsyst 7 or earlier simulation results Variants stemming from PVsyst 7 or earlier did not store the number of rows parameter. When reading the results in PVsyst 8.0.7, for variants where the number of rows cannot be determined retroactively, the report will show an “NA” note for the number of rows. If a new simulation is run, the number of rows will be set to the new default value. New warning A warning will be displayed when the user sets a non-default value for the number of rows in the backside geometry model. The PVsyst estimation for the number of rows is based on the 3D scene layout when available. With complex 3D layouts, this estimation could be not fully representative of your system. In such a case, this warning can be ignored. For the rare cases, where a variant with an unlimited orientation contained a user choice for the number of rows in the bifacial model, this warning will also appear if the variant contains simulation results, to make sure that the report and results correctly reflect the settings that have been used for the simulation. Since this option is not available anymore in V8.0.7, it is not possible to change the number of rows in the bifacial window. However, when running the simulation again with V8.0.7 the number of rows will toggle back to the default value, which is the number of rows defined in 'Orientation'. EW axis and NS-frame trackers When the azimuth of the axis was not zero, shadings were not properly calculated. This meant that the “Near shading losses” were not reliable. This has been corrected. Grid limitation and trackers In versions 8.0.0 to 8.0.6, a bug when combining grid limitation and the tracking algorithms “irradiance optimization”, “wind stow” or "seasonal tilt" prevented these algorithms from being properly applied. This has now been fixed. This may increase transposition gains in your variants, as irradiance optimization now corrects the tracker motion to maximize irradiance properly.

No, sorry, that is not possible. This would invalidate all hourly results.

Okay ! Then yes I would divide them by the related maximum power. DC cabling loss -> DC capacity AC cabling loss up to transformer -> AC capacity AC cabling loss transformer to POI -> transformer capacity

The thin objects shadings does not work in 8.0.6. Sorry for the inconvenience, we noticed this only recently. This should be patched for version 8.0.7.

But your power systems study is for an STC operation ? Or for realistic conditions.. If it's the latter, these kW losses will be underestimated if you compare them to the capacities.

One quantity that is easier to export for the resistance losses specifically is the resistance. If you have this value you can transfer it to PVsyst easily.

Hi, For ohmic resistance losses, it is difficult to convert the report total losses to a % at STC. Indeed, at STC the current is higher, and therefore the losses should be higher as well. This dependence on the external conditions is also marginally present for other losses as well. When you say that the losses are given in kW... do you mean the PVsyst report or the power systems study ?

You seem to have defined only one iteration step ? As a consequence, you cannot have any trends. You need to increase the number of "steps" to evaluate the simulation over a scatter of parameter space points.

Yes that's it !

The average tilt angle is quite different. this means that the trackers are arranged differently ? If so the tracking motion will also be different. If the plane orientation changes, then transposition gains will also change.

Hi, can you share the pages with "General parameters" ? To be able to say for sure we would need to know the typology of your array of trackers / tables. I suspect you have the irradiance optimization on ? If so, the change may be due to the shading evaluation being overall more precise. If you would like for us to check in more details you can also send your project over at support@pvsyst.com

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.