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.