laurahin

Were all trackers always used in past versions of PVsyst? We're having a problem where the "automatic" selection gives a bad result because it chooses a tracker on the edge of the array layout. This can cause a difference of as much as 2% in the losses. We suspect the issue is that we have broken arrays with many trackers, so that the number of trackers is large and it's easy for the "central tracker" selection to be on an edge. So the new treatment may save computational time, but now we have to check the choice of "central tracker" every time we set up a project.

Were all trackers always used in past versions of PVsyst?

We typically compare results for a fixed set of projects before moving ahead with PVsyst software updates. Looking at our last few comparisons, there is a big change in the horizon losses (in %) between versions 7.2.21 and 7.3.1 and then again between versions 7.3.2 and 7.4.1: PVsyst version Project 7.2.21 7.3.1 7.3.2 7.4.1 1 1.23 0.94 0.92 1.27 2 0.26 0.22 0.22 0.28 The second change is likely due to the change in horizon treatment the was implemented in v. 7.3.3 ("Horizon (far shadings): the calculation of the horizon shading has been corrected for times the sun passes the horizon line. This may slightly change the simulation results."), however I can't find an entry for any change to the horizon calculation between 7.2.21 and 7.3.1. Could you tell us what happened in that range that would've caused the horizon losses to change? The values above suggest that the change in v. 7.3.3 just returned the algorithm to its previous form. Thanks, Laura

Quick question: According to PVsyst Help, IAM losses are computed for both the front and rear sides of bifacial modules. Q: Is the back side IAM loss reported anywhere? There is no back side IAM output variable, and it looks like the IAM loss in the waterfall plot is only for the front side. I realize that the back side IAM loss must be small compared to the total system output, but most of the light impinges on the back side from oblique angles, so it can't be zero. Thanks! Laura

According to the documentation (https://www.pvsyst.com/help/spectral-correction.htm), spectral correction is applied automatically for amorphous silicon modules and PV modules that are found in the Sandia database. Is this true? My understanding was that no spectral correction was applied unless the user enabled it. I have never seen a spectral correction value in the waterfall table except for when we turn it on for First Solar modules. Thanks!

Hi, I'm unsure what PAN file parameter(s) control the low light losses for a given module. From the documentation, it seems that Rserie is the most important, but I did some tests and found that Rshunt had a greater effect. In addition to this, the PAN file I'm working with includes efficiency values for different irradiance both at the end of the general list of parameters (variable names like RelEffic800) and in a list of OperPoints at the end of the file. (The values are the same.) I can remove either or both of these lists and the low light loss comes out the same. Are these even used? Perhaps the other parameters are based on fits to these curves, making the curves themselves redundant? Please clarify. Thanks, Laura

Hi, A second definition of the reference nominal power was recently added to PVsyst. The user can now choose between PNomPV(ac), which has been the default, and PNom(Inv). My understanding is that the reference nominal power should represent the maximum power expected to flow through the AC system, and that PNomPV is based on the array size (nominal DC power) times the inverter efficiency while PNom(Inv) is the total inverter rating. Since in most cases, PNomPV is higher than the total inverter rating, it makes sense to me that PNomPV should be selected. My question is this: How much difference do you expect this choice to make? I believe that, at a minimum, it should affect the MV transformer loss if it's defined using the "Generic values" rather than the datasheet values, but I have tried running an example and found no difference in the result. Thanks, Laura

Thanks for your reply, @dtarin I did believe that the issue was with the data sets, not PVsyst, but couldn't find documentation of the data sets beyond what you included. Thus your statement in point three concerning the resolution of the horizons is quite useful. Laura

We have compared the effect of Meteonorm and PVGIS horizons and found that the far shading loss was typically greater for the PVGIS version. In making the comparisons, we noticed that the profiles as shown in the PVsyst report "Sun Paths" diagram have different characters. Even though the number of points used to define the profiles is similar, the PVGIS profile always appears smooth whereas the Meteonorm profile is blocky. Is there any particular reason for that? I would expect the Meteonorm and PVGIS horizons to be the same, since they use the same spatial resolution (90m) and likely both rely on data from the Space Shuttle Radar Topography Mission, although I haven't been able to confirm this.

We have compared the effect of Meteonorm and PVGIS horizons and found that the far shading loss was typically greater for the PVGIS version. In making the comparisons, we noticed that the profiles as shown in the PVsyst report "Sun Paths" diagram have different characters. Even though the number of points used to define the profiles is similar, the PVGIS profile always appears smooth whereas the Meteonorm profile is blocky. Is there any particular reason for that? I would expect the Meteonorm and PVGIS horizons to be the same, since they use the same spatial resolution (90m) and likely both rely on data from the Space Shuttle Radar Topography Mission, although I haven't been able to confirm this.

To me, listing the "backtracking limit" is unnecessary and confusing, given that the actual range of motion will be smaller. I suppose it might be useful to understand your shading....

So only for the tracker ranges? Yes, I can see how use of numbers like these might not have been foreseen. Thanks! Laura

Hi, I noticed the following note in the documentation for the 7.3.3 update: Shadings: PVC files with decimals are now properly imported What does this mean? (Where are these "decimals"?) Thanks! Laura

Is this addressed in the 7.3.3 update?

Hi, Do you know of any difference between Meteonorm horizons loaded from the web using the PVsyst interface and horizons we get directly from Meteonorm with a subscription? Thanks, Laura