Skip to content

Expression for calculating wind speed at different heights #2118

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

Closed
IoannisSifnaios opened this issue Jul 5, 2024 · 19 comments · Fixed by #2124
Closed

Expression for calculating wind speed at different heights #2118

IoannisSifnaios opened this issue Jul 5, 2024 · 19 comments · Fixed by #2124
Labels
enhancement GSoC Contributions related to Google Summer of Code.
Milestone

Comments

@IoannisSifnaios
Copy link
Contributor

IoannisSifnaios commented Jul 5, 2024

Most times, the wind speed provided in weather files is measured at a height of 10 m. However, in many cases it is required to estimate the wind speed at panel height. Which equation should be used in order to do this?

I found this issue (#1814), which mentions an equation from a Sandia report (I couldn't find the report, though... some help from Sandia people? @cwhanse @kandersolar). This is what is mentioned:
Estimate wind speed at module height - use technique developed by menicucci and hall (sand84-2530) */
windmd=ws2*pow(height/9.144,0.2) + 0.0001

And then there is the expression used in wind engineering, described here (for a more official reference, it is also mentioned in the book by Siegfried Heier (2014), Grid Integration of Wind Energy Conversion Systems (publisher: Wiley))

I am willing to take up the task of making the PR, etc., but first, I would like to know your thoughts on which expression should be added (maybe both?) or if there is some other equation you think is more relevant.

@kandersolar
Copy link
Member

Here is a public copy of SAND 84-2530: https://web.archive.org/web/20230418202422/https://www2.jpl.nasa.gov/adv_tech/photovol/2016CTR/SNL%20-%20Est%20Wind%20Speed%20vs%20Height_1985.pdf

@cwhanse
Copy link
Member

cwhanse commented Jul 5, 2024

A word of caution here: some temperature model coefficients (e.g. those for the SAPM) implicitly account for the difference between anemometer and PV module height above ground. They do so by regressing measured module temperature to wind speed at 10m.

The proposed function is worth adding but I would be cautious about suggesting it needs to be in a PV modeling pipeline.

@AdamRJensen
Copy link
Member

A word of caution here: some temperature model coefficients (e.g. those for the SAPM) implicitly account for the difference between anemometer and PV module height above ground. They do so by regressing measured module temperature to wind speed at 10m.

Great insight @cwhanse. Let's add this info in a warning admonition for the proposed wind speed function.

Probably worth checking out if there is similar functionality in metpy.

@IoannisSifnaios
Copy link
Contributor Author

IoannisSifnaios commented Jul 5, 2024

Good point, @cwhanse! From a quick search, I can see that only the SAPM models and the generic_linear require the wind speed at 10 m as an input. The rest of the temperature models either require wind speed at module height or don't specify (e.g., Fuentes), but I would still imagine it requires at module height...

@kandersolar kandersolar added enhancement GSoC Contributions related to Google Summer of Code. labels Jul 5, 2024
@mikofski
Copy link
Member

mikofski commented Jul 5, 2024

I agree with @cwhanse we we need to tread cautiously because in my experience there is already a lot of misunderstanding about correlation coefficients and their relation to wind speed height measurements.

  1. I emphasize what Cliff says: correlation coefficients like Uc = 25 W/m2/K and Uv = 1.2 W/m2/K/(m/s) require and depend on wind speed measured at 10-m. So if wind speeds were measured at array height, eg 2-m, a function such as the one proposed could be helpful in estimating wind speed at 10-m
  2. Ideally I would prefer to see a discussion added to the documentation explaining why free stream velocity measurements are preferred and used in temperature correlations, before adding new functions
  3. I have most frequently seen a power law but there is often debate over what exponent to use. Eg: Uw(10m) = Uw(2m)*(10m/2m)^n where n is the exponent. Other methods may be more accurate but I’m not familiar with them. I also don’t have a reference for this or know the history why it’s so prevalent

@adriesse
Copy link
Member

adriesse commented Jul 5, 2024

This is my view on the subject:

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.

@mikofski
Copy link
Member

mikofski commented Jul 6, 2024

Thanks Anton! Can we get those references?

@adriesse
Copy link
Member

adriesse commented Jul 6, 2024

Here is a link to my temperature model equivalence paper that contains the above excerpt:
https://www.osti.gov/biblio/2003640

@mikofski
Copy link
Member

mikofski commented Jul 6, 2024

Thanks Anton. So I think there is a case for pvlib to include an expression to account for wind speed height measurement, but IMO. I still think the documentation takes precedence so that folks don’t misuse it. In particular I’d like to see a table of weather resources that shows the wind speed height. Eg ground campaigns most often measure at about 3-m while satellite is usually at 10-m. Also a corresponding table of temperature models. Finally some gallery examples that show when and how an adjustment should be made. My personal preference is to adjust the wind coefficient rather than the wind speed measurements which is associative (ie: Uv’ * Uw = Uv * adj * Uw = Uv * Uw’ in which prime indicates adjustment. Also a discussion of uncertainty would be useful.

@adriesse
Copy link
Member

adriesse commented Jul 8, 2024

I think this is another area where the PV modellers are just muddling along. Someone needs to access a large amount of data and do some thorough analysis in order to develop some well-founded correlations that are useful for PV systems!

@adriesse
Copy link
Member

Do we need consensus here before the related PR is merged?

@cwhanse
Copy link
Member

cwhanse commented Jul 24, 2024

What concerns are outstanding? I'm going back through the comments and it would help to summarize.

@adriesse
Copy link
Member

adriesse commented Jul 26, 2024

Let's go back to the beginning:

Most times, the wind speed provided in weather files is measured at a height of 10 m. However, in many cases it is required to estimate the wind speed at panel height. Which equation should be used in order to do this?

Two assertions and a question.

The answer to the question is: Not the power law (or any other model developed for higher heights). Especially not if there we're talking about the height of an actual row or field of panels at that location rather than the panel height in an empty field.

The second assertion invites the question: Does it really happen often, that wind speed at panel height is needed? For me, this is not the case, but perhaps for others it is.

@kandersolar
Copy link
Member

Maybe (probably?) the simple power law is poorly suited to translating wind speeds in PV modeling contexts, but I don't think there is any doubt that it nevertheless sees wide use in that application. I just noticed it in IEC 61724-2:2016 Appendix A, for example.

My two cents: widespread usage is sufficient motivation for inclusion in pvlib, despite theoretical concerns with the model.

@adriesse
Copy link
Member

adriesse commented Aug 1, 2024

Maybe (probably?) the simple power law is poorly suited to translating wind speeds in PV modeling contexts, but I don't think there is any doubt that it nevertheless sees wide use in that application.

I have some doubts about the widespread use just like I have doubts about the frequency of the need.

I just noticed it in IEC 61724-2:2016 Appendix A, for example.

This is an informative appendix rather than normative, and it is particularly carefully worded to avoid any recommendation.

My two cents: widespread usage is sufficient motivation for inclusion in pvlib, despite theoretical concerns with the model.

This is a good example to motivate debate about more general policies for inclusion in pvlib. I would argue that widespread usage is never enough by itself, and it should not trump scientific concerns.

@kandersolar
Copy link
Member

I see plenty of use of it here: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C32&q=%22photovoltaic%22+%22power+law%22+temperature+height+10+meter+-hub&btnG=

Frequency of need: anemometers installed at solar farms are at roughly module height, not the 10 m assumed by thermal models. The NSRDB reports wind speed at 2 m, if I remember correctly.

I'll leave discussion of the last point for another day. For now, I think there are enough thumbs up here to proceed with #2124.

@adriesse
Copy link
Member

adriesse commented Aug 4, 2024

For now, I think there are enough thumbs up here to proceed with #2124.

I don't find that the foregoing discussion justifies this conclusion.

But, I have thought of one potential way to turn the inclusion of this model in pvlib into a positive thing. If this model can be coded and documented in such a way that it draws attention to and increases awareness of its limitations, shortcomings and uncertainties, and makes people think before they leap (or simulate), then it could indirectly make this world a better place.

We could furthermore consider whether including the log law at the same time could contribute even more to that goal, by forcing users to think even more about the modeling challenge. The log model has an additional parameter for surface effects, although that doesn't mean it's been validated for near-surface wind speeds either (like in a field of PV modules).

And just maybe some big data hoarder will stumble on these functions here and think: hey, I can (in)validate this!

@wholmgren
Copy link
Member

Great ideas @adriesse. Happy to work with you on follow up PRs to add the log law and improve the documentation. I don't like the fact that billions of dollars of PV have been financed using resource data (or coefficients) touched by the power law. I think the reference implementation documented with shortcomings will be useful as we try to prevent future mistakes.

@kandersolar kandersolar added this to the v0.11.1 milestone Aug 5, 2024
@adriesse
Copy link
Member

adriesse commented Aug 5, 2024

@wholmgren You're on your own on the follow-up PR. My concerns weren't taken seriously on this one, so I don't expect any better next time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement GSoC Contributions related to Google Summer of Code.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants