Hello Dr. Jason,
I am a new user of FAST.Farm and have run a few r-test cases available on GitHub. Now, I’m looking for published papers that use FAST.Farm to simulate wake steering in small wind farms with two or three turbines so that I can create the results and match them with the document. So far, I haven’t found any papers focusing on small wind farm wake steering with FAST.Farm, but I’ve come across several studies using SOWFA for this purpose. I’m interested in replicating the results from the paper " [Simulation comparison of wake mitigation control strategies for a two‐turbine case (wiley.com)]"(https://onlinelibrary.wiley.com/doi/epdf/10.1002/we.1810). I have a few questions:
- If I generate the test set-up given in the paper and run it in FAST.Farm, will the results of the turbine power production and DELs of the turbine components be the same as those obtained from SOWFA?
- What additional changes should be made in the FAST.Farm, so that I can get comparable results with SOWFA
- Do you have any relevant papers which I can run using FAST.Farm for 2-3 turbine cases so that it will help in my research as a benchmark case.
Regards
Ipsita Mishra
Thank You Dr. Jason for supporting me with relevant papers. I have gone through the first paper which you have mentioned in Sl.No.1. I am going through other papers too. I have certain observations and queries which I will post after I completely understanding the process adopted in each paper and how can I use it for my research.
Regards
Ipsita Mishra
Hello Dr. Jason,
I went through your first paper (https://onlinelibrary.wiley.com/doi/full/10.1002/we.2785), which includes one of the result analyses of Dr. Fleming’s paper (https://onlinelibrary.wiley.com/doi/epdf/10.1002/we.1810), which I was interested in running in FAST.Farm. The results are quite interesting to know that power outputs with yaw settings using FAST.Farm tool is different from the LES simulation with the SOWFA tool, although there is a good trend matching. I want to use the polar and curled wake model to generate the same case. My question is:
- Is only 1 inflow wind file @8m/s generated using TurbSim for only 1 seed or multiple seeds?
- A series of FAST. Farm simulations were run for all different yaw settings. So can I get the details of the yaw settings that I have to change in the servodyn input file?
- Is it ok to share the FAST.Farm input file, if it is available open-source?
This will help in moving forward as extension to this work which is my research objective.
Hi Dr. Jason,
Thank you for your prompt response and giving a clear answer.
For Q2. I meant the ‘Nacelle-Yaw control’ settings in the ServoDyn input file. Like at what time the turbine 1 starts yawing and till how many secs out of 1hour. I am attaching the image of the ‘Nacelle-Yaw control’ with highlighted points about which I was asking.
Dear @Ipsita.Mishra,
These simulations did not involve active yaw control through ServoDyn, which is unused when YawDOF = FALSE in ElastoDyn, as was the case here. Rather fixed yaw was used based on NacYaw.
Best regards,
Thank you so much. I will try running the case and share the results if I have any further issues.
Hi,
I’ve pushed the input files in the following git repository:
You’ll likely have to adapt them to the version of OpenFAST you are using,
Emmanuel
1 Like
Thank you so much. I have a quick question: Which version of OpenFAST are these files compatible with?
Hello Emmanuel,
kind attn: Dr. Jason
I tried running the case file shared with me. I also changed the OpenFAST input files as compatible to version 3.5.3. But the following error is reflected when I run the .fstf files. Maybe it is the version issue. Can you send me the FAST.FARM and OpenFAST exe file like so that it goes along with the case generated in your simulation. The error is shown below:
FAST.Farm-v3.5.3
Compile Info:
- Compiler: Intel(R) Fortran Compiler 2021
- Architecture: 64 bit
- Precision: single
- OpenMP: No
- Date: Apr 11 2024
- Time: 20:51:36
Execution Info:
- Date: 11/20/2024
- Time: 15:40:48-0600
Heading of the FAST.Farm input file:
Sample FAST.Farm - input file
Running AWAE.
Running InflowWind.
Reading a 101x35 grid (1000 m wide, 5 m to 345 m above ground) with a characteristic wind
speed of 9.243 m/s. This full-field file was generated by TurbSim on 20-Nov-2024 at 10:33:02.
forrtl: severe (170): Program Exception - stack overflowperiod of 3702.6 seconds).
Image PC Routine Line Source
FAST.Farm_x64.exe 00007FF751651507 Unknown Unknown Unknown
FAST.Farm_x64.exe 00007FF74E79C01F Unknown Unknown Unknown
FAST.Farm_x64.exe 00007FF74E78F48F Unknown Unknown Unknown
FAST.Farm_x64.exe 00007FF74E5A13F4 Unknown Unknown Unknown
FAST.Farm_x64.exe 00007FF75112882E Unknown Unknown Unknown
FAST.Farm_x64.exe 00007FF751651710 Unknown Unknown Unknown
KERNEL32.DLL 00007FFF62127374 Unknown Unknown Unknown
ntdll.dll 00007FFF6251CC91 Unknown Unknown Unknown
Thank You, Dr. Jason. The problem is fixed by upgrading to v3.5.4.
However, a new error is reflected:
T2:FARM_InitialCO:FWrap_t0:FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:SolveOption2
c_Inp2AD_SrvD:InflowWind_CalcOutput:InflowWind_GetSpatialAverage:CalculateOutput:IfW_FlowField_Get
VelAcc:Grid4DField_GetVel: Outside the grid bounds.
I checked the same issues mentioned before in this forum and tried to check the fast.farm input files as per the suggestions given.
NZ_high is 17 and the dZ_High is 10. Thus, the height of the high-resolution domain is 170 which is higher than the total turbine height in Z-direction (Zdist_High) as 158.3 m (RefHt + high_ext*Drotor/2 - zbot). I have considered zbot = 1m and high_ext = 1.1.
Then where is it outside the grid bound?
Please let me know if my understanding is correct and how can I correct this error.
I have attached the image of my .fstf and inflow wind.inp files for reference.
inflow wind file
Hi @Ipsita.Mishra,
I suspect the issue is with the InflowWind_GetSpatialAverage routine. This routine calculates the average wind speed across the rotor by sampling a set of predetermined points based on the rotor diameter. If this routine is getting the wrong value for the rotor diameter, then an out of bounds issue could occur. I will attempt to reproduce your error and find the what the issue is.
Regards,
Andy
Thank you so much for your support.
Dear @Ipsita.Mishra,
After some digging, I found the issue. There is an error in how the rotor points are calculated for the disk average average plane resulting in an incorrect rotor projection. The effect of this is that this calculation currently requires points a half rotor diameter downstream of the rotor. This causes a bounds error in the X dimension the high resolution box around Turbine 2.
For Turbine 1, your high resolution box extends from X0_High=-77.7 to 95.2 (X0_High + (NX_High-1) * dX_High). This spans more than a half rotor diameter downstream of the turbine hub.
for Turbine 2, your high resolution box extends from X0_High=709.3 to 882.2 (X0_High + (NX_High-1) * dX_High). However, with the turbine sitting at 877 m, there is only 5 m of high resolution wind box behind it. WIth the error in the calculations for the rotor average wind speed, the incorrectly projected rotor is partially behind this box.
I will submit a fix for this issue shortly. This will be included in our soon to be released v3.5.5 next week. In the meantime, you can either shift X0_High back by 40 m to 749.3 m, or increase NX_High to 22.
Regards,
