Run Fast.farm

[robytian]

Dear all， I have compiled the Fast-FarmSLN in VS-Build using VS, and have put the program generated in the bin into reg_tests\r-test\glue-codes\fast-farm\TSinflow. Enter fast.farm_x64.exe TSinflow.fstf through the cmd command.The following error occurred:

Farm_Initialize:Farm_ValidateInput:OutFmt produces a column width of 10 instead of 20 characters. Farm_Initialize:For efficiency, NumPlanes has been reduced to the number of time steps (134). Farm_Initialize:T1:Farm_InitFAST:FWrap_Init:FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library ... /5MW_Baseline/ServoData/DISCON_WT1.dll could not be loaded. Check that the file exists in the specified location and that it is compiled for 64-bit applications.

I don't know if I am using Fast. Farm correctly in this way. Please help to answer, thank you.

Best regards， Tian

[robytian]

After that came the following question: @jjonkman

[robytian]

The Fast. farm program I compiled myself in VS was problematic, but the realease version I downloaded from GitHub can be used directly.

[robytian]

In vs-build->FAST-farm compiles Release_OpenMP, but generating the fast.farm_x64_omp.exe runtime in bin always tells me that I cannot locate the dynamic link library. Anybody know why? Thanks

[jjonkman]

Dear @robytian,

Can you clarify your question(s)? Are you saying that the version of FAST.Farm you compile yourself in serial mode (without OpenMP parallelization) does not work, but the precompiled Windows binary of FAST.Farm works fine? And are you saying that every time you run the precompiled Windows binary of FAST.Farm with OpenMP parallelization, you have an error regarding the loading of DLLs?

Best regards,

[robytian]

Dear @robytian,

Can you clarify your question(s)? Are you saying that the version of FAST.Farm you compile yourself in serial mode (without OpenMP parallelization) does not work, but the precompiled Windows binary of FAST.Farm works fine? And are you saying that every time you run the precompiled Windows binary of FAST.Farm with OpenMP parallelization, you have an error regarding the loading of DLLs?

Best regards,

Hi，jjonkman, Sorry I didn't express myself clearly before, I'm using openfast->vs-build->fastfarm.sln; The fastfarm.sln operation on release_x64 and release_omp of the generated program did not succeed. I downloaded the release version from GitHub directly and it run, but the OMP version indicated that I could not locate the dynamic link library.

[jjonkman]

Dear @robytian,

Regarding the issue running the precompiled binary of FAST.Farm with OpenMP parallelization, I'm guessing that you have not installed the proper Intel Fortran redistributable package or you have not set the proper environmental paths (by opening the Intel command prompt), as discussed in the NOTES section of the OpenFAST v3.0.0 release page found here: https://github.com/OpenFAST/openfast/releases.

Regarding the issue with the versions of FAST.Farm you compiled yourself, I'm not sure what the problem is. Are you getting errors when you compile?

Best regards,

[robytian]

Dear @robytian,

Regarding the issue running the precompiled binary of FAST.Farm with OpenMP parallelization, I'm guessing that you have not installed the proper Intel Fortran redistributable package or you have not set the proper environmental paths (by opening the Intel command prompt), as discussed in the NOTES section of the OpenFAST v3.0.0 release page found here: https://github.com/OpenFAST/openfast/releases.

Regarding the issue with the versions of FAST.Farm you compiled yourself, I'm not sure what the problem is. Are you getting errors when you compile?

Best regards,

Thank you for your reply, it is possible that the parallel XE 2019 I am using does not match VS2019. Best regards，

[CFDFDC]

Hi @robytian

I am also struggling with exactly the same problems in building and running FAST.Farm package: '/5MW_Baseline/ServoData/DISCON_WT1.dll could not be loaded' and can not execute FAST.Farm_x64_OMP.exe. Have you solved these problems? If yes, could you give me some clues? Thanks.

BTW I use Visual studio 2019+Intel oneAPI Base Tookit+Intel oneAPI HPC Tookit. I am not sure whether such a configuration is supported by OpenFAST.

Best wishes

[rafmudaf]

@CFDFDC did you compile FAST Farm yourself or use the precompiled binary from GitHub?

For the DISCON controller, can you verify that the file referred to in your ServoDyn input file exists? The path should be relative to your ServoDyn input file. By that I mean you can append /5MW_Baseline/ServoData/DISCON_WT1.dll to the parent directory of the ServoDyn file.

[CFDFDC]

@CFDFDC did you compile FAST Farm yourself or use the precompiled binary from GitHub?

For the DISCON controller, can you verify that the file referred to in your ServoDyn input file exists? The path should be relative to your ServoDyn input file. By that I mean you can append /5MW_Baseline/ServoData/DISCON_WT1.dll to the parent directory of the ServoDyn file.

Thanks for the quick reply.

I compiled FAST.Farm myself and then clicked the \vs-build\Dsicon\Discon.sln for building, but DISCON_WT1.dll does not appears in the reg_tests\r-test\glue-codes\fast-farm\5MW_Baseline\ServoData\ , which is assigned by the reg_tests\r-test\glue-codes\fast-farm\LESinflow\NRELOffshrBsline5MW_Onshore_ServoDyn_WT1. Please see below the setting in this file.

Best wishes

[rafmudaf]

Ah ok - you can simply copy the DISCON.dll that you did compile to reg_tests\r-test\glue-codes\fast-farm\5MW_Baseline\ServoData\ and rename is to DISCON_WT1.dll. They're actually the same controller, just different name.

[CFDFDC]

Ah ok - you can simply copy the DISCON.dll that you did compile to reg_tests\r-test\glue-codes\fast-farm\5MW_Baseline\ServoData\ and rename is to DISCON_WT1.dll. They're actually the same controller, just different name.

Thanks. But actually there is no DISCON.dll file in reg_tests\r-test\glue-codes\fast-farm\5MW_Baseline\ServoData\ after I click \vs-build\Dsicon\Discon.sln. However, I notice DISCON.dll appears in reg_tests\r-test\glue-codes\openfast\5MW_Baseline\ServoData (see below how this directory looks like). Do you mean i can just copy & rename this file to reg_tests\r-test\glue-codes\fast-farm\5MW_Baseline\ServoData\?

Currently I only manage to use FAST.Farm (with super controller). All the things I've done are: (1) downloading the openfast package from github (2) double-clicking \vs-build\FAST-farm\Fast-farm.sln (both in Release-x64 and Release_OpenMP-x64 combinations) and \vs-build\Discon\Discon.sln. Below is how my /build/bin/ looks like

The FAST.Farm_x64 works well when I copy & rename DISCON.dll as I mentioned above. But I encounter problems when executing FAST.Farm_x64_OMP as shown below

Coud you give me some suggestions?

Best wishes

[bjonkman]

1. Yes, just copy/rename the DLL for the FAST.Farm regression test.
2. The OMP version of FAST.Farm is build with dynamic libraries, so you will need to make sure the executable file can open the libraries (DLLs) it depends on. You can do this a few different ways, including
   • Running the OMP executable from the Intel compiler command prompt on the computer that you built the executable on. From the Windows start menu, find the Intel [compiler version] folder, then open the Compiler [version] for Intel 64 Visual Studio [version] environment command prompt, and run FAST.Farm from that window (you can change directories). Make sure you are using the versions you built the executable with.
   • Installing the Intel Redistributable libraries for the version of the compiler you used to build the executable. You should be able to find a link to this on Intel's web site using a search engine.

[CFDFDC]

1. Yes, just copy/rename the DLL for the FAST.Farm regression test.

2. The OMP version of FAST.Farm is build with dynamic libraries, so you will need to make sure the executable file can open the libraries (DLLs) it depends on. You can do this a few different ways, including

   • Running the OMP executable from the Intel compiler command prompt on the computer that you built the executable on. From the Windows start menu, find the Intel [compiler version] folder, then open the Compiler [version] for Intel 64 Visual Studio [version] environment command prompt, and run FAST.Farm from that window (you can change directories). Make sure you are using the versions you built the executable with.
   • Installing the Intel Redistributable libraries for the version of the compiler you used to build the executable. You should be able to find a link to this on Intel's web site using a search engine.

Thanks!

I got another questions on using SOWFA ABL simulation results to provide inflow conditions for the FAST.Farm calculation (basically I'm trying to reproduce the work in https://www.osti.gov/biblio/1416519).

1> I noticed that the LESinflow file is writen in VTK with no specific order of coordinates. I'm wondering how to make sampling files in SOWFA to obtain suitable inflow files for FAST.Farm (including high- and low-resolution domain)? I guess maybe I can use something like setsSampling with entry of point clouds but I don't even know the order of point coordinates. It would be better if you can provide the sampling template.

2> The OpenFAST module calculates the turbine forces using actuator-line concept together with BEM , but the Wake dynamics module calculates the wake flow using axisymmetric nodes (If I missunderstand, please correct me). I'm wondering if the wake flow will look more like result using line actuator-disk method or result using actuator-line method?

Best wishes

[jjonkman]

Dear @CFDFDC,

Here are my answers to your questions:

1) The VTK-based wind input to FAST.Farm follows standard simple legacy serial VTK file format, which is documented here: https://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf. More information is given in the FAST.Farm User's Guide and Theory Manual: https://openfast.readthedocs.io/en/main/source/user/fast.farm/InputFiles.html#ambient-wind-precursor-files-in-visualization-toolkit-format and https://openfast.readthedocs.io/en/main/source/user/fast.farm/ModelGuidance.html#inflow-wind-generation.

2) Yes, that is correct. The BEM output from OpenFAST may contain different loads for each node of each blade, but these are azimuth-averaged within FAST.Farm, resulting in only radially dependent loads. So, the wake in FAST.Farm will be axisymmetric and look like it was generated with a radially dependent actuator disk model. This is generally an OK assumption because it is the far wake that is of interest in FAST.Farm (for calculating the wake-impact on downstream turbines), not the near wake. Please note that we are currently working on an upgrade to FAST.Farm for optionally calculating curled wake under skewed flow, which will no longer be axisymmetric.

Best regards,

[CFDFDC]

Dear @CFDFDC,

Here are my answers to your questions:

1. The VTK-based wind input to FAST.Farm follows standard simple legacy serial VTK file format, which is documented here: https://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf. More information is given in the FAST.Farm User's Guide and Theory Manual: https://openfast.readthedocs.io/en/main/source/user/fast.farm/InputFiles.html#ambient-wind-precursor-files-in-visualization-toolkit-format and https://openfast.readthedocs.io/en/main/source/user/fast.farm/ModelGuidance.html#inflow-wind-generation.
2. Yes, that is correct. The BEM output from OpenFAST may contain different loads for each node of each blade, but these are azimuth-averaged within FAST.Farm, resulting in only radially dependent loads. So, the wake in FAST.Farm will be axisymmetric and look like it was generated with a radially dependent actuator disk model. This is generally an OK assumption because it is the far wake that is of interest in FAST.Farm (for calculating the wake-impact on downstream turbines), not the near wake. Please note that we are currently working on an upgrade to FAST.Farm for optionally calculating curled wake under skewed flow, which will no longer be axisymmetric.

Best regards,

Thanks a lot for your reply.

I am also interested in the Wake Dynamics module.

1> In the Wake-deficit Increment submodule, the user guide states the wake deficit is calculated at axisymmetric gird consisting of fixed number of wake planes. And in the Wake Advection, Deflection, and Meandering submodule, the wake planes get transported in all three directions. So I understand that, at each time step, the wake deficit is actually calculated at each axisymmetric wake plane at positions determined by the instantaneous wake plane velocity, and these wake plane may be non-parallel and staggered and behave as passive tracers carried by the ambient turbulence. Am I correct?

2> Following up 1>, Does the RANS under 'quasi-steady state' mean the deficits are time-averaged or only time-filtered as done at the rotor region?

3> The user guide states the wake-added turbulence is often modeled in DWM by scaling up the background turbulence, but I do not find where mentioned this part in the FAST.Farm modeling theory?

Best wishes,

[jjonkman]

Dear @CFDFDC,

Here are my responses:

1. Yes, that is correct. The wake evolution is solved in an axisymmetric coordinate system, but the wake planes get moved as a passive tracer due to wake meandering.

2. The equations being solves in the wake-evolution model are quasi-steady state, meaning the wake deficit will depend only on downstream distance after first being "released" at the rotor. To ensure that transients simulations are compatible with this theory, all time-varying terms at the rotor that are inputs to the wake-evolution model are low-passed filtered, so, only slow changes in the wake evolution (as a result of control or gusts) are permitted.

3. Wake added turbulence is not yet included in the main or dev branches of FAST.Farm. Matthias Kretchsmer of USTUTT developed a version of FAST.Farm that includes wake-added turbulence for a two-turbine configuration that has been validated with data from the alpha ventus wind farm--see: https://wes.copernicus.org/articles/6/1247/2021/. We will soon be initiating work to add this functionality to FAST.Farm for any wind turbine configuration.

Best regards,

[CFDFDC]

Dear @CFDFDC,

Here are my responses:

1. Yes, that is correct. The wake evolution is solved in an axisymmetric coordinate system, but the wake planes get moved as a passive tracer due to wake meandering.
2. The equations being solves in the wake-evolution model are quasi-steady state, meaning the wake deficit will depend only on downstream distance after first being "released" at the rotor. To ensure that transients simulations are compatible with this theory, all time-varying terms at the rotor that are inputs to the wake-evolution model are low-passed filtered, so, only slow changes in the wake evolution (as a result of control or gusts) are permitted.
3. Wake added turbulence is not yet included in the main or dev branches of FAST.Farm. Matthias Kretchsmer of USTUTT developed a version of FAST.Farm that includes wake-added turbulence for a two-turbine configuration that has been validated with data from the alpha ventus wind farm--see: https://wes.copernicus.org/articles/6/1247/2021/. We will soon be initiating work to add this functionality to FAST.Farm for any wind turbine configuration.

Best regards,

Thanks a lot for your help!

I've downloaded the version of FAST.Farm that includes wake-added turbulence at https://wes.copernicus.org/articles/6/1247/2021/ and compiled the FAST.Farm solver. But when I try to run the single turbine under LES inflow case (in /reg_tests/r-test/glue-codes/fast-farm/LESinflow in the main branch) using this solver, I got the following error:

It seems to be caused by the lack of proper entries WkAdT, k_m1_WkAdT and k_m2_WkAdT in the LESinflow.fstf file. Could you share a template .fstf file that includes these entries and can be used for the wake-added turbulence calculation?

Best regards,

[MatthiasCK]

Dear @CFDFDC , indeed, there are a couple of parameters needed in the main file of FAST.Farm in order to set up the wake-added turbulence model. I share an example .fstf file where the parameters corresponding to the wake-added turbulence model are defined. In addition, I include an example of the InflowWind input file which is used to set up the wake-added turbulence wind field domain. Be aware, that additional turbulent wind files are needed for the wake-added turbulence domain.

I plan to publish a more detailed manual soon, which I will attach to the wake-added turbulence branch.

Best regards, Matthias

NREL5MW_FAST.Farm_WakeAddedTurbulenceExample.zip

[CFDFDC]

Dear @CFDFDC , indeed, there are a couple of parameters needed in the main file of FAST.Farm in order to set up the wake-added turbulence model. I share an example .fstf file where the parameters corresponding to the wake-added turbulence model are defined. In addition, I include an example of the InflowWind input file which is used to set up the wake-added turbulence wind field domain. Be aware, that additional turbulent wind files are needed for the wake-added turbulence domain.

I plan to publish a more detailed manual soon, which I will attach to the wake-added turbulence branch.

Best regards, Matthias

NREL5MW_FAST.Farm_WakeAddedTurbulenceExample.zip

Thanks for your reply. I ran FAST.Farm WITHOUT the wake-added turbulence branch and compared with SOWFA-ADM results. The turbulent kinetic energy countours look like:

Top and bottom are the horizontal and vertical plane, respectively. It is shown that FAST.Farm seems can predict some TKE although with much lower as SOWFA. I am wondering:

1) What module in FAST.Farm causes the generated TKE? I guess it's from the combination of velocity deficit calculation and wake-plane velocity, but I am not sure about this.

2) Can the generated TKE in FAST.Farm be called as wake-added turbulence? If so, it may be helpful for the modeling of wake-added turbulence.

Best wishes,

[jjonkman]

Dear @CFDFDC,

In the Dynamic Wake Meandering (DWM) approach, a wake generates two forms of turbulence. The first form of turbulence is from meandering of the wake deficit due to large-scale turbulent structures in the ambient turbulent inflow. The second form of turbulence is from what is called "wake-added turbulence", which is small-scale turbulence generated in regions of high shear in the wake. Only the first form of turbulence is included in the standard version of FAST.Farm released by NREL. @MatthiasCK has developed a branch of FAST.Farm that also includes "wake-added turbulence" and NREL will soon be initiating a project to add "wake-added turbulence" in the standard version of FAST.Farm. I'm guessing your results show an under prediction of TKE in the wake calculated from FAST.Farm compared to SOWFA due to the lack of "wake-added turbulence".

Best regards,

[CFDFDC]

Dear @CFDFDC,

In the Dynamic Wake Meandering (DWM) approach, a wake generates two forms of turbulence. The first form of turbulence is from meandering of the wake deficit due to large-scale turbulent structures in the ambient turbulent inflow. The second form of turbulence is from what is called "wake-added turbulence", which is small-scale turbulence generated in regions of high shear in the wake. Only the first form of turbulence is included in the standard version of FAST.Farm released by NREL. @MatthiasCK has developed a branch of FAST.Farm that also includes "wake-added turbulence" and NREL will soon be initiating a project to add "wake-added turbulence" in the standard version of FAST.Farm. I'm guessing your results show an under prediction of TKE in the wake calculated from FAST.Farm compared to SOWFA due to the lack of "wake-added turbulence".

Best regards,

Thanks for your reply. I also examine the different velocity component in velocity field from FAST.Farm. I find the turbulence generated from meandering of the wake-deficit only has the streamwise component (ie, without the wake-added turbulence module, FAST.Farm only produce streamwise TKE in the wake), although the wake-plane velocity has three velocity components. I'm wondering what causes such a behaviour.

Best wishes,

[jjonkman]

Dear @CFDFDC,

Your results are what I expect given that the wave deficit will be aligned with the streamwise direction when the rotor is aligned with the wind. The velocity of the wake planes is used to meander the wake deficit, but is not directly summed with the wake velocity deficit and ambient wind velocity to generate the disturbed wind (ambient + wake) flow field. This is because the wake plane velocity is based on the ambient wind velocity (via spatial averaging), and so, is effectively already in the summation and should not be double counted.

Best regards,

[CFDFDC]

Dear @CFDFDC,

Your results are what I expect given that the wave deficit will be aligned with the streamwise direction when the rotor is aligned with the wind. The velocity of the wake planes is used to meander the wake deficit, but is not directly summed with the wake velocity deficit and ambient wind velocity to generate the disturbed wind (ambient + wake) flow field. This is because the wake plane velocity is based on the ambient wind velocity (via spatial averaging), and so, is effectively already in the summation and should not be double counted.

Best regards,

Thanks for your reply. So you mean the generated TKE (additional to the ambient turbulence) in Fast.Farm (see above left contour) is from wake-defict + wake-plane velocity (considering the transformation from meandering frame of reference to the global inertial frame of reference)?

Best regards,

[jjonkman]

Dear @CFDFDC,

No. As I said previously, the wake-plane velocity is not included directly in the disturbed wind field, which only contributions from the ambient wind velocity and the wake deficit velocity. The wake deficit, of course, meanders and so changes locations every time step, but the meandering velocity is not included in the summation so as to not be double counted from what already exists in the ambient flow field.

Best regards,

[CFDFDC]

Dear @CFDFDC , indeed, there are a couple of parameters needed in the main file of FAST.Farm in order to set up the wake-added turbulence model. I share an example .fstf file where the parameters corresponding to the wake-added turbulence model are defined. In addition, I include an example of the InflowWind input file which is used to set up the wake-added turbulence wind field domain. Be aware, that additional turbulent wind files are needed for the wake-added turbulence domain.

I plan to publish a more detailed manual soon, which I will attach to the wake-added turbulence branch.

Best regards, Matthias

NREL5MW_FAST.Farm_WakeAddedTurbulenceExample.zip

Dear @MatthiasCK

Thank you very much for the reply.

I try to run the version of FAST.Farm with wake-added turbulence. Because I use the inflow data from SOWFA, I have to generate a Mann turbulence domian with consistent coordinates with the SOWFA inflow domain. In the .fstf file, I set the origin of Mann turbulence domain as: X0_WkAdT is the most upwind location, Y0_WkAdT is the most right location when looking downwind, and Z0_WkAdT is the lowest location. However, I got the following error

It seems to be caused by the setup of Mann turbulence domain, but I have no idea how to fix this problem. Attached is the case file. Could you give some suggestions? WAT_FF.zip

Best regards