Save WindData onto FlorisModel and simplify post-run() calls

[misi9170]

This pull request simplifies calls to methods that extract the power after a FlorisModel has been run(). To do so, any WindData object that is passed in to FlorisModel.set() is saved onto the FlorisModel. Setting of the FlorisModel._wind_data attribute can only be achieved using set(), and a getter method is added to expose the hidden FlorisModel._wind_data.

These changes enable the following calls to be simplified considerably, and allow the output to match the "shape" of the WindData object, if one was used:

• get_turbine_powers()
• get_farm_power()
• get_farm_AEP()

A few important changes are also implemented:

• get_farm_AEP() is now simply a wrapper around a new method, get_expected_farm_power(). The get_expected_farm_power() is then clearer. We have also discussed raising an error if get_farm_AEP() is called without a WindRose data type on FlorisModel._wind_data---@paulf81, what do you think, should get_farm_AEP() raise an error if called without a WindRose?
• None of the get_...power methods call run(). To use these methods, the user must call run() first. This clarifies the paradigm, which used to differ between different methods (get_farm_AEP() would call run(), whereas get_turbine_powers() and get_farm_power() would not).
• The above means that the no_wake flag can be removed form the the get_farm_AEP() method---if the user would like a version without wakes, they will now execute run_no_wake() instead of run() prior to calling the get_...power methods.

Other notes

• Saving the WindData object onto the FlorisModel essentially supersedes Drive layout optimizations using WindData objects #822
• the cut_in_wind_speed and cut_out_wind_speed arguments to get_farm_AEP() have been removed. These were inconsistent with the paradigm that all findices on the FlorisModel will be run. This also mirrors the removal of these terms on the ParallelComputingInterface (Rename floris.simulation, floris.tools to floris.core, floris #830, although that removal is not complete). If users would like to remove certain wind conditions from AEP calculations, they will need to set() the conditions they intend to include.
• Supersedes and was motivated by Add functions to return turbine and farm power in wind rose form #844
• get_farm_AEP() now allows users to specify how many hours there are in a year (defaults to 365 * 24=8760, but some users may like to use 8766 to account for leap years)

To do

• Update UncertainFlorisModel to track these changes.
• Consider switching to warning, rather than error, if layout optimization is run without a WindData object available
• Consider raising error or warning if get_farm_AEP() is called without a WindData object available

[misi9170]

@rafmudaf , before you review fully, are you on board with the main idea of this PR?
If so, @paulf81 , perhaps you could map these changes onto UncertainFlorisModel (which would be a good way of getting to know the changes I've made here...)

Also, @ejsimley , see the FlorisModel.wind_data attribute (which is actually a getter over a hidden attribute FlorisModel._wind_data) and the FlorisModel.get_expected_farm_power() method

[ejsimley]

Thanks @misi9170. I think this is a good way to simplify getting farm power, expected power, AEP and saving/accessing the wind rose information in the floris model.

[paulf81]

hi @misi9170 , one thought is you might discard the changes to the examples because they will only make the eventual merge to refactor_examples harder, if you leave the core changes in place I can update all the relavent examples in refactor_examples

[misi9170]

hi @misi9170 , one thought is you might discard the changes to the examples because they will only make the eventual merge to refactor_examples harder, if you leave the core changes in place I can update all the relavent examples in refactor_examples

That's true... but the checks will fail and the examples on the v4 branch won't run in the meantime. Is that a problem?

[paulf81]

Maybe just delete those examples then? I think the merge will be easier, I have everything I need in the refactor branch, Paul From: misi9170 ***@***.***> Reply-To: NREL/floris ***@***.***> Date: Wednesday, March 20, 2024 at 1:00 PM To: NREL/floris ***@***.***> Cc: Paul Fleming ***@***.***>, Mention ***@***.***> Subject: Re: [NREL/floris] Save WindData onto FlorisModel and simplify post-`run()` calls (PR #849) CAUTION: This email originated from outside of NREL. Do not click links or open attachments unless you recognize the sender and know the content is safe. hi @misi9170<https://github.com/misi9170> , one thought is you might discard the changes to the examples because they will only make the eventual merge to refactor_examples harder, if you leave the core changes in place I can update all the relavent examples in refactor_examples That's true... but the checks will fail and the examples on the v4 branch won't run in the meantime. Is that a problem? — Reply to this email directly, view it on GitHub<#849 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABOVSRX6MWJF4YA5QY5OIUDYZHMD7AVCNFSM6AAAAABE6ZRCMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGM3TQMZZGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[misi9170]

Hi @paulf81, to be honest, I'd rather keep them in to keep a record of the changes necessary for the examples to run that will be tied to this PR's merge commit. Assuming this PR gets merged, when you go to merge v4 back into the refactor_examples branch at some point, you could just keep all "current" changes (i.e. the versions on the refactor_example branch) to the example files (and then make updates to the examples as necessary). I don't think that should be too much of a headache, but I'm certainly happy to help deal with the merge conflict if it's messier than I'm imagining!

[paulf81]

Hi @paulf81, to be honest, I'd rather keep them in to keep a record of the changes necessary for the examples to run that will be tied to this PR's merge commit. Assuming this PR gets merged, when you go to merge v4 back into the refactor_examples branch at some point, you could just keep all "current" changes (i.e. the versions on the refactor_example branch) to the example files (and then make updates to the examples as necessary). I don't think that should be too much of a headache, but I'm certainly happy to help deal with the merge conflict if it's messier than I'm imagining!

Ok, yeah, I get that. Let's do it that way then, thanks!

[misi9170]

For future reference, note a small new capability that tests if a warning is logged (e.g on this file)

[misi9170]

@aclerc, just wanted to tag you here so that you see this, since this change is partly in response to your feedback :)