I tried to compile OpenFAST asper the documentation. I followed all steps one-by-one, but when I try to do the actual compilation, CMake fails with:

$ FC=gfortran cmake ../
-- The CXX compiler identification is GNU 6.4.0
-- The C compiler identification is GNU 6.4.0
-- The Fortran compiler identification is GNU 6.4.0
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- broken
CMake Error at /usr/share/cmake-3.6.2/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "/usr/bin/c++.exe" is not able to compile a simple test
  program.

  It fails with the following output:

   Change Dir: /home/FejPau/code/OpenFAST/build/CMakeFiles/CMakeTmp



  Run Build
  Command:"/cygdrive/c/opal-rt/rt-lab/v11.2.1.100/common/bin/gmake.exe"
  "cmTC_af8f7/fast"

  C:\opal-rt\rt-lab\v11.2.1.100\common\bin\gmake.exe -f
  CMakeFiles/cmTC_af8f7.dir/build.make CMakeFiles/cmTC_af8f7.dir/build

  gmake.exe: command not found: /bin/sh

  gmake.exe: *** [cmTC_af8f7/fast] Error 0x7f





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:18 (project)


-- Configuring incomplete, errors occurred!
See also "/home/FejPau/code/OpenFAST/build/CMakeFiles/CMakeOutput.log".
See also "/home/FejPau/code/OpenFAST/build/CMakeFiles/CMakeError.log".

I attached CMakeOutput.log and CMakeError.log.

The strange thing is, when looking at CMakeError.log, it calls gmake.exe from C:\opal-rt\rt-lab\v11.2.1.100\common\bin\gmake.exe. I tried to remove this folder from the PATH environment variable, but it still tries to run gmake.exe from there.

I can't uninstall rt-lab because I need this for another project.

What else can I try?

CMakeError.log
CMakeOutput.log

When you declare fixed-length arrays in the registry input file, the FAST Registry doesn't treat them properly with the -ccode flag. There is a mixup between the pointers and the values pointed to.

The current workaround is to make the arrays allocatable and allocate them inside your code.

HydroDyn invokes an intrinsic pseudo-random number generator (pRNG) to derive the internal wave kinematics time series from the wave frequency and direction spectra. However, the intrinsic pRNG is different across different compilers and operating systems, making cross comparisons of time-domain response difficult.

TurbSim also uses a pRNG to derive wind time series from the wind spectrum (among other uses). In addition to an intrinsic pRNG, TurbSim also has a built-in pRNG named RanLux (implemented in Fortran source code). If RanLux where moved to the NWTC_Library, it could be used by FAST modules. It is recommended to add the RanLux pRNG to the NWTC_Library and use it as an optional pRNG within HydroDyn. (The intrinsic pRNG is initialized with 2 seeds; the RanLux pRNG is initialized with 1 seed and is selected by setting the second random seed to the RanLux keyword.) Once implemented, when the RanLux pRNG is selected in HydroDyn, it will then be possible to have identical wave kimenatics time series to enable cross comparisons of time-domain responses across different compilers and operating systems.

With the latest updates on the dev branch, I get a compilation error when using GNU gfortran 6.3.0. I am not sure where the character length 11 is showing up, every entry in ParamUnitsAry is neatly formatted and looks like it is 10 characters long.

openfast/modules-local/aerodyn/src/AeroDyn_IO.f90:3092:122:

                                "(N/m)     ","(N/m)     ","(N/m)     ","(N/m)     ","(N/m)     ","(N/m)     ","(-)       ", &
                                                                                                                          1
Error: Different CHARACTER lengths (10/11) in array constructor at (1)
openfast/modules-local/aerodyn/src/AeroDyn_IO.f90:3446:34:

             p%OutParam(I)%Units = ParamUnitsAry(Indx) ! it's a valid output
                                  1
Error: Function 'paramunitsary' at (1) has no IMPLICIT type

@ghaymanNREL @bjonkman

The Line2-to-Point mesh-mapping algorithm for loads documented in our AIAA paper is correct. However, there is a bug in the implementation of the mapping search part of the algorithm that leads to the problems--basically, while the total integrated loads are correct, the local loads distributed along the Point elements are incorrect when the number of points elements is greater than the number of Line2 nodes.

FAST users have reported this problem in the following forum posts:
https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1767
https://wind.nrel.gov/forum/wind/viewtopic.php?f=3&t=1701

DWM driver contains USE ifport which is specific to Intel Fortran Compiler. This code fails to compile with gfortran.

Is it possible to fix this warning directly in OpenFAST?

include/FAST_Library.h:37:12: warning: ‘AbortErrLev’ defined but not used [-Wunused-variable]

I thought that we had already included calculations of the rotational velocity of the blade nodes in ElastoDyn, but looking at the code after a user on the forum reported that the terms were missing: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1900, I confirm that the they have not been calculated. While AeroDyn doesn't need the rotational velocity of the blade nodes, the AeroDyn nodes may be offset from the ElastoDyn nodes, so a rotational velocity of the ElastoDyn nodes should lead to a change in the translational velocity of the AeroDyn nodes through the mesh-mapping routines. These terms should be included in a future release of ElastoDyn.

The second problem reported in the forum topic linked above only applied to an earlier version of FAST, which has already been fixed.

The upper bound on WaveDir is checked incorrectly in the WAMIT2 submodule of HydroDyn. See the following forum topic for details: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1670.

The second problem reported in that forum topic is not a bug; the direction pairs must be fully populated (not sparse).

A DISCON dynamic-linked library (DLL) is needed to run OpenFAST if the ServoDyn input file is using option 5 for the PCMode and VSContrl parameters.

The DISCON DLL is built from a fortran file containing the DISCON subroutine with the following interface:

SUBROUTINE DISCON ( avrSWAP, aviFAIL, accINFILE, avcOUTNAME, avcMSG ) BIND (C, NAME='DISCON')
!DEC$ ATTRIBUTES DLLEXPORT :: DISCON

We should probably include a 'dummy' DLL in a standard build via a DISCON.f90 file, and people can replace the dummy DISCON.f90 file with their own if they need a certain controller behavior. Perhaps this DISCON.f90 file lives in modules-local/servodyn/src ?

As a side note, various regression tests need different flavors of the DISCON DLL, what process is responsible for building these prior to launching regression tests? Perhaps this is a separate issue!

I compiled openfast using intel compiler with MKL math library. For Test21, I found that when I set OMP_NUM_THREADS parameter to a larger number, the MKL can run in parallel, which can speed-up the calculation. However, when OMP_NUM_THREADS is set to different values, the generated Test21.SD.sum files are different, and then obviously the final calculation results are different. Any reason for this to happen?

Thanks!

Hai

In BeamDyn, the number of quadrature points when using trapezoidal quadrature should equal

( Station_Total - 1 )*Refine - 1

but in routine SetParameters() of BeamDyn.f90, the number of quadrature points when using trapezoidal quadrature is set incorrectly using the number of key points for the first member

( kp_total - 1 )*Refine - 1

I guess this wasn't found before because in the NREL 5-MW example, kp_total = Station_Total.

Thanks go to Bonnie Jonkman of Envision Energy USA for reporting this bug.

Build OpenFAST on Ubuntu, and tried running

openfast -h

The help flag doesn't seem to work, and the executable is still looking for an input file. Also, it seems the executable names are FAST.exe and FAST_x64.exe, not openfast.

Full output:

pete@pete-VirtualBox:~/projects/openfast/build$ openfast -h

  Syntax is:

     FAST [-h] <InputFile>

  where:

     -h generates this help message.
     <InputFile> is the name of the required primary input file.

  Note: values enclosed in square brackets [] are optional. Do not enter the brackets.


 **************************************************************************************************
 OpenFAST

 Copyright (C)  National Renewable Energy Laboratory

 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.
 **************************************************************************************************

 OpenFAST-v0.1.0-948-gfcb6fab7-dirty
 Compile Info:
  - Architecture: 64 bit
  - Precision: double
 Execution Info:
  - Date: 03/27/2018
  - Time: 13:50:04-0400


  Syntax is:

     OpenFAST [-h] <InputFile>

  where:

     -h generates this help message.
     <InputFile> is the name of the required primary input file.

  Note: values enclosed in square brackets [] are optional. Do not enter the brackets.


  Syntax is:

     FAST_x64.exe [-h] <InputFile>

  where:

     -h generates this help message.
     <InputFile> is the name of the required primary input file.

  Note: values enclosed in square brackets [] are optional. Do not enter the brackets.


 FAST_InitializeAll:The required input file was not specified on the command line.

 FAST encountered an error during module initialization.
  Simulation error level: FATAL ERROR

  Aborting OpenFAST.

The OpenFAST documentation has instructions to help developers build the documentation locally to aid in producing documentation. However, the approach to building the documentation locally on Windows is unclear. Guidance should provided for Windows-based developers (such as myself) on how to build documentation locally on Windows.

Following the document, I successfully built OpenFAST into an executable program both on Linux and Windows cygwin. Now I want to build OpenFAST into a dynamic library for embedding usage, but I didn't find instructions about this topic in the document.

I knew nothing about the command line usage mode of CMake, so according to my guess I just tried,

cmake ../ -DBUILD_FAST_CPP_API=1

Unfortunately the error message is shown in both Linux and Windows cygwin,

Could NOT find MPI_C (missing: MPI_C_LIBRARIES MPI_C_INCLUDE_PATH)

Is my method correct, and how to compile OpenFAST into a dynamic library on Linux and Windows cygwin?

To automatically check the code (and PRs) will compile and pass tests, these services could be used:

• Travis CI for Linux
• AppVeyor for Windows
• GitHub Actions

Update - Adding environment matrix
Systems

• macOS
• Windows
• Linux (Ubuntu)

Compilers

• GNU Fortran 10
• Intel Fortran 2020 (oneAPI Classic)
• CygWin - Windows only

Test types

• Regression tests
  • glue-codes
  • individual modules
• Unit tests
• Memory footprint

The OpenFAST documentation on read-the-docs (http://openfast.readthedocs.io/en/latest/) refers to the ability to get the documentation in PDF format via a “box” in the lower left corner of the browser screen. However, this functionality is not yet supported.

The member-based hydrodynamic coefficients in HydroDyn do not appear to be sorted correctly when they are specified top-down instead of bottom-up. This bug was reported in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1636.

The local sectional load (force/moment) outputs from BeamDyn are not correct. We'd prefer to implement these load calculations via integration of the applied, gravitational, and inertial loads distributed along the beam from the section to the tip, plus the relevant applied point loads.

More information provided in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=3&t=1622.

AeroDyn14 driver contains USE AeroDyn_Types instead of USE AeroDyn14_Types. Looks like the code needs to be updated to reflect the changes since introduction of AeroDyn v15.

Historically, NREL's supported a MATLAB toolbox (https://github.com/OpenFAST/matlab-toolbox) that could be used to convert FAST input files from one version to another to aid users in upgrading their models when upgrading FAST versions. However, this toolbox has not yet been updated (or an equivalent script provided in its place) to support converting input files from FAST v8.16 to OpenFAST v1.0 format. The format of OpenFAST v1.0 is not too different from that of FAST v8.16 (without only one minor change to the FAST primary input file and several additions to the AeroDyn primary input file), but these differences will grow over time, so, the script must be continually updated along with OpenFAST.

Moreover, all of the sample OpenFAST inputs files in the regression tests still include version numbers based on the old module-specific numbering convention. Now that the version numbering convention has changed in OpenFAST, the version numbers in the example input files should be updated accordingly.

See attached file for description of the problem.

BeamDyn_InitializationBug.pdf

There is a small bug preventing HydroDyn from functioning properly when a model has no strip-theory nodes (NJoints = NMembers = 0). This is discussed more in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=3&t=1227&p=8160.

As a workaround until this bug is fixed, one can set up a HydroDyn module with two joints and one member, but with all member properties and coefficients set to zero.

While the translational displacement outputs from BeamDyn are correct, the corresponding rotational displacement outputs from BeamDyn are not. More information is discussed in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1564&p=7780.

Dear developers,

there is a tiny error in ElastoDyn_IO.f90, line 3620:
CALL ReadVar( UnIn, InputFile, InputFileData%NacYaw, "RotSpeed", "Initial nacelle-yaw angle (deg)", ErrStat2, ErrMsg2, UnEc)

I think the fourth argument should be "NacYaw".

Best,
Chengyu Wang

The OpenFAST documentation has a great section describing the conversion from FAST v8.16 to OpenFAST v0.1 (http://openfast.readthedocs.io/en/latest/source/user/fast_to_openfast.html). However, the changes between OpenFAST v0.1 and v1.0 are only briefly summarized at a high level in the release comments in the OpenFAST v1.0.0 tag (https://github.com/OpenFAST/openfast/releases). A release notes section should be added to the OpenFAST documentation summarizing the key details of what is new in each release to aid the general user. What's important to include in the release notes is a summary of the new features and changes to existing features that will effect the solution (e.g. bug fixes), including changes to the input files that the general user should understand when upgrading. While anyone can review the commit logs to find all of the details of changes, there is generally far too much detail in the commit logs for the general user to comprehend. The release notes should be the user-oriented summary of these commit logs.

I'm preparing to change the nwtc.nrel.gov website to link to OpenFAST and to publicly announce the release of OpenFAST, but a release notes section in the OpenFAST documentatoin for the upgrade from OpenFAST v0.1 to OpenFAST v1.0 should be added first. This release notes section can then be updated as additional OpenFAST tags are added in the future.

I have compiled two versions of openfast in Linux/CMake using Intel and gcc respectively. And I compared their results for Test21 with the results in https://github.com/NWTC/FAST. The three results are just different with each other. Any one has an idea? I need a standard way to compile openfast so that I can use this as the benchmark.
Thanks!

Dear all,
as I'm new to compiling in general so I hope you can give me a hint which way to try.
Because of limited disk space I can't install Cygwin on my machine. Visual Studio and Intel Fortran are not available to me.
Can you give me some guidance on what software to take and how to do it?
I need a 32bit version of OpenFAST.
Can someone send me an executable or help me creating one by myself.

Attached the error I got with mingw32 when compiling openfast.

Best regards,
Simon

We should include WinSock2.h in modules-ext/map/src to avoid compiling issues on Windows for people who only have the current Windows SDK on their machine or whose $(WindowsSDK_IncludePath) variable points to an SDK more recent than 7.1a.

I've fixed this on a Windows box by simply adding the path to the 7.1a include dir for my build box, i.e., C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include, in the MAP_dll project properties under VC++ Directories -> Include Directories.

But if we simply add WinSock2.h to the MAP_dll project, then the above fix is not needed and this solution would be valid for all Windows builds. We would need to exclude WinSock2.h from non-Windows builds.

When you turn on the VTK output, the file naming convention is something like:
Model.AD_Blade1.t0.vtp
Model.AD_Blade1.t1.vtp
...
Model.AD_Blade1.tN.vtp

In order for Paraview to read in and animate the entire time series, the "t" should not be there. Instead, the filename should look like:
Model.AD_Blade1.0.vtp
Model.AD_Blade1.1.vtp
...
Model.AD_Blade1.N.vtp

This DISCON library is discussed in other issues, but it seems like this is an issue all its own. Currently OpenFAST does not appear to be portable to OSX (and likely Windows too?). We have a test in Nalu that couples with OpenFAST and it is not able to succeed on OSX due to it requiring a .so library:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library ../../mesh/5MW_Baseline/ServoData/libDISCON_glin64.so could not be loaded. Check that the file exists in the specified location and that it is compiled for 64-bit applications

Dear developers,

I am new with the OpenFast project and tried to compile OpenFast on a 64-bit LINUX machine (CentOS 6.9) and a GNU 4.4.7 C and Fortran compiler.
I could create the Makefiles (cmake) for OpenFAST. Here are the messages of "cmake":

-- The CXX compiler identification is GNU 4.4.7
-- The C compiler identification is GNU 4.4.7
-- The Fortran compiler identification is GNU 4.4.7
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - found
-- A library with BLAS API found.
-- A library with BLAS API found.
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- A library with LAPACK API found.
-- Setting system file as: src/SysGnuLinux.f90
-- Configuring done
-- Generating done
-- Build files have been written to: /fs/jochen/OpenFAST/build

But when running "make", I get the following error messages for the compilation of SysGnuLinux.f90:

build-g44:/fs/jochen/OpenFAST/build>make
[ 4%] Built target fast_registry
[ 5%] Building Fortran object
modules-local/nwtc-library/CMakeFiles/nwtclibs.dir/src/SysGnuLinux.f90.o
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:181.12:

REAL(DbKi), INTENT(IN) :: DblNum
1
Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:227.15:

  REAL(QuKi), INTENT(IN)     :: x             ! input 
           1

Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:228.15:

  REAL(QuKi)                 :: NWTC_ERFR16   ! result
           1

Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:222.3:

FUNCTION NWTC_ERFR16( x )
1
Error: Function result 'nwtc_erfr16' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:266.15:

  REAL(QuKi), INTENT(IN)     :: x             ! input 
           1

Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:267.15:

  REAL(QuKi)                 :: NWTC_GammaR16  ! result
           1

Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:261.3:

FUNCTION NWTC_GammaR16( x )
1
Error: Function result 'nwtc_gammar16' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:375.15:

  REAL(DbKi), INTENT(inout)           :: Inf_D          ! IEEE value for

Na
1
Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:376.15:

  REAL(DbKi), INTENT(inout)           :: NaN_D          ! IEEE value for

In
1
Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:382.15:

  REAL(DbKi)                          :: Neg_D          ! a negative

real(D
1
Error: Kind -1 not supported for type REAL at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:391.23:

  Neg_D = -1.0_DbKi
                   1

Error: Missing kind-parameter at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:398.22:

  Neg_D = 0.0_DbKi
                  1

Error: Missing kind-parameter at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:401.22:

  Inf_D = 1.0_DbKi / Neg_D
                  1

Error: Missing kind-parameter at (1)
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:169.26:

FUNCTION Is_NaN( DblNum )
1
Error: Symbol 'dblnum' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:222.26:

FUNCTION NWTC_ERFR16( x )
1
Error: Symbol 'x' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:261.28:

FUNCTION NWTC_GammaR16( x )
1
Error: Symbol 'x' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:365.39:

SUBROUTINE Set_IEEE_Constants( NaN_D, Inf_D, NaN, Inf )
1
Error: Symbol 'nan_d' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:365.46:

SUBROUTINE Set_IEEE_Constants( NaN_D, Inf_D, NaN, Inf )
1
Error: Symbol 'inf_d' at (1) has no IMPLICIT type
/fs/jochen/OpenFAST/modules-local/nwtc-library/src/SysGnuLinux.f90:394.26:

  NaN_D = SQRT ( Neg_D )
                      1

Error: Symbol 'neg_d' at (1) has no IMPLICIT type
make[3]: ***
[modules-local/nwtc-library/CMakeFiles/nwtclibs.dir/src/SysGnuLinux.f90.o]
Error 1
make[2]: ***
[modules-local/nwtc-library/CMakeFiles/nwtclibs.dir/src/SysGnuLinux.f90.o.pr
ovides] Error 2
make[1]: *** [modules-local/nwtc-library/CMakeFiles/nwtclibs.dir/all] Error
2
make: *** [all] Error 2

Maybe someone has an idea what's going wrong.
Thanks in advance for your help!
Jochen Lang

It has been mentioned recently that AeroDyn 14 may be phased out in favor of AeroDyn 15. This issue is intended to start that conversation.

@jjonkman Is there anything that is in AeroDyn 14 but not in AeroDyn 15?

In routine CalculateStandardYaw of ServoDyn.f90, the yaw angle (position) command when the yaw rate is commanded from a Bladed-style DLL is calculated by adding an increment of YawRateCom*DT to the current yaw angle. However, the yaw angle command should be defined as the integral of the yaw rate command, regardless of the current yaw angle (i.e. the yaw angle command must become a state of ServoDyn). As it is currently implemented (incorrectly), when the yaw rate commanded from a Bladed-style DLL is zero, the yaw angle is commanded to be current yaw angle, effectively eliminating the yaw spring stiffness, yielding large yaw errors. I would not use yaw control from Bladed-style DLL controllers until this bug is fixed.

See the following forum topic for more information: https://wind.nrel.gov/forum/wind/viewtopic.php?f=30&t=1844&p=9256.

The regression test framework always checks for matplotlib, but should only do so when the cmake flag CTEST_PLOT_ERRORS is ON.

I was browsing the documentation and saw that multiple Reynolds number airfoil data, and interpolation between these, is not yet supported. Is this in progress on a branch, or is there some discussion on what needs to be done, etc.?

We are currently developing our own controller to work with FAST and we want to use the avrSWAP(15) (ElecPwr) for some control loop. However, after the first call of the controller, a value for avrSWAP(15) is set, but is not updated in the subsequent calls. I compared the behavior of avrSWAP(14) (RotPwr), and this value is updated correctly in each iteration.

This issue is aimed at adding input file options that might help the user better diagnose standalone runs with BeamDyn.

1. A finite difference routine is required for the developed to help compare the analytical BeamDyn formulation against a numerical counterpart. Relevant developer flags should be added to the input file.
2. A few variables are currently hard coded. Specifically, the maximum load retries and maximum static iterations. These should ideally be input file options.

The Simulink interface to FAST consists of Simulink calling the FAST S-Function, which calls the FAST dynamic library. While the OpenFAST repository includes the glue code and MATLAB script for compiling the FAST S-Function, the OpenFAST repository doesn't include a CMake script or VS-Build solution for compiling the FAST dynamic library.

Related to this missing build, is a misplacement of the FAST_Library.f90 source file. FAST_Library.f90 is to the FAST dynamic library for the Simulink interface as FAST_Prog.f90 is to compiling the OpenFAST executable. FAST_Library.f90 is currently included in the modules-local/fast-library/src directory; however, it seems like FAST_Library.f90 should be moved to the glue-codes/Simulink directory.

The DLLEXPORT directives in FAST_Library.f90 for Intel Fortran Compiler generates warnings when compiling on Unix-y architectures. Replace snippets as below to quell this warning

!DEC$ ATTRIBUTES DLLEXPORT::FAST_Sizes
#ifndef IMPLICIT_DLLEXPORT
!GCC$ ATTRIBUTES DLLEXPORT :: FAST_Sizes
#endif

with

#ifndef IMPLICIT_DLLEXPORT
!DEC$ ATTRIBUTES DLLEXPORT::FAST_Sizes
!GCC$ ATTRIBUTES DLLEXPORT :: FAST_Sizes
#endif

CMake is already set up to handle addition of -DIMPLICIT_DLLEXPORT on Unix-y architectures.

The data format of the various user-specified wave-kinematics input files (.Elev, .Vxi, .Vyi, .Vzi, .Axi, .Ayi, .Azi, and .DynP) used with the WaveMod = 6 option in HydroDyn are very finicky, with very specific requirements regarding data format, white space, etc. This has caused many users trouble. HydroDyn should be made more robust so that the data format requirements are more user-friendly. More information can be found in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1690.

@bjonkman of Envision Energy recently reported to me that she found a minor bug in the FAST driver/glue code that results in incorrect values of the generator torque and electrical power being sent from ServoDyn to Bladed-style DLLs. There has also been some discussion about this on the forum: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1668&p=9779. Bonnie said she'll provide NREL with the fix soon.

Port updates from https://github.com/gantech/fastv8DriverProgram for the OpenFOAM/Nalu interface to OpenFAST repo.

@gantech

There are some known compiling errors that were documented in the Compiling Instructions for FAST8:

1. The version of gfortran must be at least 4.6.0. NWTC Library uses some quad-precision variables, which are not supported in earlier versions of gfortran.
   Possible workarounds: You might be able to set QuKi to some other supported real kind that is not 4 or 8 (not sure REAL(2) is supported, but you could try); otherwise, you'd have to set QuKi to 4 or 8 and remove the QuKi MODULE PROCEDURE lines from all the INTERFACE blocks at the top of the NWTC Library source files.
2. Intel Fortran must be version 11 or later. NWTC Library uses the gamma() function, which is not provided in earlier versions.
   Possible workarounds: You can write your own gamma() function in the SysI*.f90 files, or remove the calls to gamma() (e.g., set nwtc_gamma = 1) and avoid using IceDyn and the wave spreading features of HydroDyn.

It is recommended to put a minimum version requirement for both gfortran and ifort compilers in cmake.

@bjonkman Thanks for pointing this out.

Currently, the motion output mesh from BeamDyn is based on the finite-element nodes. However, with low-order elements commonly used (Order_Elem <= 7), this results in only a handful of nodes where motions are passed from BeamDyn to the aerodynamic solver (e.g. AeroDyn or CFD) resulting in a coarse distribution of motions used in the aerodynamics calculation. It would be better to define the motion output mesh from BeamDyn based on the spatial-integration method, so that if trapezoidal quadrature is used (Quadrature = 2), the motion distribution passed to the aerodynamics solver is better resolved.

When trying to compile in single precision, errors are encountered in Driver_Beam_Subs.f90 and OrcaDriver_Subs.f90.

In Driver_Beam_Subs, the problems are at lines 427, 596, 598. At 596 and 598, the fix is relatively simple--just need to change those constant 1.0_ReKi's to 1.0_R8Ki. I believe this is the correct fix, as BeamDyn is always run in double precision. At line 427, the variable DvrData%MultiPointLoad is the problem in that it needs to be double (BDKi) instead of single to be passed to the Find_IniNode() subroutine. DvrData is of type BD_DriverInternalType (defined at the top of Driver_Beam_Subs), and MultiPointLoad is given type ReKi, which, perhaps, should instead be R8Ki. However, I do not know enough about the inner workings to know whether this is the case.

In OrcaDriver_Subs, the problems are at lines 1981 and 1990, and are the same issue. The offending variable here is u%PtfmMesh%TranslationDisp, where PtfmMesh is MeshType, and TranslationDisp is defined to be R8Ki. Everything else in the array being constructed at 1981/1990 is real(4) in single precision, so the quick and dirty fix that gets it to compile is wrapping the three references to u%PtfmMesh%TranslationDisp on each line in real( *, ReKi). However, the better strategy may be to change TranslationDisp to ReKi in ModMesh_Types.f90, though, again, I may not know enough to be correct in this.

The TRANSFER function puts data on the stack, so pack and unpack routines generated by the FAST Registry can cause stack overflow errors when run on large data sets (e.g., large wind files or large offshore models).

I receive fatal build error:
Not a git repository (or any parent up to mount point /cygdrive/c)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

At this point I have not investigated any further. Should test a non-Windows cmake build under the same conditions: zip download instead of git clone

Dear developers,

I find an error regarding the Renolds number calculation in the file:
modules-local/aerodyn/src/BEMTUncoupled.f90, line 96, which is:
Re = airDens * W * chord / mu
It seems to be problematic, because the variable 'mu' here is actually the kinematic viscosity, rather than the dynamic viscosity. This line is within the subroutine:
subroutine BEMTU_Wind( axInduction, tanInduction, Vx, Vy, chord, airDens, mu, W, Re )
which is called by many other functions, an example is in the file:
modules-local/aerodyn/src/BEMT.f90, line 977, which is:
call BEMTU_Wind( 0.0_ReKi, 0.0_ReKi, u1%Vx(i,j), u1%Vy(i,j), p%chord(i,j), p%airDens, p%kinVisc, Vrel, Re )
The seventh argument is kinematic viscosity instead of dynamic viscosity! It is true for other calls of the function. The easiest way to correct may be just to replace the line 96 of BEMTUncoupled.f90 with:
Re = W * chord / mu

It is also the case for fastv8 repository. I hope this could help. Thanks.

Best,
Chengyu Wang

BeamDyn often requires small time steps that could be increased if BeamDyn is given better initial conditions that reduce start-up transients. Addressing this problem may be aided by the currently BeamDyn linearization effort currently under development.