laurahin

Bummer. It seemed like a good idea at the time.

Could you explain what "Trackers with shadings: the partition model for electrical shading losses now considers the bottom row of cells" means? Thanks.

We haven't seen large changes in the electrical loss yet in our (admittedly limited) use of v. 7.4, which includes variants with significant terrain. Is it possible that the differences as great as 3% aren't attributable to the modified shading loss algorithms per se but to automatic selection of a different diffuse shading reference tracker when rerunning in the higher version? We definitely have seen elect. loss differences that great depending on the location of the reference tracker in an array.

Say you have an array with two different module types, same racking and orientation, but different module sizes. Is the difference in backtracking behavior caused by the modules having different lengths taken into account when transposition is calculated for this array? If it wasn't for the size difference/backtracking, the modules would all face the same way. Thanks!

If the answer to this problem is to turn the error off, why have the message at all? Maybe it should be a warning and not a prohibitive error? Laura H.

I looked at this help page from PVcase more closely. It appears that we have to run PVsyst twice if we want to get the electrical effects of shading correctly. Is that true? Thanks. Modeling Terrain following trackers from PVcase in PVsyst | PVcase Help Center

Hi, We are treating our first project that uses terrain following trackers (Nextracker XTR). When creating the scene in PVcase, our CAD worker had to define articulation points where the trackers could change angle. The design calls for 27 module strings, and they’re broken into groups of 6-8 modules as needed. During import into PVsyst, the tracker sections are being read in as separate trackers. We don’t have an issue with this, but haven’t found a way to define the partitions for electrical effect calculations. In the past, we have sometimes used slightly longer trackers in the shading scene to make them fit properly. In this case, we’ve used a non-integer number of partitions per object. We thought we would do the same here, but the non-integer values would have to be less than 1 and this isn’t allowed in the partition definition. Any recommendation? I saw some relevant info on PVcase’s web page (below), but didn’t understand it. It may be that we brought the scene in incorrectly (the “Import to PVsyst steps” link is broken) and the segments comprising each tracker are still associated in some way in their example. Thanks!

It is my understanding that if you enter a number of strings that isn't divisible by the number of inverters, PVsyst will find the correct configuration by varying the number of strings per inverter. Can you confirm that this means that the clipping will be different for inverters with different numbers of strings? I am finding that E out of the inverter may not be constant (the total AC capacity) at all times when there is (excess-power based) clipping. For example E out Clipped energy Presumably 176,000 kW is the nominal inverter capacity. Or could the difference be due to inverter derate due to heat or other factors? Thanks, Laura

Well, does each of the years use different met data? Or why are you doing a 20-year simulation?

PVsyst will not calculate like that. PVsyst will simulate the following: The reason for the difference between warning in one case and error in the other is that (for the warnings only) PVsyst in the first case does only a rough evaluation using the total Pnoms, it doesn't separate the two types of inverter. This seems to be a contradiction. How can PVsyst "only do a rough evaluation" in the first case when you say that it will separate out the inverters (86 with 21 strings, 14 with 22)?

Hi, We have just switched from v. 7.3.2 to 7.4.4. We like the new feature where PVsyst reads the correct inverter PNom limitation mode for power factor implementation, since we were checking and inputting this manually. We see that when we start a new project, the correct mode is shown and neither of the "PNom mode derogation" options is selected. However, when we load an existing project, there is always one selected. While we can then toggle back and forth between the two options, there doesn't seem to be any way to ask for the option to be automatically set based on the OND specs. That is, one or the other boxes will always be selected. Question: Is there a way to reset this selection? It might not matter, but giving someone an unneeded option is always leaving room for error. Thanks, Laura

My understanding was that this was explicitly against the PVsyst users license, but since they haven't commented....

Hi, There are some new options when you import an external shading scene, such as from PVcase, and I can't find explicit documentation of them. 1) What does "best azimuth" mean in the "PV objects - Define orientation according to" setting, and how is it determined? 2) What does the "Terrain" option do? How would the tree crown "describe (maybe should be "define") the ground"? Incidentally, the plural of foot is feet. Feets is not a word in English.

This implies that users should bear in mind that the shading animation is only for educational purposes.

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