LauraH

What resolution are the tested tracker angles, every 5 degrees? 2 degrees? .....

Thanks. I wonder how Google's AI came up with that. My interest isn't in improving production, it's in accurately modeling ATI trackers. They are tied together in groups of 2 to 20 rows (depending on model) controlled by a single motor. This layout is something that PVcase can represent, although I'm not sure how they determine the tracking angles.

If I search for "gang tracked trackers PVsyst" in Google, Google's generative AI (which I don't fully trust) provides a whole page of information about simulating these trackers in PVsyst, starting with "In PVsyst, "gang tracked trackers" refers to a type of solar tracker system where multiple trackers are mechanically linked together, moving as a single unit to follow the sun's path, essentially acting as a "gang" to optimize sun exposure on the solar panels; this design is often used to minimize mutual shading between trackers within a large array, maximizing energy production." and moving on to "How to model gang tracked trackers in PVsyst: Project setup: When creating a new project in PVsyst, specify the tracker type as "Horizontal axis" or "Tilted axis" depending on your design. Tracking settings: Within the tracker definition, select the "Gang tracking" option to activate the linked movement feature." However, I can't find any of this information on a PVsyst website/help page/etc. What's the story? It would be great if PVsyst could model these trackers, particularly with backtracking.

Hi, Normally, we model mixed module blocks by finding an equivalent block that uses just one module model. Could we accommodate a mixed block using the multiple MPPT feature? If the block only contains two module models that are identical except for bin class, say 445s and 450s, would that make a significant difference to the production on that inverter (due to differences in inverter operation, not just the module rating)? I'm wondering whether it's worth the effort to represent the block more specifically. Thanks!

I'm unclear. If you apply the TFT option to trackers that aren't terrain-following, how does that position the trackers correctly?

With respect to the original question, will PVsyst eventually be able represent tracker gaps if they're included in an imported PVC scene? We can break the trackers into one per string, but this may allow the trackers to accommodate terrain better than the would in reality.

Temperature varies with elevation, and most high-altitude regions are mountainous, which is to say that the elevation varies rapidly in space. Thus the temperature at individual locations cannot be represented accurately using an average over 1 deg x 1 deg.

It is a misconception that the pre-PSM NSRDB data came from ground stations. The 1961-1990 version contained only 7% observations; the rest of the data came from an empirical model (METSTAT) that used meteorological data as inputs. The 1991-2005 version contained only 1% observations; the rest of the data came from the METSTAT model or the "SUNY Albany" satellite model (a precurser to CPR's SolarAnywhere product). Thus only a miniscule portion of the data in the TMY2 or TMY3 products consists of observations. The situation with Meteonorm is similar. Although some people say that Meteornorm has ~8,000 ground station, in fact only meteorological variables were measured at most of those stations. There are about 1,600 stations with measurements. The rest of the data comes from a satellite model; it is used to fill gaps in the ground site spatial coverage (which tend to be large outside of Europe). You can learn all these things by reading the NSRDB users' manuals or the Meteonorm software and theory documents. But I agree that the values from PSM tend to be high.