Sg/floris interface - #17
Conversation
| x = x[idx] | ||
| y = y[idx] | ||
| # return interpolator for y | ||
| return interp1d(x, y, kind="linear", fill_value="extrapolate", bounds_error=False) # TODO: should fill_value be extrapolate? |
There was a problem hiding this comment.
Should fill_value be extrapolate?
| # calculate rotor area | ||
| rotor_area = np.pi * self.bem_model.rotor.R**2 | ||
|
|
||
| # loop over flow conditions -> TODO: should this be vectorized? |
There was a problem hiding this comment.
Should this be vectorized?
| pitch = np.deg2rad(self._pitch_interp(vel)) | ||
| tsr = self._tsr_interp(vel) | ||
| # solve BEM | ||
| bem_sol = self.bem_model(pitch, tsr, yaw = yaw, tilt = tilt) |
There was a problem hiding this comment.
Do we need to limit or control the number of fixed point iterations?
|
I improved my validation figures! The "Floris" lines are FLORIS used with the MITRotor interface. 
|
|
|
Just a heads up that I made a few updates to the FLORIS branch that this works off, but I've rerun both your example and some integration tests on my side and everything is still working as it should be. Regarding the failing tests: FLORIS no longer supports python version 3.9 as of FLORIS v4.6, as python 3.9 is now at end of life. |
* Attempt at vecotization in pre-process * Working through initial 2 turbine test * Working with 10x speedup for rotor, 2x slowdown for annulus * Vectorization working with Np as the first axis * Fixed some tests with float input, but needs more work * Updated example 6 to include LUT example * Time vectorized code * Fix example timing script * All tests pass, other than new dimensional tests * Vectorization complete * Clean up BEM tests
|
This PR is now done. It covers a lot of ground, including both an interface for FLORIS and ROSCO. It also adds in the LUT functionality. There are examples for all of these use cases and all existing tests run as well. |
|
Here are the outputs of the examples: Example 6In the first example, we are simply testing that MITRotor and FLORIS using MITRotor return the same values when using the same 1D control scheme. Example 7In this example, we are testing the timing and values generated by the LUT vs direct calculations. Note that the rotor-averaged and annulus-averaged have different values, but this has to do with averaging not the LUT. Example 8Finally, in this example, ROSCO was used to create a 2D control scheme by wind speed and yaw. We can see the scheme and how they compare to the scheme in the ROSCO paper, as well as the C_T, C_P, and power both at zero and non-zero yaw. |
|
Note that this does not utilize MITRotor's BEM ability to account for sheer and veer. That can be added later. |
iupfal
left a comment
iupfal
left a comment
There was a problem hiding this comment.
Great work comments here:
- Make FLORIS and ROSCO optional dependencies
- Add in test to make sure vectorized solve is the same as looped
- Note in code that BEM doesn't use sheer/veer
- ROSCO calculate misspelling
iupfal
left a comment
iupfal
left a comment
There was a problem hiding this comment.
Issues have been addressed
3 participants
You're making a pull request to a branch (probably main) of MITWindFarm. Please ensure you have done the following.
This is not ready to merge!! This is a draft of an interface for using MITRotor within FLORIS.
I have written the interface to include the following three function:
powerthrust_coefficentaxial_inductionThe new user-defined rotor operation models,
MITRotorTurbine, takes in the following optional arguments:bem_model (BEM): optional BEM model as defined in MITRotor, defaults to IEA15MW with UMM momentum modelpitch_csv (str): optional path to pitch trajectory based on wind speed, defaults to IEA15MW Figure 2 (https://docs.nrel.gov/docs/fy22osti/82134.pdf)tsr_csv (str): optional path to tsr trajectory based on wind speed, defaults to IEA15MW Figure 2 (https://docs.nrel.gov/docs/fy22osti/82134.pdf)This follows the outline laid out in this branch of FLORIS and in this example within the branch.
The default rotor is the IEA 15 MW. The control right now is just a trajectory (based on wind speed) that is interpolated based on Figure 2 here. If a user wants to use a different turbine, they also need to provide two trajectory CSV files.
I have written a small test suite to confirm that the thrust coefficient and axial induction produced by FLORIS with MITRotor is nearly the same as just MITRotor by itself. I also checked that the leading turbine's power decreases with yaw (and second turbine's power increases if first turbine is yawed).
I also tried to compare with a plot from the IEA 15MW technical report. The below is figure 3-2 on page 20.
It seems like we are in the right ballpark, although the ranges of pitch and tsr don't really fully overlap for wind speeds run (between 5m/s and 25m/s).
I also plotted the interpolators for pitch and tsr that I created just to make sure that was looking alright. Compare to figure 2:
