Dear @Salur.Basbug,
As you suggest, there should not be any meandering in this case because of the lack of ambient turbulence. I’m a bit surprised by the strong dependence you are showing to C_Meander in this case.
The value of C_Meander may effect the advection speed of the wake, but in steady uniform inflow, the solution should eventually reach steady state, and presumably you are showing the results only after the start-up transient has passed and all turbines are fully waked; is that correct?
The value of C_Meander may also effect the vertical wake deflection if you have shaft tilt enabled (and thus, skewed flow); if so, visualizing the wake in vertical X-Z plane may help.
As you said, FAST.Farm is not really targeted at steady uniform inflow. (If you are interested in that, I’d recommend using FLORIS instead of FAST.Farm.) I have no experience calibrating the FAST.Farm parameters against high-fidelity modeling results for steady uniform inflow, but that is likely what would be required for an accurate solution from FAST.Farm for this case.
Best regards,
Dear Jason, thanks a lot for the quick reply.
Soon, I’ll also include ambient turbulence and (hopefully) active yaw control, therefore I’ve preferred FAST.Fast (vs FLORIS). For now, I just do some tests with steady flow, getting familiar with the code etc.
Yes, I have run all cases for 2000 s , all gen. power curves became flat. Thank you about the note regarding ShftTilt. It was -5 deg in all runs, as in the TSInflow reg_test case for NREL 5 MW (used the files there, almost unchanged). I’ll check the vertical planes, but need to regenerate vtk’s for that.
I guess, since some parameters are averaged over an area scaled with D_wake * C_meander, having a larger C_meander may decrease the impact of wake deficit (because a larger area with ambient speed = 8 m/s is included). Maybe this would have an impact on power (?). I’ll dig a bit into the theory guide & code.
Best regards,
Dear @Salur.Basbug,
Thank you for clarifying your approach; starting simple and building complexity in steps makes sense to me.
C_Meander should not impact the wave deficit evolution in the meandering frame of reference, which is dictated by the Wake Dynamics module of FAST.Farm. However, C_Meander can impact the wake advection and deflection. Based on your response, I’m guessing it is the vertical wake deflection as a result of shaft tilt that is resulting in the change in power production.
Best regards,
Dear Jason,
I checked and it looks exactly as you anticipated. I’ve attached the vertical cut planes for the above-mentioned case, where I compared C_meander = 1.0 (top image) vs 2.5 (bottom image). Significant difference in vertical wake deflection is apparent!
When I repeated these simulations without the shaft tilt (ShftTilt = 0), the wakes advect straight downstream (as one would expect), and gen. power is the same for both values of C_meander.
Thanks again for your help in figuring this out.
Best regards,
1 Like
Dear Jason,
I have attached the equation 6.34 from the theory guide, that calculates “the advection, deflection, and meandering velocity of each wake plane”. And C_meander determines the width of the function w_n_polar (defined in Eq. 6.35).
If I understand correcty, when a small C_meander (e.g. =1) was selected in my above-mentioned case, the velocity component normal to the turbine plane decreases significantly (due to the wake deficit), whereas the component parallel to the turbine plane remains unchanged (I assume). And this leads to a strong deflection. With a bigger C_meander, we include a larger zone from the fast ambient wind into account in Eq 6.34, hence the normal velocity component is less affeced and the deflection is weaker. Would you say that’s correct ?
Best regards,
1 Like
Dear @Salur.Basbug,
Yes, that sounds correct.
Best regards,
1 Like
Dear Jason,
I wish to estimate the wind shear in a super controller algorithm. Preferably I would access the “WindVelX” component at different heights, which can be given as an output from the .fstf file, from within the “sc_calcoutput” subroutine. Is this possible? Can the output fields (from the FAST.Farm file, and/or the OpenFAST turbine .fst files) be accessed directly by a super controller?
Best regards,
Dear @Viktor.Alatalo,
This is not possible without a change to the source code.
Currently, the super controller of FAST.Farm only receives inputs from individual wind turbine controllers (argument to_SC). And the wind shear is not a standard input that is passed to the individual wind turbine controller.
That said, the wind shear is often estimated within a controller based on other measurements, e.g., the bending moment on each blade. Moreover, you could modify the OpenFAST source code to pass the wind shear known within OpenFAST directly to the individual wind turbine controller, which could then be passed to the super controller (through to_SC), or you could modify the FAST.Farm source code to pass the wind shear directly to the super controller (via argument to_SCglob, which is currently null).
Best regards,
1 Like
@Jason.Jonkman ,
I’m going to use fast Farm (openfast 3.0) to simulate the wake of 5MW wind turbine under wave motion. At present, the wake of fixed wind turbine has been simulated by using DWM, but I’m not sure whether hydrodyn can work at the same time to simulate waves? Are there any published examples or help documents?
In addition, I refer to Larsen’s article on DWM, “wake meandering: A practical approach”. Finally, the surface reflection model is discussed to simulate the influence of ground reflection on the upwards motion of turbine wake.Does openfast 3.0 consider the impact of surface reflection?
Hi @YuMing_Yuan,
I’ve also read the paper you mentioned about “wake meandering: A practical approach”, and understand what you mean with “surface reflection model”.
FAST.Farm theory guide section 7 has a list of “Future Work” and that includes this item in the list: “Reflect wakes off of the ground” ; along with some other features that NREL is planning to add into FAST.Farm. Let’s see what Jason will say about the progress 
By the way, there are also publications illustrating floating wind turbine simulations, under wind & wave conditiong, conducted using FAST.Farm. You may check:
-
Numerical study on difference of wake characteristics and effects considering several floating offshore wind turbines
-
Wake meandering effects on floating wind turbines
-
Effects of induction and wake steering control on power and drivetrain responses for 10 MW floating wind turbines in a wind farm
Best regards,
2 Likes
Thanks, @Salur.Basbug, for responding to @YuMing_Yuan’s questions. I agree with your response.
As noted by the referenced papers, FAST.Farm is capable of modeling wind farms for offshore wind (both fixed and floating) applications, including hydrodynamic excitation. Moreover, a recently issued pull request into the OpenFAST github repository extends the current functionality of FAST.Farm to support consistent wave propagation across the wind farm and shared mooring arrangements: MoorDyn v2 + shared moorings + wave propagation in FAST.Farm by mattEhall · Pull Request #1086 · OpenFAST/openfast · GitHub.
NREL has not yet been funded to work on implementation of a ground effect model in FAST.Farm, but that is on our development roadmap.
Best regards,
1 Like
Hi Salur,
Thank you for sharing relevant publications, which will be of great help to my work. Thank you
Best regards,
Thank you for your reply, Jason. I am reading the relevant literature to simulate the floating wind turbine. Best regards,
Dear @Jason.Jonkman
I’m using Fast-Farm to simulate the wake of oc4 deepcwind semi at wind u = 11.4m/s, wave H = 3.79M, t = 12.1s. I modified the example “fast certification test #25: NREL 5.0 MW baseline wind turbine with oc4 deepcwind semi” to add a uniform wind field of 11.4m/s. It is found that the following two problems are unreasonable:
-
It is observed GIF that the development of wake does not change with the movement of floating wind turbine. Does this require any special setting?
-
As shown in the figure, it is found in the VTK file that the wake is generated only in the low resolution domains, while in the high resolution domains, there is only a uniform wind field, which is not affected by the wake.
There seems to be a certain connection of the above two problems. Since the program does not report an error, I am not sure what parameters should be modified to correct wake result.
Best regards,
Dear Jason,
In a super controller’s “SC_CalcOutputs” subroutine, I access the hub horizontal wind speed by sending the avrSWAP(27) signal as outputs from the turbines’ DISCON programs (through “to_SC”). I wish to use this signal in post-processing, but I can’t seem to replicate it with common outputs. For instance, I expect the avrSWAP(27) signal to match sqrt(Wind1VelX^2 + Wind1VelY^2), given that the WindVel point is located at the turbine’s hub (which it is). However, I find that these signals don’t match. Should I expect these signals to match? If not, is there any output field which gives the avrSWAP(27) signal directly?
Thank you in advance and best regards,
Viktor
Update: I made an error. The point where I measured the WindVel outputs did not coincide with the actual hub location. I had assumed the “anemometer” was located at z = hub height = 90 m, and x = y = 0 m (in the turbine’s frame of reference). However, it seems I should have assumed it is at the exact location of the hub, as using x = “OverHang” = -5.0191 m (for the baseline 5MW turbine) gives WindVel outputs which lets me replicate the avrSWAP(27) signal with only an insignificantly small error.
Best regards,
1 Like
Dear @Viktor.Alatalo,
I agree with your finding regarding where avrSWAP(27) is calculated.
Best regards,
1 Like
Hi @Jason.Jonkman ,
Before compiling FAST.Farm (in Linux environment), I tried to include the cmake flag -DCMAKE_Fortran_FLAGS_RELEASE=“-O2 -xhost” (because it is recommanded in the theory guide for memory and speed improvements)
But if I include this flag, and try to compile, I get “gfortran: error: language host not recognized”. This happened in two different machines, and the compilation worked as soon as I’ve removed this flag.
Did anyone experience the same and knows the solution ?
Does that flag change much in the speed (assuming we run with single precision and multiple CPU’s) ?
Best regards,
Hi @Salur.Basbug,
With CMake, you should generally avoid modifying the CMake_<Lang>FLAGS variables directly unless there’s no other way around it. In this case, setting the build type to Release or RelWithDebInfo will set the appropriate optimization flags
cmake .. \
-DBUILD_TYPE=RELEASE # -O3, most aggressive math optimizations but longest compile time
# or
-DBUILD_TYPE=RELWITHDEBINFO # -O2, good balance between compile time and run time optimization
-xHOST is only valid for the Intel Fortran compiler. For GNU, look up -march or -mtune. I’ve used the Intel version myself, but I have not used the GNU version. That being said, if you are running FAST Farm on the machine where its compiled, the best instruction set available should already be chosen by the compiler. And if you’re running it on a different machine, be sure it supports at least the instruction set on the machine where you’re compiling. It’s also worth mentioning that if you’re running on a cluster, you should compile with that target instruction set (ideally its something like AVX), and compiling for xHOST will limit the performance of the executable.
