Dear all,
In the recent work of Kelsey Shaler “Wake Interaction Modeling Using A Parallelized Free Vortex Wake Model, thesis, 2020”, the FVW method has been extended to multiple turbines including the parallelization in FAST v7 and v8. Does someone know can we run multiple-turbines case with FVW method in OpenFAST coupled with elasto, servo, hydro …? Another question is regarding the FVW method in FAST.Farm, does it make sense to run multiple turbines with FVW method in FAST.Farm?
Thanks in advance.
Best regards,
Wenchao
Dear @Wenchao.Yu,
The work presented in Kelsey Shaler’s PhD thesis is not included in the NREL versions of the FAST v7, FAST v8, or OpenFAST (the work was done independently of NREL and prior to Kelsey joining NREL).
The standalone AeroDyn driver now supports multiple rotors with aerodynamic interaction included when the FVW model of OLAF is enabled (see a demonstration of that capability in our recent Wind Energy Science paper: WES - A multipurpose lifting-line flow solver for arbitrary wind energy concepts and the documentation here: 4.2.1.5. AeroDyn Driver — OpenFAST v3.3.0 documentation). That said, this functionality has not yet been interfaced to a structural solver that supports multi-rotor systems.
FAST.Farm supports the ability to model wake interaction between wind turbines in a wind farm, including aerelastics for each rotor, but the wake model is based on dynamic wake meandering (DWM) theory rather than FVW theory. When using FAST.Farm, you could choose to calculate the rotor aerodynamic loads using OLAF within the AeroDyn module of OpenFAST, but FAST.Farm would still consider the wake based on DWM theory in this case. One project we’d like to pursue at some point is an improved coupling between OLAF and FAST.Farm–where OLAF resolves the near wake and DWM resolves the far wake, but we have not been funded for such a project yet.
Best regards,
1 Like
@Jason.Jonkman Thanks a lot for your reply, that’s super clear now and it is interesting to have the coupling between OLAF and FAST.Farm in the future 
Just to report, I set up a case recently for multiple-turbines simulation in FAST.Farm based on the r-test case of glue-code/fast-farm/TSinflow and activated OLAF model for rotor aerodynamic loads computation, I got an error as below:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
==2629== Invalid read of size 8
==2629== at 0x6C96D7: __fastwrapper_MOD_fwrap_calcoutput (FASTWrapper.f90:591)
==2629== by 0x6E0735: __fastwrapper_MOD_fwrap_t0 (FASTWrapper.f90:511)
==2629== by 0x44452F: __fast_farm_subs_MOD_farm_initialco (FAST_Farm_Subs.f90:2050)
==2629== by 0x79CE6E: MAIN __ (FAST_Farm.f90:109)
==2629== by 0x79D13C: main (FAST_Farm.f90:28)
==2629== Address 0x0 is not stack’d, malloc’d or (recently) free’d
At the line FASTWrapper.f90:591,
y%D_rotor = 2.0_ReKi * maxval(m%Turbine%AD%m%rotors(1)%BEMT_u(indx)%rLocal)
! BEMT_u(indx) is calculated on inputs that were passed INTO AD_CalcOutput; Input(1) is calculated from values passed out of ED_CalcOutput AFTER AD_CalcOutput
It seems like rLocal is not allocated in FAST.Farm if we use OLAF to compute aerodynamic loads. If switching to BEMT, everything just works properly. Have you ever seen this problem when using OLAF in FAST.Farm?
Thanks for the discussion.
Best regards,
Wenchao
Dear @Wenchao.Yu,
Thanks for finding the offending line in FASTWRapper.f90! This is very helpful in troubleshooting!
I looked through the history of this section of code to see why this issue exists. From what I can tell, we likely did not test OLAF with FAST.Farm when we implemented it a few years ago. So this bug has likely existed since OLAF was added in 2019.
I’m not entirely certain how difficult this will be to fix. I’ll look into it this evening and see what can be done. In the meantime I have opened an issue on OpenFAST (Segmentation in FAST.Farm with OLAF (AD15) · Issue #1391 · OpenFAST/openfast · GitHub).
Regards,
Andy
Dear @Andy.Platt,
Thanks for your reply. I’ll also try to fix it properly.
Just to confirm with you, use the rotor diameter calculated at initialization can simply avoid this bug. But of course, calculate the rotor diameter from a flat disk projection in OLAF would be more appropriate.
Best regards,
Wenchao
Let’s move this discussion to the GitHub issue Andy started. I’ve added further comments there.
Thanks,