Error while running FAST.Farm on Windows

1900360 commented 3 years ago

Description <Hi, I am trying to run fast.farm on windows. First I used the input file on the official website, but the following error occurred when CMD executed the command>

Produce

Steps to reproduce the behavior: 1. Windows 10, Compiler: Intel(R) Fortran Compiler 1900 2. Run 'FAST.Farm_x64.exe FAST.Farm--input.dat' case with cmd 3. See the error **Expected behavior** Obviously, my input conflicts with the source program, or something is wrong, but I can't figure out why.The input file is at the end 4.The cmd output is now: ``` G:\desktop\nothing for something\dwm\dwm\code\openfast\low>FAST.Farm_x64.exe FAST.Farm--input.dat ************************************************************************************************** FAST.Farm Copyright (C) 2021 National Renewable Energy Laboratory Copyright (C) 2021 Envision Energy USA LTD This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY. See the "LICENSE" file distributed with this software for details. ************************************************************************************************** FAST.Farm-v3.0.0 Compile Info: - Compiler: Intel(R) Fortran Compiler 1900 - Architecture: 64 bit - Precision: single - OpenMP: No - Date: Jun 23 2021 - Time: 21:41:28 Execution Info: - Date: 08/11/2021 - Time: 16:13:57+0800 Heading of the FAST.Farm input file: "FAST.Farm--input" Running AWAE. Running WakeDynamics. Running FASTWrapper (v1.00.00, 7-Feb-2017). Running OpenFAST. OpenFAST input file heading: FAST Certification Test #19: NREL 5.0 MW Baseline Wind Turbine with OC3 Monopile RF Configuration, for use in offshore analysis Running ElastoDyn. Nodal outputs section of ElastoDyn input file not found or improperly formatted. Running AeroDyn. AD15 Nodal Outputs: Nodal output section of AeroDyn input file not found or improperly formatted. Skipping nodal outputs. Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 1) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 1) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 3, blade 1) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 4, blade 1) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 2) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 2) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 3, blade 2) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 4, blade 2) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 3) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 3) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 3, blade 3) Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 4, blade 3) Running InflowWind. Running ServoDyn. Running ServoDyn Interface for Bladed Controllers (using Intel Visual Fortran for Windows, ). Using legacy Bladed DLL interface. Running HydroDyn. Generating incident wave kinematics and current time history. Calculating second order difference frequency wave kinematics. Calculating second order sum frequency wave kinematics. Running SubDyn. Fixed bottom case detected Performing Craig-Bampton reduction 60 DOFs -> 0 modes + 6 DOFs Using static improvement method for gravity and ext. loads Calculating Full System Modes for summary file Time: 0 of 60 seconds. The BEM solution is being turned off due to low TSR. (TSR = 0). This warning will not be repeated though the condition may persist. (See GeomPhi output channel.) T1:FARM_InitialCO:FWrap_t0:FWrap_CalcOutput:Nacelle-yaw error is undefined because the rotor-disk-averaged relative wind speed is directed vertically Aborting FAST.Farm. ``` **Additional context** [FAST.Farm--input.txt](https://github.com/OpenFAST/openfast/files/6967273/FAST.Farm--input.txt)

jjonkman commented 3 years ago

Dear @1900360,

You said that you are using one an input file from the official website, but I see that you've changed many input parameters, including the location of the wind turbine and which OpenFAST model is being used. The error is saying that the "Nacelle-yaw error is undefined because the rotor-disk-averaged relative wind speed is directed vertically". FAST.Farm cannot run if the rotor-disk-averaged relative wind speed is directed vertically. Based on the settings you've changed in your input file(s), do you know why the the wind speed is this way? Can you run FAST.Farm as is without changing the input files? If so, what input file change leads to this error?

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

Hello, I changed the data in the input file just because the official website file failed to run before. The changes include the AMBIENT WIND and WIND TURBINES. Because the OpenFAST model in the official website refers to the relative position, and I think the official website has not been updated for a long time, so the name of the file is different from the name of the existing OpenFAST Model, so I made the above changes. So I was wondering if you have a complete and up-to-date input file and how the DWM model is used? Forgive me for being a novice, because there are not many tutorials on the fast. Farm model on the Internet.

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

I am using this kind of fan model, is there any problem?

Best regards, FAST.Farm--input.txt 5MW_Land_DLL_WTurb.txt

jjonkman commented 3 years ago

Dear @1900360,

I haven't tried to review your files in detail, but I would suggest first starting with one of the existing FAST.Farm examples. There are two provided in the OpenFAST r-test--one using LES inflow and one using TurbSim-derived inflow--see: https://github.com/OpenFAST/r-test/tree/main/glue-codes/fast-farm. Do these run for you without error?

Best regards,

1900360 commented 3 years ago

I ran the two examples you mentioned, but I got the following error：

”“” The BEM solution is being turned off due to low TSR. (TSR = 0). This warning will not be repeated though the condition may persist. (See GeomPhi output channel.)

T1:FARM_InitialCO:FWrap_t0:FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:SolveOption2 c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_4Dext_CalcOutput [position=(-5, 0, 90) in wind-file coordinates]:Interp4D:Outside the grid bounds. SolveOption2:SrvD_CalcOutput:DLL_controller_call:Running with torque and pitch control of the NREL offshore 5MW baseline wind turbine from DISCON.dll as written by J. Jonkman of NREL/NWTC for use in the IEA Annex XXIII OC3 studies. FWrap_t0:FWrap_CalcOutput:Nacelle-yaw error is undefined because the rotor-disk-averaged relative wind speed is directed vertically

Aborting FAST.Farm. “”“ What should I do to prevent such a mistake

1900360 commented 3 years ago

@jjonkman @NRELAdmin

1900360 commented 3 years ago

Do you have a sample file for the 2MW fan? Forgive me for needing it so badly

jjonkman commented 3 years ago

Dear @1900360,

I would not expect you to receive this error running the sample FAST.Farm model provided by NREL, unmodified. Perhaps there is something wrong with the version of FAST.Farm you compiled yourself? Can you try running the NREL example using the precompiled version of FAST.Farm for Windows, available from here: https://github.com/OpenFAST/openfast/releases/download/v3.0.0/FAST.Farm_x64.exe?

By "2MW fan", do you mean a wind turbine rated for 2 MW? NREL does not such a model available in the public domain. The closest is probably the WindPACT 1.5-MW baseline wind turbine.

Best regards,

1900360 commented 3 years ago

I have been able to run the example, but the duration is short and it does not show the full wake evolution. What should I do? 5MW

1900360 commented 3 years ago

When Mod_AmbWind=1 in the input file of fast.farm, the program runs fine, but the above problems may occur because the high fidelity precursor simulation using VTK format generates too little ambient wind data (according to the official website), which can only run 30 steps at low resolution. The high resolution wind data output file cannot be generated. At present, I changed Mod_AmbWind in the input file of fast.farm to 2 (other parameters remain unchanged), but the following problems occurred

(base) G:\desktop\nothingforsomething\dwm\dwm\code\openfast\reg_tests\r-test\glue-codes\fast-farm\LESinflow>FAST.Farm_x64.exe FAST.Farm--input.dat

**************************************************************************************************
FAST.Farm

Copyright (C) 2021 National Renewable Energy Laboratory
Copyright (C) 2021 Envision Energy USA LTD

This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.
**************************************************************************************************

FAST.Farm-v3.0.0
Compile Info:
 - Compiler: Intel(R) Fortran Compiler 1900
 - Architecture: 64 bit
 - Precision: single
 - OpenMP: No
 - Date: Jun 23 2021
 - Time: 21:41:28
Execution Info:
 - Date: 08/24/2021
 - Time: 10:44:18+0800

 Heading of the FAST.Farm input file:
   "FAST.Farm--input"
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 (v2.00.07a-bjj, 14-Jun-2016)
   on 24-Sep-2019 at 16:18:09.

   Processed 2000 time steps of 10-Hz full-field data (period of 200 seconds).
Running WakeDynamics.
Running FASTWrapper (v1.00.00, 7-Feb-2017).
Running OpenFAST.
OpenFAST input file heading:
    FAST Certification Test #26: NREL 5.0 MW Baseline Wind Turbine (Onshore)

Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
Running AeroDyn.
AD15 Nodal Outputs: Nodal output section of AeroDyn input file not found or improperly formatted.
Skipping nodal outputs.
Running InflowWind.
Running ServoDyn.
Running ServoDyn Interface for Bladed Controllers (using Intel Visual Fortran for Windows, ).
Using legacy Bladed DLL interface.
 Time: 0 of 60 seconds.
The BEM solution is being turned off due to low TSR.  (TSR = 0). This warning will not be
repeated though the condition may persist. (See GeomPhi output channel.)

T1:FARM_InitialCO:FWrap_t0:FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:SolveOption2
c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_4Dext_CalcOutput [position=(-5, 0, 90) in
wind-file coordinates]:Interp4D:Outside the grid bounds.
SolveOption2:SrvD_CalcOutput:DLL_controller_call:Running with torque and pitch control of the
NREL offshore 5MW baseline wind turbine from DISCON.dll as written by J. Jonkman of NREL/NWTC for
use in the IEA Annex XXIII OC3 studies.
FWrap_t0:FWrap_CalcOutput:Nacelle-yaw error is undefined because the rotor-disk-averaged relative
wind speed is directed vertically

 Aborting FAST.Farm.

1900360 commented 3 years ago

(1) How can I extend the wake simulation time? (2) What should I do if I encounter the above situation? (3) If I want to use a wind turbine rated for 2 MW, how should I change the preset model？ @jjonkman @NRELAdmin

1900360 commented 3 years ago

Here's the change I made 屏幕截图 2021-08-24 103931

jjonkman commented 3 years ago

Dear @1900360,

The FAST.Farm examples are meant as just that...examples to get you started and to test functionality of the software. You'll have to set up your own model and generate your own wind data (from LES, TurbSim, etc.) to run your own simulations of your own length and purpose.

Regarding the error you are getting, I believe this is because the only thing you've changed in the LES example is Mod_AmbWind, but you have set the ambient wind settings or wind turbine locations correctly for the TurbSim data you are using (via the InflowWind module). Ambient wind from TurbSim is centered around Y = 0, and without moving the wind turbine location of the LES example from WT_Y = 1000.0 m, the wind turbine is simply outside the wind domain, which I suspect is what is causing this error. If you wish to generate your ambient wind data from TurbSim rather than LES, I suggest starting with the TurbSim inflow example (https://github.com/OpenFAST/r-test/tree/main/glue-codes/fast-farm/TSinflow), where in fact the wind turbines are centered about Y = 0.

Regarding (3), do you already have all of the properties of the 2-MW wind turbine you wish to model, or is this something you intend to design or scale from an existing wind turbine of a different size?

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

Thank you very much! I finally found the problem and solved it. At present, I want to model the existing model of VestasV80 2MW wind turbine, but I don't know where to start. At present, only the parameters such as rotation speed and diameter provided on the official website are available. Could you please give me the reference process? Because I don't know much about it.

Best regards,

jjonkman commented 3 years ago

Dear @1900360,

I'm glad FAST.Farm is now working for you.

Regarding the modeling of a 2-MW turbine, if you have limited information (which is sounds like you do), you'll likely have to scale one of the existing reference wind turbine models (such as the WindPACT 1.5-MW baseline turbine or the IEA Wind 3.4-MW reference wind turbine, apply scaling laws to get you close to the values of the parameters you do have, and then update design details (perhaps via optimization) to get closer to the turbine representation you want. If you are trying to model a specific wind turbine with specific details, the more information you have the better the turbine representation can be (obviously). I have not done this myself, so, I can't really comment on the detailed steps required. That said, @ewquon of NREL has followed such a procedure to develop OpenFAST models of various sizes by scaling and optimization steps--see the following github repository for more information: https://github.com/NREL/openfast-turbine-models/tree/master/IEA-scaled.

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

How do you verify the results generated by fast. Farm? How do you know how accurate the wake is? Is there a more accurate way to verify and compare?

Best regards,

jjonkman commented 3 years ago

Dear @1900360,

I'm not sure I fully understand your question, please refer to our published papers regarding how we've calibrated, verified, and validated FAST.Farm:

https://www.nrel.gov/docs/fy21osti/76805.pdf https://www.nrel.gov/docs/fy20osti/76760.pdf https://www.nrel.gov/docs/fy19osti/73657.pdf https://www.nrel.gov/docs/fy19osti/72893.pdf https://www.nrel.gov/docs/fy18osti/71376.pdf https://www.nrel.gov/docs/fy18osti/70533.pdf

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

Currently, when I change the grid parameters of Fast. Farm, I encounter the following problems. Is it beyond the scope of the fan or other reasons? My intention is to encrypt the number of grids so as to achieve a more refined result. Is this setting correct?

 Time: 0 of 20 seconds.

T1:FARM_InitialCO:FWrap_t0:FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:SolveOption2
c_Inp2AD_SrvD:InflowWind_CalcOutput:CalcOutput:IfW_4Dext_CalcOutput [position=(-6.7917, 17.531,
80.632) in wind-file coordinates]:Interp4D:Outside the grid bounds.
SolveOption2:SrvD_CalcOutput:DLL_controller_call:Running with torque and pitch control of the
NREL offshore 5MW baseline wind turbine from DISCON.dll as written by J. Jonkman of NREL/NWTC for
use in the IEA Annex XXIII OC3 studies.

 Aborting FAST.Farm.

Best regards,

jjonkman commented 3 years ago

Dear @1900360,

This error means that an aerodynamic analysis node for one of the wind turbines is beyond the boundaries of the high-resolution domain. The "position" listed in the error message is relative to the wind turbine origin (WT_X,WT_Y,WT_Z).

Increasing the resolution of the low- and high-resolution domains of FAST.Farm will lead to a converged result at greater computational expense. See the Modeling Guidance chapter of the FAST.Farm User's Guide and Theory Manual for guidance on how to set these discretizations: https://openfast.readthedocs.io/en/main/source/user/fast.farm/ModelGuidance.html.

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

Thank you. I finally solved the problem. Later when I changed the entry conditions, I wanted to use TurbSim to generate the BTS file as shown (WindType=3), but I had this problem: HB9_0)L0`WPQNS% 899ONMY

 Heading of the FAST.Farm input file:
   "FAST.Farm--input"
Running AWAE.
Running InflowWind.

   Reading a 101x35 grid (300 m wide, 50 m to 130 m above ground) with a characteristic wind
   speed of 6 m/s. This full-field file was generated by TurbSim (v2.00.07a-bjj, 14-Jun-2016) on
   31-Aug-2021 at 15:30:08.

forrtl: severe (157): Program Exception - access violationiod of 1800 seconds).
Image              PC                Routine            Line        Source
FAST.Farm_x64.exe  00007FF6C445BF52  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C4459F2B  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C443E7ED  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C37CC0C5  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C34AC725  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C3683521  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C366CEAE  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C34A13EE  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C5CC3B62  Unknown               Unknown  Unknown
FAST.Farm_x64.exe  00007FF6C61BF934  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFC1F167034  Unknown               Unknown  Unknown
ntdll.dll          00007FFC20042651  Unknown               Unknown  Unknown

I didn't know if it was right. I referred to TurbSim specification file for modification, but it didn't reach the expected result

Best regards,

1900360 commented 3 years ago

Dear @jjonkman,

This is my input file in Turbsim. I don't know why, but the value in the red circle cannot be read. It is displayed as N/A $InkedKCG7SDR){7CNA{V)ULG7VM3_LI$ 8X7J80G`8WVR0`9JAM@@V

Best regards,

bjonkman commented 3 years ago

When you choose the "SMOOTH" turbulence model, the inputs you circled in red are not used. Please see the TurbSim User's Guide for more information regarding which inputs are used with each different turbulence model.

jjonkman commented 3 years ago

Dear @1900360,

I'm not sure why you are getting an access violation error when using this TurbSim-generated file within FAST.Farm. It would probably help to compile FAST.Farm in debug mode and then rerun this simulation, which should provide a bit more information on why this error is generated.

Best regards,

andrew-platt commented 3 years ago

The access violation may be due to a bug in InflowWind that was updated in the dev branch. The main branch (v3.0.0) do not include this fix, so this bug could occasionally lead to overstepping the full-field wind grid in certain cases without getting caught.

Fixed here: https://github.com/OpenFAST/openfast/pull/769

HYFOAM commented 3 years ago

hello @jjonkman When I went to read WakeDynamics.f90, I did not have a good understanding of the WD_Interp (yVal, xArr, yArr) function and its variables. I hope you can help me answer it, thank you!

jjonkman commented 3 years ago

Dear @HYFOAM,

Based on a function y = f(x) specified by arrays xArr and yArr, FUNCTION WD_Interp() returns the value of x that corresponds to the value yVal, including possible interpolation.

FUNCTION WD_Interp() is used in the calculation of the wake diameter within the wake dynamics module of FAST.Farm.

Best regards,

HYFOAM commented 3 years ago

Dear @jjonkman

Thank you very much for your reply.

I want to do some wind tunnel experiments to make some corrections to DWM. Do you have any good ideas for the experiment I am going to do?

Best regards,

jjonkman commented 3 years ago

Dear @HYFOAM,

Well, the DWM model aims to capture the far-wake evolution, meandering, and wake-added turbulence of wind turbine wakes in the atmospheric boundary layer for the purposes of calculating the structural loads of waked turbines in a wind farm. So, ideally you'd model a turbulent boundary layer flow and one or more turbines in the wind tunnel experiment with measurements of the inflow, wakes, and turbine response.

Best regards,

HYFOAM commented 3 years ago

@jjonkman

Thank you very much for your answers!

Best regards,

YiqXia commented 3 years ago

Dear @jjonkman

I am using FAST.Farm from OpenFASTv3.0.0 to simulate a wind farm of three IEA 15MW wind turbines. In OpenFAST one turbine can run well, however, the following errors show in FAST.Farm

T1:FARM_InitialCO:NearWakeCorrection:Wake model is not valid in the propeller-brake region, i.e., Ct > 2.0. T2:FARM_InitialCO:NearWakeCorrection:Wake model is not valid in the propeller-brake region, i.e., Ct > 2.0. T3:FARM_InitialCO:NearWakeCorrection:Wake model is not valid in the propeller-brake region, i.e., Ct > 2.0.

Could you please let me know the possible reasons?

Best regards,

YiqXia commented 3 years ago

Dear @jjonkman

The above problem is related to the high-resolution domain and it is solved by greatly enlarging NX_High, NY_High, NZ_High.

Thanks a lot.

jjonkman commented 3 years ago

Dear @YiqXia,

This error is stating that the disk-averaged rotor thrust coefficient is greater than 2, where the near-wake correction in FAST.Farm is invalid. A rotor thrust coefficient greater than 2 is quite unexpected and it appears to happen for all three wind turbines. I would guess the wind turbines are not operating as expected based on an incorrect setting in the FAST.Farm or OpenFAST input files. I'm not sure I understand how this would be tied to the discretization of the high-resolution domains, but it is difficult for me to guess what the actual problem would be. Can you clarify? How do the wind speed, rotor speed, and blade pitch angles look for each turbine as output from OpenFAST up until the simulation failure?

Best regards,

Tommi1198 commented 2 years ago

Hey @1900360 , what program did you use to visualize the result that you shared on 24 August 2021? The simulation I mean Thank you very much

jjonkman commented 2 years ago

Dear @Tommi1198,

The visualization shown by @1900360 uses visualization data output from FAST.Farm and displayed using the ParaView software.

Best regards,

Tommi1198 commented 2 years ago

Dear @jjonkman , what tipe of extension file ParaView can open? Thanks

jjonkman commented 2 years ago

Dear @Tommi1198,

For the visualization data, FAST.Farm makes use of the simple legacy serial VTK file format discussed in the online FAST.Farm documentation: https://openfast.readthedocs.io/en/main/source/user/fast.farm/InputFiles.html#ff-ambwindvtk.

Best regards,

1codecopyer commented 1 week ago

Dear @jjonkman In FAST In the main input file. fstf of Farm, there are 3 options for the parameter Mod_AmbWind. For different choices, the OpenFAST team provided corresponding examples, namely LESinlow, TSinlow, and ModAmb3. My question can be summarized as follows: Different ModAmbWind settings require different input files. How to generate and understand these corresponding input files. Therefore, I will describe my problem in points:

Q1、When ModAmbWind=1, i.e. LESinflow example： The official provided sample input file called LESinflow example, which contains low-high resolution files, as shown in the figure for details:

Low-high resolution input files in. vtk format with naming conventions.The official document provides the following description:The low-resolution ambient wind data files must be named Amb.t.vtk and stored in a subdirectory named Low. In the file names, is an integer (without leading zeros) between 0 (at t=0) and N-1, whre N= FLOOR(TMax/ DTLow) + 1.The high-resolution ambient wind data files must be named Amb.t.vtk, where is an integer (without leading zeros) between 0 (at t=0) and DTLow/DT_High * (N-1).

The official document describes it as: When using ambient wind generated by a high-fidelity precursor simulation with Mod_AmbWind = 1, ambient wind data files for both the low- and high-resolution domains must be pre-generated.

So how are these low high resolution and. vtk format input files generated? Can we use TurbSim to generate it? Taking the Amb.t0.vtk file as an example, My personal understanding is to use TurbSim to read. inp input files and turn on the WrFMTFF=True switch，

Then use OpenFAST.exe to read the output wind file of TurbSim, and open 'WrVTK' in the VISUALIZATION section to generate a .vtk file.

In theory, it seems feasible, but the number of generated. vtk files is limited. If I add the simulation duration 'TMax', increase the DTLow/DT'High ratio, or increase the number of fans in the LESinflow example in the. fstf file, the number of high-resolution. vtk files in the HighTfolder will further increase. This means that manually running the output wind file of TurbSim through OpenFAST to generate. vtk files will NOT be practical.

Of course, the content discussed above is based on the fact that. vtk files can be generated using TurbSim. Does it mean that the. vtk input file for the LESinflow example cannot be generated in. vtk format using TurbSim if it is the actual measurement data obtained from LES experiments? If we can use the combination of TurbSim and OpenFAST to generate. vtk, what are the operation procedures and details? How to quickly create a large number of. vtk files?

Q2、Is the low-high resolution .vtk file equivalent to the AMBIENT WIND section in creating wind field flow effects? Is it just a difference in the implementation of defining grid wind fields?

The schematic diagram of the defined grid wind field is shown in the figure：

Q3、Mod_AmbWind=2 compared with 3

The official description of the difference between these two options is: When using ambient wind through multiple instances of the InflowWind module, i.e, when Mod_AmbWind = 3, only one InflowWind input file is specified. However, multiple wind data files are used, each with a different name. Specifically, the file name in the InflowWind input file in this case specifically refers only to the directory path of the wind files. The wind file root names are required to be Low for the low-resolution domain and HighT for the high-resolution domain associated with turbine nt. What is the basis for choosing 2 or 3 depending on the number of InflowWind instances? In other words, in what scenario or research purpose is 2 chosen, and in what scenario is 3 chosen?

I browsed the input file for the ModAmb3 example， In this example, the wind farm contains 4 wind turbines, each with a high-resolution.inp file and TIMESR TurbModel, as shown in the figure：

And the time series file USRTimeSeries_T1.txt is shown in the figure:

So are the 3 wind speed components of this wind speed vector real measurements? Can I customize the required time series file for the actual measurement of the wind speed 3 component measured by the LiDAR? Is there a requirement for the time resolution of time series files?

Q4、Confusion about the FAST.Farm inertial-frame coordinate system:

The input parameter PropagationDir in the InflowWind primary input file be set to 0, ±90, or 180 degrees so that the wind propagates along the ±X or ±Y axes of the FAST.Farm inertial-frame coordinate system (the exact direction should depend on the orientation of the wind turbines and farm). The above is the official description, where the parameter PropagationDir=0 means that the incoming wind in the wind field follows FAST The grid defined by Farm propagates in the positive X-axis direction, following the flow direction of the wind turbine. PropagationDec=90 means that the incoming wind in the wind field propagates along the negative Y-axis.

Is there a correlation between FAST.Farm's inertial-frame coordinate system and geographic coordinate system? I think FAST.Farm's X-axis positive half axis points to due east and Y-axis positive half axis points to due north. Is my understanding incorrect? Can PropagationDir only be set discretely, and can the interval range be set? Or use commas to separate several discrete degrees of direction for PropagationDir?

I asked a lot of questions at once, all of which were confusions that arose after reading the documentation and running the examples. I hope this has not caused any inconvenience to you or your team, and I look forward to your clarification and answers.

jjonkman commented 1 week ago

Dear @1codecopyer,

Here are my responses:

The Mod_AmbWind = 1 option in FAST.Farm is meant for specifying the ambient wind data based on a high-fidelity precursor simulation, e.g., using large-eddy simulation (LES) from SOWFA, AMR-Wind, or other LES software. If you want to use TurbSim to generate inflow for FAST.Farm, you should use Mod_AmbWind = 2 or 3 instead (with Mod_AmbWind = 3 being what we recommend).
I'm not sure I understand your question.
It is generally very difficult to define one TurbSim wind data file that has sufficient size and spatial-temporal resolution to support both the low- and high-resolution domains that meet the FAST.Farm modeling guidance. As such, we generally recommend using Mod_AmbWind= 3 in virtually all use cases. In fact, we'll likely remove the Mod_AmbWind = 2 option in a future release of FAST.Farm because we generally don't recommend anyone using it. The ModAmb_3 example does not make use of LiDAR or other measured wind input. Rather, TurbSim is first run to generate wind data file for the low-resolution domain, then the time series of wind velocity at the hub of each wind turbine in the farm is extracted from this low-resolution input, and the TurbModel = TIMESR feature of TurbSim is used to generate the wind data file for the high-resolution domain of each turbine in subsequent TurbSim simulations that is correlated with the low-resolution domain. This is the typical procedure for using the Mod_AmbWind = 3 option.
The global coordinates of OpenFAST and FAST.Farm do not follow compass directions. Rather, the positive global X axis in OpenFAST and FAST.Farm is aligned with the nominal (zero-degree) wind and wave propagation direction. When using FAST.Farm with TurbSim-based wind inflow, we generally recommend setting PropagationDir = 0 and to rotate the wind farm (i.e., the X,Y coordinates of each wind turbine) rather than PropagationDir if you want to change the wind direction.

FYI: When setting up FAST.Farm models and their inflow, we generally recommend using the python scripts available in the OpenFAST Toolbox, which follow the FAST.Farm modeling guidance: https://github.com/OpenFAST/openfast_toolbox/tree/main/openfast_toolbox/fastfarm.

Best regards,

1codecopyer commented 3 days ago

Dear @jjonkman I have carefully read the official documentation of FAST.Farm, especially the Modeling Guidance section. I'm using the official example of Mod_AmbWind=3 that you recommendedMod_AmbWind3 Official Example.

The main input file,FAST.Farm.fstf, for my FAST.Farm is provided as follows： FAST.Farm - copy.txt Some control switches have been opened for the input file, including: UseSC=True WrDisWind=True OutAllPlanes=True

Briefly summarized as the issue of wake and synthetic incoming wind, these problems have confused me, so I am seeking your advice：

Q1 ：about wake and related issues Q1-1：

There is such a description in the official document：To ensure the wake deficits are accurately captured by FAST.Farm, NumPlanes should be set so that the wake planes propagate a sufficient distance downstream, preferably until the wake deficit decays away (xdist), with typical values between 10−20 D（Rotor Diameter）。So what is the distance between the wake planes, and are the wake planes evenly distributed at equal intervals? According to the formula, my personal guess is that the wake plane is arranged at equal intervals. I wonder if this guess is correct?

There is such a description in the official document：A VTK file is written for each plane, time step and turbine. The number of planes written will increase with each DT_Low time step, until the full number of planes Num_Planes is reached. Q1-2：Why is the output quantity of vtk files about the wake plane in the vtk_ff_planes folder so small？ The number of wake planes NumPlanes remains unchanged, i.e. NumPlanes =71, and the time step DT_Low=4,The output of the wake plane is stored in a folder named vtk_ff_planes, which contains the wake plane vtk file as shown in the figure:

There is such a description in the official document: The following field are always written: x,y,z components of the wake deficit velocity (in the meandering frame), ambient, shear, and total eddy viscosity. I used the post-processing software ParaView to read the output file of the wake plane format of WT1 in . vtk format. The visualization result is shown in the figure (the figure shows the x-component of the wake deficit velocity): Q1-3：How to reflect the evolution process of the wake in the upstream and downstream wind turbines through the physical quantities written in the wake plane, namely the x-y-z components of the loss velocity in the wake plane, and the eddy viscosity? Can you recommend the NREL team to use FAST.Farm software to study the relevant literature or research suggestions on wake evolution? Or in other words, do you have any good research suggestions on how to use FAST.Farm to study the interaction between environmental turbulence intensity and the wake inside the wind turbine (to accelerate or suppress the recovery of the wake), and how to quantify the wake?

Q2: Issues About Synthetic Turbulence Ambient Inflow The official uses a synthetic turbulence ambient wind folder named TutbSim in the Mod_SmbWind=3 example, which contains low and high-resolution ambient wind data files. I carefully compared the low resolution domain wind data files. The input file for low resolution domain ambient wind data is shown in the figure:

The input file for high resolution domain ambient wind data is shown in the figure:

I have verified that the hub height input parametersHubHt of the input files for low and high-resolution wind data satisfy the equation,HubHt=Zbot+GridHeight-0.5Dgrid(zbot=1, which refers Z0_Low in FAST.Farm input primary file).

Q2-1： I don't understand: According to the power law equation of the wind profile, the calculated hub wind speed Vhub varies greatly depending on the hub height HubHt settings in the low and high-resolution input files. So, which one can correctly refer to the true wind speed at the hub position of the wind turbine? The hub height is set differently in these two files, resulting in a significant difference in height. Which one can correctly represent the height of the wheel hub?

Q2-2 How to set up synchronization of high-resolution and low resolution environmental wind data in time and space?To account for turbine downstream distance, each time series should then be offset in time based on the freestream velocity and turbine location.How to understand the sentence?How to operate so that the wind speed time series extracted from low resolution ambient wind data can take into account factors such as wind turbine position and free inflow wind speed?

Best regards

jjonkman commented 3 days ago

Dear @1codecopyer,

Here are my responses:

Q1-1 The distance between the wake planes is based on the meandering velocity normal to the wake plane and the low-resolution time step. The meander velocity will depend on the local wind speed and wake deficit, so, the distance between each wake plane will not be the same.

Q1-2 In the VTK file naming for each wake plane, the number with 9 digits refers to the time step in seconds multiplied by 100, so, 000000400 refers to t=4 s and 000000800 refers to t=8 s, and the number with 4 digits is the wake plane number, with 0000 referring to the wake plane at the rotor and 0001 referring to the next wake plane downstream.

Q1-3 I'm not sure I really understand your question, but I would suggest reviewing the theory behind the polar wake model in FAST.Farm readthedocs: https://openfast.readthedocs.io/en/main/source/user/fast.farm/FFarmTheory.html#wake-dynamics-wd-module and/or the theory behind the curled wake in: https://onlinelibrary.wiley.com/doi/full/10.1002/we.2785.

Q2-1 When using TurbSim to generate synthetic wind data for FAST.Farm, typically HubHt in TurbSim is not set to the actual hub height of the turbine, but rather, to the vertical center of the wind domain per the following OpenFAST issue: https://github.com/OpenFAST/openfast/issues/199. The actual hub-height of the NREL 5-MW baseline wind turbines used in this example is 90 m.

Q2-2 To synchronize the wind data in the high-resolution domain with the wind data in the low-resolution domain, the wind low-resolution domain data is generated in TurbSim first, then, the time history near the hub of each wind turbine is extracted from this domain and used as a prescribed time series input in TurbSim for each high-resolution domain, using the TIMESR feature of TurbSim to correlate the time series at other points in the high-resolution domain with this time series. This process is automated if you use the python scripts from the OpenFAST Toolbox that we generally recommend you use when setting up FAST.Farm models and generating their inflow: https://github.com/OpenFAST/openfast_toolbox/tree/main/openfast_toolbox/fastfarm.

FYI: The _ModAmb3 example in the r-test does not follow all of the FAST.Farm modeling guidance; the low-resolution domain, in particular, was made smaller and coarsened up for the purposes of reducing the size of the r-test repository.

Best regards,

1codecopyer commented 2 days ago

Dear @jjonkman Thanks a lot for your reply and suggestions! I downloaded openfast-tool and successfully ran the first two example Python files in the fastfarm/examples folder. I read the OpenFAST help documentation, but I still don't know how the synchronization process you mentioned is automatically implemented.Which script file should I use to achieve low and high-resolution time and space synchronization? After initial attempts, I modified the input parameters of TurbSim in Ex1_TurbSimInputSetup. py and only obtained the input file of the modified low resolution domain wind data. Even if the parameter is set to WrFMTFF=True in the modified . inp file, the output is only the . u, . v, . w wind speed component file at the hub position in the low resolution domain.

Or should we use other scripts to extract high-resolution domain data from low resolution domain wind data files?Do we need to modify and use sh files to extract high-resolution wind speed time series?

The problem of synchronizing low and high-resolution wind data has been bothering me for a long time, even after reading the OpenFAST help documentation. Can you further explain the operation process?

Best regards!

rthedin commented 2 days ago

It is hard to point to one place on the openfast_toolbox where the synchronization process is "actually implemented". As per the modeling guidance, the spatial and temporal resolution of the low-resolution turbulence boxes should ideally be an integer multiple of the high-resolution ones, ensuring the synchronization. See non-numbered equation directly before section 4.2.15.6.4.1.2 here. This synchronization is done to avoid interpolation and thus reduced effective turbulence.

Regarding an example, I recommend you follow the complete FAST.Farm example available in the examples directory. In this example, you create the low- and high-resolution boxes sequentially: https://github.com/OpenFAST/openfast_toolbox/blob/fa0d6037b7116bfe66d411658d589ebba7634722/openfast_toolbox/fastfarm/examples/Ex3_FFarmCompleteSetup.py#L145-L151. In other examples, you are responsible for ensuring the alignment.

If you run the complete example slowly, understanding each step of the way, you will be able to make sense of the alignment/synchronization of the low- and high-resolution turbulence boxes. Here are some additional details that will help you:

In the toolbox, the alignment is mostly done in the TS_high_get_time_series function. As the name implies, this function gets the time series of the point related to the turbine location from the low-res box, and writes as an input to be used on the high-res.
Temporal alignment: https://github.com/OpenFAST/openfast_toolbox/blob/fa0d6037b7116bfe66d411658d589ebba7634722/openfast_toolbox/fastfarm/FASTFarmCaseCreation.py#L1418-L1425
Spatial alignment: https://github.com/OpenFAST/openfast_toolbox/blob/fa0d6037b7116bfe66d411658d589ebba7634722/openfast_toolbox/fastfarm/FASTFarmCaseCreation.py#L1398-L1416
A lengthy comment is provided explaining what happens in situations where the turbine is not exactly at a grid point.

OpenFAST / openfast

Error while running FAST.Farm on Windows #808