Dear NREL Team,
I hope this finds you well.
I am reaching out with a query regarding the use of the curl wake model in FAST.Farm simulations. Specifically, I encounter a “division by zero” error when running simulations for below-rated Vhub values using the pyFAST Python toolbox. Interestingly, the model runs for higher Vhub values, but with an extremely high spatial resolution, which significantly increases computational demand when using TurbSim.
Upon examining the Python toolbox, I noticed that the simulation parameters for the curl model are initialised with dr = D/10, which results in a relatively large value compared to dr=Cmax used in the polar wake model. This larger dr value appears to contribute to a much smaller dt_low_les compared to its counterpart in the polar model.
I am wondering if this behaviour is a known issue with the curl wake model and if there are recommended approaches to mitigate it. Additionally, is this wake model better suited for use with the Mann turbulence model due to its ability to generate high-resolution grid data?
Thank you in advance for your assistance and guidance.
Dear @Abdulbaset.Alazhare,
Can you clarify what error you are running into? I’m not sure I understand what the issue is.
I’m also a bit confused by your comments. DT_Low in the curled wake model is proportional to dr, so, the larger dr, the larger DT_Low can be.
FYI: We’ll likely change the modeling guidance for dr for the polar wake model, from c_max to be the same as the curled wake model (dr = D/10, or D/15 to be conservative with a finer resolution).
Best regards,
Dear @Jason.Jonkman,
Thank you for your reply.
The error message encountered is as follows:
pyFAST\fastfarm\TurbSimCaseCreation.py:168: RuntimeWarning: divide by zero encountered in scalar divide self.ny = np.ceil(Ydist_Low/self.dy)+1
Regarding DT_Low, it is correct that for the curl model, DT_Low is directly linked to dr. The formula for the curl model is given by dt_lr_max = dr / (2 * v_hub). This results in a significantly smaller value compared to the formula used for the polar model, which is expressed as dt_lr_max = C_meander * D / (10 * v_hub). The variation in these calculation methods leads to a smaller DT_Low value for the curl model compared to the polar model.
Subsequently, DT_Low is used to calculate ds_lr_max with the formula ds_lr_max = (dt_low_les * v_hub^2) / 15. For the curl model, this calculation yields a much smaller ds_lr_max value than for the polar model. In some cases, this value is smaller than ds _hr_max, which leads to the “division by zero” error.
Thank you for your assistance.
Kind regards.
Dear @Abdulbaset.Alazhare,
I agree with your equations for DT_Low for the polar and curled-wake models.
But for DS_Low, the equation DS_Low <= DT_Low * V_Hub^2/15 is only correct for the polar wake model; for the curled wake model, I would use DS_Low <= C_Meander * D^Wake * V_Hub/(150 m/s), which is valid for both the polar and curled wake models. See the following documentation issue on OpenFAST for more information: DEFAULT and Recommended Polar and Curled Wake Settings in FAST.Farm · Issue #1822 · OpenFAST/openfast · GitHub.
Best regards,
Dear @Jason.Jonkman
Thank you for your response.
I used the formula DS_Low <= C_Meander * D^Wake * V_Hub/(150 m/s) to calculate the grid size. However, when running FAST.Farm, I encountered the issue shown in the attached screenshot below.
I am unsure of the nature or cause of this error. Could you please provide assistance?
Additionally, I compared the .fstf files generated for the polar and curl models side by side, as illustrated in the screenshot below (polar on the left, curl on the right). It appears that the curl model employs a significantly smaller temporal step for the low-resolution domain, resulting in NX_Low being much higher for the curl model compared to the polar model—500 versus 70, respectively.
I would greatly appreciate it if you could confirm that the highlighted values in the curl .fstf file look correct (are not too fine or coarse) and assist in addressing the error I am getting when running FAST.Farm for the curl model.
Thank you.
Dear @Abdulbaset.Alazhare,
Just a few comments:
- Which version of FAST.Farm are you using? An issue that was triggering a “stack overflow” error in FAST.Farm was fixed recently in the release of FAST.Farm within OpenFAST v3.5.4: Fix for some stack overflow issues with FAST.Farm by andrew-platt · Pull Request #2452 · OpenFAST/openfast · GitHub. If you are not using this version, I suggest upgrading, which will hopefully resolve that issue.
- I’m not sure why your
DT_High values are so different between your two model set ups.
- Likewise for
dr and NumRadii, which as I said above, we now generally recommend to be the same between the polar and curled wake models (but the modeling guidance on readthedocs still needs to be updated).
- I can’t confirm your other spatial-temporal discretizations without specific knowledge of your model set up, including rotor diameter and mean wind speed. That said, I generally agree that the
DT_Low, dX_Low, and NX_Low would differ between the polar and curled wake models when you follow the modeling guidance. You could see if increasing DT_Low above the modeling guidance causes any numerical stability issues with the curled wake model; we did this recently in the following paper and it did not suffer numerical stability issues, so, the modeling guidance as stated may be more strict than necessary: Fix for some stack overflow issues with FAST.Farm by andrew-platt · Pull Request #2452 · OpenFAST/openfast · GitHub.
Best regards,
Dear @Jason.Jonkman, many thanks for your continued support and prompt response as usual.
I was using FAST.Farm v3.5.3 initially, but the “stack overflow” issue was resolved when I switched to v3.5.4. Thank you for pointing that out.
Regarding DT_High, I had previously used a small time step but have now adjusted it to 0.3, following your recommendation in an earlier post (Using Mann Model for FastFarm Simulations - #10 by Jason.Jonkman). Similarly, I initially set dr = c_max as advised by the manual. However, based on your recent comments, I will now use dr = D_rotor / 15 for both models.
For this simulation, I am working with the NREL 15 MW wind turbine, which has a rotor diameter (D) of approximately 241 m. The inflow average wind speed for the simulation is 7 m/s.
I have one additional question: Is there a way to track the downstream distance of the upstream turbine’s wake centre over time? Specifically, I’d like an alternative to relying on the variable WkAxsXT1DN at a particular N-plane and checking when its value becomes non-zero.
Dear @Abdulbaset.Alazhare,
I’m glad you now feeling more confident with your FAST.Farm set up.
But I’m not sure I understand your question about downstream distance. The wake behind a wind turbine will extend from the rotor until the last wake plane is reached, typically 15-20D.
Best regards,
Dear @Jason.Jonkman, thank you for the prompt response.
To clarify my question, I am interested in tracking the x-location of the wake center over time. My objective is to determine the time lag between conditions at the upstream turbine and their impact on the downstream turbine. In other words, I aim to understand how many seconds it takes for a change in the inflow conditions or turbine operation to influence the downstream turbine. If you have any suggestions or insights on how to approach this, I would greatly appreciate your input.
Kind regards
Dear @Abdulbaset.Alazhare,
As I said, the wake extends from the rotor until the last wake plane. You can think of this as a continuous function expressed at discrete wake planes. It sounds like what you want is the downstream (x-displacement) of given wake planes.
Without changing the source code, this data is only available through the OutAllPlanes output option of FAST.Farm, which will generate a VTK file for each plane, time step, and wind turbine. While the coordinates of these planes are expressed in the meandering frame of reference (not global coordinates), the x-component of the coordinate can be thought of as the downstream distance a given wake plane is from its corresponding rotor at the current time step. I believe this data–that is, the x-component of the ORIGIN in the VTK file for each plane, time step, and wind turbine–is the data you want.
Best regards,
