laurahin

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.

We have compared the results of several simulations using 7.2.21 and 7.3.1/7.3.2. In all cases, the far shading loss is lower in the 7.3 versions, in one case by 30% (i.e., 1.23% goes to 0.94%). There can also be much smaller increases in the near shading loss. Is this an intentional change, and if so, what is the reasoning? Thanks! Laura Hinkelman

The degradation loss increases by the degradation rate (say, 0.4%) every year. This means that in the first year, the loss goes from 0 to 0.4% and over the second year it goes from 0.4% to 0.8%. Averaged over the entire year, the degradation is thus 0.2% the first year, 0.6% the second year, and so on. By definition, the average of a linearly increasing value from one time to the next is the value at the center of the interval, so the explanation in terms of half years gives the same result. It's just not as physically meaningful or, apparently, easy to understand.

And this is on top of the front side mismatch that has already been applied to the entire energy, so it should arguably be even lower.

I have the same question. I have a case with the following parameters, taken from the waterfall diagram: Effective radiation on collectors = 2051 Global irradiance on the rear side = 129 Bifaciality factor = 0.67 Rear side mismatch loss specified by user = 5% The "mismatch for back irradiance" on the waterfall diagram is 0.3%. Question: How is this value obtained? Assuming that this value is applied to the total energy (from front and rear sides combined), it should be the user's input value times the fraction of the energy that comes from the rear side. Since the module efficiency and the module area are the same on the front and rear side (once the shading loss, etc., are taken into account), this comes down to the effective irradiance on the rear side relative to the total (front and rear side) irradiance. I calculate this as follows: Effective rear side irradiance = rear side irradiance * bifaciality factor = 86 Total irradiance = 2137 Fraction of irradiance from rear side = 86/2137 = 4% Thus the effective rear side mismatch loss should be 5% * 0.04 = 0.2%, but the value on the waterfall chart is 0.3%. Clearly my thought process doesn't match PVsyst's approach. Could someone clarify this? Thanks, Laura

Hi, We were comparing results for single axis tracking systems and fixed tilt arrays matched by using N-S axis orientation. We find that the production can differ at the same (nominal) angles. We assume that the fixed tilt angle is well defined, so are wondering about the definition of PhiAng for SAT systems. Is it the angle in the center of the hour? average over the hour? something else? Thanks.

If you adjust the RMS so that no warning is generated even though you have multiple pitches in your scene, what value of pitch will the simulation use? I assume that PVsyst can still only use one value in its calculations.

Two more points of follow-up: 1) In the PVsyst report, a variable "EArray" is shown in the "Balances and main results" table, but "Array nominal energy" and "Array virtual energy at MPP" appear in the waterfall diagram. It would seem confusing if the report really shows array output with different PP regulation assumptions in these two locations, but maybe nobody looks that closely. 2) Going back to what DC power would be available before the inverter: I now think inverter power point tracking is irrelevant to this situation. If we shunt all of the energy to the BESS before it reaches the inverter, the battery charge controller will do the tracking. Since we aren't asked to model the BESS, we can give the client EArrMPP and let them figure it out. I think one source of confusion is that power point tracking, applied at the inverter or charge controller, interacts with components up- and downstream in the system. Comments? Thanks!

Hi, I'm simulating a system that includes one bifacial and one monofacial module type, each set at different pitches, so am running this as two variants and combining the results. I'm having difficulty deciding how to treat the AC losses. I have split the POI limit using AC capacity weighting, on the assumption that the output of the two variants will go up and down simultaneously, and the MV transformers can also easily be split because there is one for each inverter. However, I'm not sure what to do about the HV transformer. Do I need to split that, too, even though there is only one? I had originally just entered the full transformer capacities in both simulations, but the monofacial portion is only 1/6 of the total array capacity, so I get an error message "The transformer nominal power is far higher than the maximum output power of the inverter." Aside from reducing the nominal power, the only way I can think of to move forward is to increase the value of the advanced parameter "External transfo: maximum oversizing" until the error message goes away. Will one of these approaches give me the correct transformer losses? Thanks.

An example of when this is important is when we use multiple met files as part of a batch. Those met files are also not included in the export, so we have to load them all again if another person needs to work on the project. Of course, if they were included in the first place, the topic of the SIT file wouldn't even come up.... The export files definitely need work.

I agree. Having to pass along the SIT file separately from the project export is a nuisance, and frequently forgotten. It always looks like you have it, since the SIT file information IS in the export file. I also tried exporting this file, changing the extension to SIT, and putting it in the sites folder, but PVsyst doesn't find it. Now that is bizarre.