Question about application of Fuentes PV thermal model coefficients

[kjsauer]

Looking at: lib_pvwatts.cpp

My gut feeling is that if PVWatts wants to apply Fuentes-derived PV thermal model coefficients, they need to translate the 10-m TMY wind speed height to the same PV module height assumed by Fuentes in deriving said coefficients.

[cpaulgilman]

Note to see also pvlib/pvlib-python#1814

[kandersolar]

Maybe worth pointing out that the newest version of PVWatts (v8, no reference doc yet AFAIK) switched from Fuentes to NOCT. https://github.com/NREL/ssc/blob/develop/ssc/cmod_pvwattsv8.cpp#L442

[kjsauer]

Here's an additional bit of information provided by André Mermoud, the primary author of PVsyst. Perhaps we need to open a GitHub Issue in the NSRDB GitHub repository if such a repo exists.

You are right, the wind velocity measured according to the WMO standards (World Meteorological Organization) specify that the measurement should be done at 10 m height.
Source: https://forum.pvsyst.com/topic/3377-height-of-wind-speed-data-used-to-derive-pvsyst-thermal-parameters/

[janinefreeman]

@kjsauer I'm curious if you've run across any results analyzing the effect that the difference between a 10-m and 2-m wind measurement height have on actual PV output. It wouldn't be terribly hard to extrapolate the wind speed externally, then feed a modified weather file into pvwatts and examine the effect on annual energy. I imagine it's quite small, but it would be useful to us to know the magnitude of the effect in order to figure out the best fix (and where it falls in the priority list).

[kjsauer]

I think it would be straightforward enough to test out different wind speed columns via custom weather data input files where each one has wind speed at a different height. For example, you could start with one that's known to be 10-m and then adjust (translate) that to a column representing 2-m height (or vice versa) using a common, PV industry-accepted equation such as the following:

Ws10 = Ws,x*(10/x)^0.25
-> Proposed coefficient for PV arrays is 0.25 [compliments of T. Townsend]
x is height of anemometer
10 is 10-m height
Ws10 is wind speed at 10-m height (m/s)
Ws,x is wind speed at anemometer height (m/s)

I suspect the impact is non-negligible and dare I say significant in the context of both PV energy simulations and capacity testing.

[janinefreeman]

There will be a poster on this at PVPMC next week! Check out Manajit, Aron, and Matt @mjprilliman 's poster. I won't spoil the results in advance but looking forward to updating this discussion based on the analysis they did.

[kjsauer]

Thanks Janine. Unfortunately, I won't be at PVPMC this year 😥, but I look forward to reviewing the poster. I'm also tagging @cwhanse as FYI, b/c I asked Cliff in a separate email if he would please raise this topic at this year's workshop. I'm very happy to see that it's getting some attention. And I'm hoping it's looked at from both an energy simulation and capacity testing perspective, as discussed above 🤞. The wind speed height used to calculate both measured and modeled PV system power capacity must be the same for an apples-to-apples comparison.

[janinefreeman]

They looked at the effects primarily from an energy simulation perspective. Wouldn't the ideal for capacity testing be to measure and input cell or module temperature directly, or is that not commonly available somewhere at an operational plant?

[kjsauer]

The most common form of capacity test (in almost all cases, for utility-scale & DG projects, from an IE/OE perspective) is ASTM E2848-13, which makes use of global plane-of-array irradiance, ambient temperature, wind speed, and ac power. Traditionally, measured wind speed is translated to 10-m via Tim Townsend's above equation for the measured regression in order to align it w/ the TMY data used in the PV energy simulation (the latter data is used for the modeled regression). The result of the measured data capacity test regression must be compared to the result of the modeled data capacity test regression (to determine pass/fail), so the two (2) regressions must be executed in an apples-to-apples way, where the data used in both cases attempts to represent, in principle, the "same" measurands.