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

Add FLORIS based wind-speed estimator to FLASC #228

Merged
merged 7 commits into from
Nov 26, 2024
Merged

Conversation

paulf81
Copy link
Collaborator

@paulf81 paulf81 commented Oct 23, 2024

Add FLORIS based wind-speed estimator to FLASC

Feature or improvement description
This PR adds a wind speed estimator based on measured power, and the expected power curve in FLORIS, to estimate the wind speed. The approach is modeled on the estimator based on data in @aclerc 's wind-up, in which the estimator blends between using power in the wind-ranges where power can be mapped to wind speed (below rated and above cut-in), and blends to using wind speed outside that range. The difference is that the power curve is taken directly from FLORIS. This approach will be useful when using FLASC to model-fit FLORIS, by ensuring that wind speeds can be selected which exactly reproduce the observed power, reducing a "noise" source of error unrelated to wakes.

Impacted areas of the software
floris_tools.py

Todo:

  • Remove temporary example, included just to help review
  • Add tests

@paulf81 paulf81 added the new-feature A new feature label Oct 23, 2024
@paulf81 paulf81 requested review from misi9170 and ejsimley October 23, 2024 19:57
@paulf81 paulf81 self-assigned this Oct 23, 2024
@paulf81
Copy link
Collaborator Author

paulf81 commented Nov 18, 2024

ok @misi9170 and @ejsimley I think this is now ok to review if you have a minute

Copy link
Collaborator

@misi9170 misi9170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good @paulf81 --- I just added some requests for clarity around the ws3 value and a suggestion on requiring power to be specified in kW.

I also took the liberty of consolidating the example notebook a bit---hopefully that's ok. It'd be good for you to take a look at it and make sure you're happy with the update.

ws0 = 0
ws1 = float(np.interp(rated_power * 0.1, pow_pc, ws_pc))
ws2 = float(np.interp(rated_power * 0.9, pow_pc, ws_pc))
ws3 = ws2 + 1.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does ws3 represent, physically? The others are fairly intuitive, but I don't follow the meaning of ws3?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the wind-up version, ws3 is the wind speed at which the lower quartile of the data in the bin exceeds the max power threshold, let's say "completing" the transition into region 3

ws_est_gain_y = [0, 1, 1, -1]

ws_est_gain = np.interp(df_scada["ws_{:03d}".format(ti)], ws_est_gain_x, ws_est_gain_y)
ws_est_gain = np.clip(ws_est_gain, 0, 1)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe similar to the comment above about ws3, it seems strange to define a gain value of -1 for the ws3 entry and then clip any interpolated value back to 0? Would that be equivalent to setting ws3 closer to ws2 and then setting the last value of ws_est_gain_y to 0?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think in our case this would be equivalent

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now added some comments describing the wind speeds ws0, ws1, ws2, ws3.

This will be especially useful in model fitting to avoid any error on un-waked turbines.

Args:
df_scada (pd.DataFrame | FlascDataFrame): Pandas DataFrame with the SCADA data.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How strictly do we enforce that df_scada's power should be specified in kW? Presumably, if the power is not in kW, the approach will fail?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true, I think we only recommend it. I guess it will fail very badly at least, but we could think about adding some tests that power is in kW. Any values in excess of 20,000 would be a clue?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm trying to think whether any other procedures in FLASC assume that power is in kW. Possibly not, since we are often dividing a power by a reference power, so the units cancel out. But maybe there are other places on floris_tools.py where we make this assumption.

@paulf81
Copy link
Collaborator Author

paulf81 commented Nov 19, 2024

Overall this looks good @paulf81 --- I just added some requests for clarity around the ws3 value and a suggestion on requiring power to be specified in kW.

I also took the liberty of consolidating the example notebook a bit---hopefully that's ok. It'd be good for you to take a look at it and make sure you're happy with the update.

Your changes are good, thanks!

@misi9170 misi9170 self-requested a review November 25, 2024 21:01
@paulf81
Copy link
Collaborator Author

paulf81 commented Nov 26, 2024

Thanks @misi9170 !

@paulf81 paulf81 merged commit 214f67a into NREL:develop Nov 26, 2024
3 checks passed
@paulf81 paulf81 deleted the ws_est branch November 26, 2024 04:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-feature A new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants