FAST.Farm Outside the grid Type: Usage question

[sunshine-wangzhe]

Dear all:
I am using the TSinflow example under FAST.Farm and want to achieve support for 30 wind turbines with a wake time step < 10ms, without making any other modifications. Can you give me some suggestions? My current modifications are as follows:

I don't know why this is happening，Please give me some help.

[jjonkman]

Dear @sunshine-wangzhe,

Similar FAST.Farm questions have been asked in many other OpenFAST issues before. If you are not already doing so, I would first upgrade to the newest version of FAST.Farm within OpenFAST. I would also use the python scripts available in the OpenFAST Toolbox, which will ensure that the inflow generation is compatible with your OpenFAST models and that the FAST.Farm spatial-temporal modeling guidance is followed,.

Best regards

[sunshine-wangzhe]

Dear jjonkman:
I want to run OPENFAST models in real-time. I've written a single-turbine S-Function based on the offline version, which works fine. Now I'm trying to implement multiple turbines, but I'm encountering problems with FAST_Start. Can you give me some help? Here's part of my code and the error messages. This is for my master's thesis project - I would really appreciate your assistance.

[deslaughter]

@sunshine-wangzhe , please attach the complete file so I can try compiling and debugging it. I don't think that I have enough information from your screenshot.

[sunshine-wangzhe]

Dear all:
I have already resolved the issue mentioned above. Now, after upgrading to the latest version 4.2.0, when I use the example in fast-farm\TSinflow\FAST.Farm.fstf and only make the following modifications, an out-of-bounds error occurs. Theoretically, it should not exceed the boundaries of the high-resolution wind field. Could you provide some guidance on this?

cmd/
FAST_InitializeAll:ED_Init:ED_ReadInput:ReadBladeInputs:ReadBladeFile:The ElastoDyn Blade file,
.../5MW_Baseline/NRELOffshrBsline5MW_Blade.dat, DISTRIBUTED BLADE PROPERTIES table contains the
PitchAxis column. This column is unused and will be removed in future releases

Farm_Initialize:For efficiency, NumPlanes has been reduced to the number of time steps (31).

Time: 0 of 90 seconds.

T1:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_UpdateStates:FAST_AdvanceStates:AD_UpdateS
tates:AD_CalcWind:AD_CalcWindRotor:IfW_FlowField_GetVelAcc:Grid4DField_GetVel:Outside the grid
bounds: ( -5.00, 0.00, 90.00); box bounds: ( -69.49, -80.00, 5.00) to ( 83.06,
70.00, 155.00)
T2:FARM_UpdateStates:FWrap_Increment:FAST_Solution:FAST_UpdateStates:FAST_AdvanceStates:AD_UpdateS
tates:AD_CalcWind:AD_CalcWindRotor:IfW_FlowField_GetVelAcc:Grid4DField_GetVel:Outside the grid
bounds: ( -5.00, 0.00, 90.00); box bounds: ( -81.37, -80.00, 5.00) to ( 71.18,
70.00, 155.00)

Aborting FAST.Farm.

[jjonkman]

Dear @sunshine-wangzhe,

DT_High must be an integer divisor of DT_Low. While that is the case in your set-up (3/0.01 = 300), I'm guessing there is some floating point round-off error occurring now that you've increased the divisor from 30 to 300. Perhaps @deslaughter or @andrew-platt can comment further.

Note, however, that the TimeStep in the TurbSim data this FAST.Farm case uses equals 0.1 s, so, while this shouldn't trigger an error, there is really no need to reduce DT_High lower than that.

FYI: With Mod_SharedMooring = TRUE, DT_Mooring will not be used in this case.

Best regards,

[sunshine-wangzhe]

Dear jjonkman
I set Mod_SharedMooring to 0.01 because if left unmodified, the system would prompt that its value cannot be higher than DT_High. However, I'm confused as to why DT_High works when set to 0.02 but causes issues when set to 0.01. Thank you very much for your response. @deslaughter and @andrew-platt, Could you provide some assistance?

Best regards,

[sunshine-wangzhe]

Dear deslaughter:
Please give me some help!

Best regards,

[deslaughter]

@sunshine-wangzhe I would guess that the wind input file, 90m_08mps.bts is too short for the simulation whenDT_High is set to 0.01. The wind file contains 200 seconds of data per AnalysisTime with a TimeStep of 0.1 seconds as specified in 90m_08mps.inp. If FAST.Farm assumes that the time step of that file is 0.01, as you input, then the wind file will only contain 20 seconds of data, which is much less than the simulation length. If you want to set DT_High to 0.01, then you'll need to regenerate the wind file with TurbSim, using the same time step settings as FAST.Farm.

[jjonkman]

@deslaughter -- I disagree with your response because FAST.Farm should interpolate the TurbSim data to the finer time-resolution chosen for FAST.Farm., which is why I told @sunshine-wangzhe that there is no reason to choose DT_High in FAST.Farm that is smaller than the TimeStep in TurbSim. I'm still expecting this error is triggered by floating point round-off error.

@sunshine-wangzhe -- Nevertheless, the quick workaround is to set DT_High = TimeStep = 0.1 s in this case.

Best regards

[andrew-platt]

Looking at the error message, the point requested should in theory be inside the box bounds listed in the error message (Outside the grid bounds: ( -5.00, 0.00, 90.00); box bounds: ( -69.49, -80.00, 5.00) to ( 83.06, 70.00, 155.00)). I'm rather puzzled by why this is showing as out of bounds. The only thing I can think of is that the error message is not reporting the x bounds correctly (x and time are interchangeable) and that the wind field is not periodic.

@deslaughter, the .bts format contains the dt for the file in the header information. Unless we broke something in the code there, InflowWind will use this value in the wind calculations.

There is probably a logic error in the check for DT_Mooring using a > instead of >=.

[deslaughter]

@jjonkman I ran OpenFAST in the debugger and the issue is caused by round off error, but not in the expected way. Honestly, it was luck that this worked with DT_High = 0.1. In the first call to AD_UpdateStates, the input times are [0.01, 0, -0.01] and AD_CalcWind is called for each of these times to get the velocities from the Grid4D flow field. FAST.Farm sets the start time for the grid to TimeStart = 0.0. Then, in Grid4DField_GetVel, we run this calculation to get the time index into the grid tmp = Time - G4D%TimeStart)/G4D%delta(i) which results in tmp = -1 which is used to calculate the index as int(tmp) + 1. When tmp is exactly -1, we get an invalid index of 0 because the grid's time index starts at 1. However, if tmp is not exactly -1, we get a grid index of 1 because int(-0.999999999) + 1 = 1. Since DT_High = 0.1 cannot be exactly represented, but DT_High = 0.01 can, this calculation gives an invalid index for 0.01, but not for 0.1.

Essentially it's rounding error that allowed this to work in the first place, not rounding error that caused it to fail with DT_High = 0.01. So, how do we fix this? I'd say that technically the 4D grid is invalid for times before the start time of 0, so one solution would be to modify FAST.Farm to provide a negative start time initially. The other would be to clamp the time used in Grid4DField_GetVel to be at least equal to the start time and since this negative time is really before the simulation begins it doesn't need to extremely accurate. I believe that the InflowWind Grid4D is only used with FAST.Farm, so this would be a simple change to make. @andrew-platt what do you think?

[andrew-platt]

@deslaughter, thanks for figuring this out! I agree that clamping the time at the start is a good approach. I don't think we need accuracy there at the start of the simulation.

@jjonkman, do you foresee any issues with negative flow direction in wakes at T=0 as a result of doing this?