Dear Dr.Jonkman,
I downloaded the source code in Bonnie’s reply and compiled it.When I simulated it using the newly generated FAST.Farm_x64_OMP.exe, the error in the picture occurred. And OpenMP is still No.
Best Regards，
Dear @Jian.Zhang,
You had e-mailed something similar previously; is that correct? The problem still seems to be driven by a high skew angle, which I’m a bit surprised by.
Regarding your new results, I also see large platform-roll motion (PtfmRDyi). Are you simulating the NREL 5-MW baseline wind turbine atop the OC4-DeepCwind semisubmersible? I wouldn’t expect this much roll motion for this FOWT.
Also, is the following correct?
WvHighCoff 1.570796→0
This would imply that the waves are fully filtered out; is that true?
I also see that the issues exists for WT1, which is presumably upstream of the other. This means you should be able to see similar issues when simulating with standalone OpenFAST, uncoupled from OpenFAST. I would debug there before switching back to FAST.Farm.
Best regards,
Dear @RuoNan.Zhu,
I’m not sure what source code you are referring to, but it does not look like you are running a version of FAST.Farm compiled with OpenMP. Regarding the error you are receiving, this looks to be caused by the use of an input file that is not compatible with the version of FAST.Farm you are running. As with any input file processing error, I would enable the Echo option to debug.
Best regards,
Dear Dr.Jason，
I have now successfully made OpenMP Yes, due to the previous failure caused by the wrong configuration selection of the platform at compile time. But the second problem remains.
Best regards，
Dear @Jason.Jonkman
For the “WvHighCoff 1.570796→0”, I consider I have a typo, and I set the “WvHighCoff 1.570796→500”.
Maybe I should give more description about my simulation cases. With the synthetic wind inflow generated by TurbSim, the codes run well whether for OC4-DeepCwind semisubmersible and OC3 Spar platforms. I should say the given examples performed well with FAST.Farm.
The error information appeared in the cases considering the wake-added turbulence (which might be caused by the blade tip or root vortex shedding) with my recompiled executable program. The case for OC3 Spar performed well, but unfortunately, the failure appeared in the OC4-DeepCwind semisubmersible case, as shown before, with the information of the high-thrust and low TSR.
I uploaded the cases into Google disk, which might be slightly large due to the big tempo-spatial wind field. If possible, could you have a quick look, as I have no idea after a long-time debug process?
https://drive.google.com/drive/folders/1vgssrUM80FZoAt_vLIWp1d8pf1pNKuiS?usp=sharing
Thank you very much
Best regards,
Dear @RuoNan.Zhu,
Again, regarding the error you are receiving, this looks to be caused by the use of an input file that is not compatible with the version of FAST.Farm you are running. As with any input file processing error, I would enable the Echo option to debug.
Best regards,
Dear @Jian.Zhang,
I don’t seem to have access to your Google drive. But it sounds like the problem may be related to the wake added turbulence branch of FAST.Farm that you are using. This branch is not supported by NREL, so, I’m not sure how to help; I would suggest reaching out to Matthias Kretschmer.
FYI: We are working at NREL to add a wake added turbulence into FAST.Farm, and have a used Matthias Kretschmer’s work as a starting point, but we are changing the implementation a bit to make it a bit easier to use.
Best regards,
Dear Dr. Jonkman,
Thank you for your reminder. I will turn to Matthias Kretschmer for help, and even so, I attached the examples in the following links.
https://drive.google.com/drive/folders/1vgssrUM80FZoAt_vLIWp1d8pf1pNKuiS?usp=share_link
The confusing aspect is that I could run the Spar and TLP case with the introduction of wake-added turbulence; however, it does not apply to the Semisubmersible one. I know you are currently busy, so maybe have a quick look if allowed. If not, ignore it—many thanks.
Best regards,
Dear everyone,
FAST.Farm uses OpenFAST, which uses the BEM theory (with advanced corrections) to compute the output data at the wind turbine level. Does this mean that FAST.Farm is an actuator disk model?
I know that SOWFA uses an actuator line model. But in this case, I’m confused because SOWFA also uses OpenFAST to compute the data at the wind turbine level, which uses the BEM theory…
Can someone please clarify this confusion please?
Kindest regards
Younes
NREL people should correct me if I’m wrong, but as I understand it:
BEM method solves the axial & tangential induction factors (a and a’) iteratively (using the turbine data tables, tip speed ratio etc), and delivers the forces applied on the turbine, but does not tell you much about the 3D flow or pressure fields away from the turbine, just the velocity profile along the blade in radial direction.
Acuator disk & line methods work within a 3D- flow solver (as far as I’ve seen). The 3D solver gets the turbine forces from ADM or ALM, include them in the navier stokes equations as body forces, and solves for the flow and pressure distribution everywhere in your domain. So there is a 2-way coupling & information exchange at every time step between the 3D flow field and turbine.
I’m not sure if we can call FAST.Farm an actuator disk model, since it does not really solve any pressure field. It assumes a velocity deficit profile in the wake of the turbine and superimposes that on the external flow field. The wake deficit advection + diffusion is handled like a passive scalar (e.g. temperature profile would be also a passive scalar). It falls in the category called “dynamic wake meandering method” as I understand.
SOWFA I never used, so leave that part 
I hope it helped.
Best regards
Dear @Younes.Oudich,
I agree with @Salur.Basbug’s comments.
I would just clarify that both FAST.Farm and SOWFA use OpenFAST, which uses the AeroDyn module to compute the local aerodynamic loads based on airfoil polar data (table look-up of lift, drag, and pitching moment based on local angle of attack), with optional inclusion of unsteady airfoil aerodynamics. But FAST.Farm relies on the AeroDyn’s module’s computation of induction using momentum theory (BEM) while SOWFA computes induction via CFD. FAST.Farm further models the far wake based on actuator disk assumptions within the context of the Dynamic Wake Meandering principles.
Best regards,
Dear @Salur.Basbug and @Jason.Jonkman
Thank you so much for the precise reply, it helps a lot!
Kindest regards
Younes
Dear all，
Have you ever encountered strange data results? For example, in the case of a single fan, is the wind speed at the center of the hub not positively correlated with the power generation? Maybe someone can tell me why?
Best regards
Hi,
It would be easier to judge, if you plot wind speed & GenPwr on the top of each other over the given time period.
There might be a small time lag between wind speed & GenPwr changes, since some parameters are filtered in OpenFAST e.g. in the turbine controller (low-pass filter to eliminate quick fluctuations). Also there is the turbine inertia, so it takes some time for the turbine speed to increase, when the wind becomes faster.
Best regards,
Hello Jason, I would like to ask you how to connect all wind turbines to super controller in FAST.Farm.
The wind farm model information is below.
Number of wind turbine: 3
Turbine model: NREL 5MW
UseSC: True
The ‘super controller(SC)’ was built to only read wind turbine states using sample fortran code that you provide. To reading state check, I added below line
print*, 'time',t, '(P#1)',to_SC(1), '(P#2)',to_SC(2)
Also, the wind turbine controller was built to not only torque/blade pitch control but also send ‘electrical power(W)’ to SC. (Of course, the wind turbine controller was built using sample code(DISCON_SC.f90)) like this
(WTG Contorller #1)
to_SC(1) = avrSWAP(15) !
(WTG Controller #2)
to_SC(2) =avrSWAP(15)
The output is below. As you see the simulation result, SC can not read second wind turibne state(electrical power).
time 0.000000000000000E+000 (P#1) 0.0000000E+00 (P#2) 0.0000000E+00
time 3.00000000000000 (P#1) 1580182. (P#2) 0.0000000E+00
time 6.00000000000000 (P#1) 1616384. (P#2) 0.0000000E+00
time 9.00000000000000 (P#1) 1626957. (P#2) 0.0000000E+00
time 12.0000000000000 (P#1) 1566830. (P#2) 0.0000000E+00
time 15.0000000000000 (P#1) 1478938. (P#2) 0.0000000E+00
time 18.0000000000000 (P#1) 1389057. (P#2) 0.0000000E+00
time 21.0000000000000 (P#1) 1311764. (P#2) 0.0000000E+00
time 24.0000000000000 (P#1) 1285304. (P#2) 0.0000000E+00
time 27.0000000000000 (P#1) 1264880. (P#2) 0.0000000E+00
time 30.0000000000000 (P#1) 1238847. (P#2) 0.0000000E+00
Dear @Hyungyu.Kim,
I’m not sure why the power of the second turbine shows up as zero in your super controller. Have you set NumCtrl2SC = 1 in sc_init()? In the individual turbine controller (DISCON_SC), have you printed variable avrSWAP(15) to ensure that the power of turbine 2 is nonzero within that controller?
Best regards,
Thank Jason for your reply and sorry for my late reply 
(1) Have you set NumCtrl2SC = 1 in sc_init( )?
→ Yes! I did. For working test, I set NumCtrl2SC = 10. please refer to the figure below
(2) have you printed variable avrSWAP(15) to ensure that the power of turbine 2 is nonzero within that controller?
→ Yes! To find that 2nd wind turbine power output is not zero, I incuded a ‘print’ function in Discon_SC of 2nd WTG. Then, I checked the power output of 2nd WTG is not zero. However, the supercontroller still failed to catche the power output of 2nd WTG.
I wonder why the supercontroller can not catch the power output of 2nd WTG. I would like to ask you is there any tips on building a supercontroller?
Dear @Hyungyu.Kim,
It sounds like there is a problem in the data transfer between the individual turbine controller (DISCON_SC) and the super controller (SC). Perhaps a bug?
Have you tried following the data flow through OpenFAST and FAST.Farm to see where the problem might be? (Adding further print statements may help.)
If this is a bug, I would suggest moving this discussion from here to the OpenFAST issues page: Issues · OpenFAST/openfast · GitHub.
Best regards,
Thank you for your fast reply.
I really impressed with your quick response 
As your suggestion, I’m going to check the code again by adding ‘print’ function.
Also, I will move this issue to OpenFAST issues page if I can not find any solution.
If it’s not disturbing, could you send me the supercontroller code to get turbine power output from wind turbine in the situation I’m considering? Because i’m not confident in the code I built.
Dear @Hyungyu.Kim,
The code you shared for transferring power from the individual controllers to the super controller makes sense to me, which is why I’m suspecting a bug in the data transfer.
Best regards,
