laurahin

Thanks so much for the thorough response. Just curious: Did you try the option of converting a monofacial module to bifacial with a bifaciality factor of 0? If not, we'll try it and I'll post the results.

PVsyst allows us to define individual subarrays that include, for example, different module types or different ILRs at the inverter. To what extent are the calculations performed independently for these subarrays, i.e., are the calculations independent all the way through the inverter output, as is the case with actual PV plants, or combined at some earlier point? It's difficult to say because some parameters, such as bifaciality, are shown as averages in the PVsyst report and the waterfall diagram lumps together losses over the entire array. Thanks.

I should clarify that I'm not just asking whether PVsyst will run, but whether the parameters associated with each subarray - IAM and bifaciality factors, power going into assigned inverters with corresponding ILRs, etc. -- will track through the system appropriately.

Hi, With the state of module imports to the US, we're getting crazier and crazier mixes of modules in plants we need to model. We're trying to keep the number of variants to a minimum and are wondering whether we can mix the following in the system (Actually, we know some of these already but are just being thorough so this can be a reference) - modules of different ratings, same manufacturer and series - modules from different manufacturers, but same physical size - modules from different manufacturers, different sizes - multiple racking configurations, e.g., 1P and 2P - fixed tilt and SAT racking - bifacial modules with different bifaciality factors - bifacial and monofacial modules - bifacial and monofacial modules where we trick PVsyst by editing the monofacial module PAN to make it bifacial with a bifaciality factor of 0 To what extent would the shading scene need to accurately represent these, i.e., do all of the modules with different ratings need to be located in the correct positions in the shading scene with or without shading objects? On the correct slopes? Thanks! Laura

What if we edit the PAN file of the monofacial module to indicate that it's bifacial with a bifaciality factor of 0?

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

Just a detail, but light in solar wavelengths is not reemitted by the ground. At the ground temperature, emission will only be in IR wavelengths. The light hitting the ground and going to the rear side of the module is scattered/reflected from the ground without absorption.

Just curious when version 3.3 might come out...?

Could someone explain what changes were made to the treatment of POI clipping in going from v. 7.2 to 7.3? We are running a set of simulations varying the inverter count and the POI limit and have been using v. 7.3.2. We have found instances where POI clipping is diagnosed even though the total inverter capacity is lower than the POI limit. We noticed the following version notes about changes to POI clipping in different revisions of v. 7.3 PVsyst 7.3 - 19/12/2022 - Simulation: complete revision of the grid-limitation treatment in the simulation. Patch 7.3.2 - 08/02/2023 - System, grid limitation: the sharing between inverter overload loss and EUnused energy loss (grid limitation) is now correct but they suggest that whatever problem was introduced has been resolved. Here are some examples of waterfall diagrams with and without POI limits. DC capacity is 388 MW; inverter capacity is 300 MW (ILR 1.28); POI limit, when included, is 344 MW (DC/AC 1.128). Note that both systems give the same final output, but some of the inverter clipping is shifted to POI clipping when the (meaningless) POI limit is added. For comparison, a run using v. 7.2.21 that includes the grid limit is provided last. It shows no clipping at the POI. (Final output is not the same due to a slight difference in electrical shading loss.) We have similar examples for other ILR values, input resource files, etc., and find this behavior completely counterintuitive. Thanks, Laura v. 7.3.2, no POI limit v. 7.3.2 with 344 MW grid limit v 7.2.21 with 344 MW grid limit

What's the status of this correction?

Has there been any confirmation of or resolution to this issue? Thanks.