Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about application of Fuentes PV thermal model coefficients #1039

Open
kjsauer opened this issue Jul 25, 2023 · 13 comments
Open

Question about application of Fuentes PV thermal model coefficients #1039

kjsauer opened this issue Jul 25, 2023 · 13 comments

Comments

@kjsauer
Copy link

kjsauer commented Jul 25, 2023

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
Copy link
Collaborator

cpaulgilman commented Jul 26, 2023

Note to see also pvlib/pvlib-python#1814

@kandersolar
Copy link
Member

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
Copy link
Author

kjsauer commented Aug 4, 2023

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
Copy link
Collaborator

janinefreeman commented Sep 15, 2023

@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
Copy link
Author

kjsauer commented Sep 16, 2023

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
Copy link
Collaborator

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
Copy link
Author

kjsauer commented May 6, 2024

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
Copy link
Collaborator

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
Copy link
Author

kjsauer commented May 6, 2024

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.

@kjsauer
Copy link
Author

kjsauer commented May 14, 2024

Hello, I received a photograph of the poster from a colleague. How was the NSRDB 2-m wind speed data scaled to 10-m (or vice versa)? I don't believe this was explained in the poster. Also, please explain this sentence: "Additionally, these models have a built-in scaling model to scale the 10 m wind speed to the actual height of PV panels (approximately 2 m)." Is there a reference for this (e.g., SAM/PVWatts/PVsyst help menu)? Thanks.

@janinefreeman
Copy link
Collaborator

janinefreeman commented May 14, 2024

Hi! The wind data wasn't scaled, but actual data from the two different heights was used (I believe the source was MERRA). I agree the sentence you call out is a bit confusing- what they mean is that the module thermal models have empirical coefficients that were formulated assuming the wind speed is measured at a height of 10 m (true for both CEC/NOCT and Sandia thermal models). Neither the CEC/NOCT nor the Sandia model actually scale the wind speed, in my understanding. I unfortunately can't speak for the PVsyst model.

Sandia model reference: https://energy.sandia.gov/wp-content/gallery/uploads/SAND-2004_PV-Performance-Array-Model.pdf page 17, equation 11, coefficient "b"

CEC/NOCT model reference: https://www.nrel.gov/docs/fy15osti/64102.pdf page 46, eq 9.36, the constants modifying v_w in that equation

@kjsauer
Copy link
Author

kjsauer commented May 15, 2024

Thanks again Janine for that clarification. In that case, would you please confirm that, for the weather data sets used in the poster, all the other weather data variables (e.g., GHI, DHI, DNI, Tamb) stay the same at each timestamp, and the only meteo variable you're changing is Wspd (10-m vs. 2-m) (namely, that you're only swapping out the 10-m Wspd column w/ the 2-m Wspd column)? Finally, my feeling from reading the poster is that NSRDB is not going to re-conform with the World Meteorological Organization WMO standard height of 10-m. If that's the case, we might just need to use a different set of thermal parameters (namely, the wind speed coefficient, e.g., Uv in PVsyst) revised for the 2-m wind speed height, in the case when 2-m wind speed data is used (specifically, when using NSRDB weather data as input). But most definitely we wouldn't want to simply accept a ~0.2-0.3% bias in annual PV energy simulation results (!) when it's straightforward to get it back to ~0% by using a revised wind speed coefficient (thermal parameter). To summarize: 1.) Revert NSRDB data to 10-m wind speed height and keep the well-established, default (standard) thermal params as is when using that data, OR 2.) Keep the 2-m wind speed height & revise the wind speed thermal param when using that data.

@adriesse
Copy link

adriesse commented May 15, 2024

I included some discussion about wind speed height in PV Module Operating Temperature Model Equivalence and Parameter Translation, which you may find interesting. I have pasted the relevant section here:

B. Wind speed

Each model has a coefficient that multiplies wind speed. In practice, wind speed increases with height above the ground in a non-linear manner, therefore the model coefficients are valid for a specific combination of module installation height and wind speed measurement height. The Faiman model coefficients and NOCT values are typically determined using wind speed measured near module height, but the modules are not necessarily near ground level. SAPM and PVsyst coefficients are specified for use with wind speed data at the standard 10 m height, but that information is only useful if the module height corresponding to those coefficients is also clearly specified.

To accommodate a different installation or measurement height, either the wind speed data or the wind speed coefficient can be adjusted. The basis for such an adjustment is often either the log law or the power law which describe the wind speed profile as a function of height using an empirical parameter related to the surface roughness; however, these profiles are not applicable close to the ground or close to the level of the objects that contribute to the roughness. [12] For the adjustment from 10 m to 2 m, a nominal height for a ground-mounted array, some reduction ratios found in the literature are: 0.51 [7], 0.56 [13], 0.67 [14] and 0.725 [15]. This range gives an indication of the level of uncertainty associated with such adjustments.

The SAM NOCT model uses a predetermined factor of 0.51 to reduce 10 m wind speed data to ground-mounted, module-level wind speed, but unfortunately the origin of this value is undocumented. The need for adjustments with other models to or from different heights should be evaluated by the user of the models on a case by case basis taking into consideration the both the source of the empirical parameters and the source of the wind speed data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants