Fortran compiler is not able to compile a simple test program.

[QusayHawari]

Hi,

I am working on MAC, and trying to obtain the OpenFAST build libraries. I used Brew to get all the necessary tools (cmake, gcc, fortran, openblas, lapack). I also used Brew install OpenFAST. To make sure I have all the tools, I used Brew info OpenFAST, and I got the following;

brew info OpenFAST
openfast: stable 3.0.0 (bottled)
NREL-supported OpenFAST whole-turbine simulation code
https://openfast.readthedocs.io
/usr/local/Cellar/openfast/3.0.0 (5 files, 27.1MB) *
  Poured from bottle on 2021-10-04 at 14:18:40
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/openfast.rb
License: Apache-2.0
==> Dependencies
Build: cmake ✔
Required: gcc ✔, openblas ✔
==> Analytics
install: 9 (30 days), 14 (90 days), 36 (365 days)
install-on-request: 9 (30 days), 14 (90 days), 36 (365 days)
build-error: 0 (30 days).

To get the Makefiles I used cmake .. (after moving into the directory of /OpenFAST/build, and using mkdir build && cd build) and executed/got the following:

which openfast
/usr/local/bin/openfast
openfast -v

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

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

 OpenFAST-HEAD-HASH-NOTFOUND
 Compile Info:
  - Compiler: GCC version 11.1.0
  - Architecture: 64 bit
  - Precision: single
  - OpenMP: No
  - Date: Jun 26 2021
  - Time: 17:11:58
 Execution Info:
  - Date: 10/04/2021
  - Time: 18:27:28+0100

  OpenFAST terminated normally.

cd /Users/qusayhawari/OpenFAST/build 
mkdir build && cd build
build 
cmake ..
-- The CXX compiler identification is AppleClang 12.0.5.12050022
-- The C compiler identification is AppleClang 12.0.5.12050022
-- The Fortran compiler identification is Intel 19.1.3.20200925
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: /usr/local/bin/ifort
-- Check for working Fortran compiler: /usr/local/bin/ifort - broken
CMake Error at /usr/local/Cellar/cmake/3.21.3_1/share/cmake/Modules/CMakeTestFortranCompiler.cmake:54 (message):
  The Fortran compiler

    "/usr/local/bin/ifort"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/local/bin/gmake -f Makefile cmTC_bd6ab/fast && /usr/local/bin/gmake  -f CMakeFiles/cmTC_bd6ab.dir/build.make CMakeFiles/cmTC_bd6ab.dir/build
    gmake[1]: Entering directory '/Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeTmp'
    Building Fortran object CMakeFiles/cmTC_bd6ab.dir/testFortranCompiler.f.o
    /usr/local/bin/ifort    -c /Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTC_bd6ab.dir/testFortranCompiler.f.o
    Linking Fortran executable cmTC_bd6ab
    /usr/local/Cellar/cmake/3.21.3_1/bin/cmake -E cmake_link_script CMakeFiles/cmTC_bd6ab.dir/link.txt --verbose=1
    /usr/local/bin/ifort CMakeFiles/cmTC_bd6ab.dir/testFortranCompiler.f.o -o cmTC_bd6ab 
    ld: library not found for -lSystem
    gmake[1]: *** [CMakeFiles/cmTC_bd6ab.dir/build.make:99: cmTC_bd6ab] Error 1
    gmake[1]: Leaving directory '/Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeTmp'
    gmake: *** [Makefile:127: cmTC_bd6ab/fast] Error 2

  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 "/Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeOutput.log".
See also "/Users/qusayhawari/OpenFAST/build/build/CMakeFiles/CMakeError.log".

Is there anything I can change from the cmake file, or use a different cmake compiler for it to work?

I previously used clang 4.0, but did't work as well.

Thanks in advance, Qusay.

[rafmudaf]

Hi @QusayHawari

Did you do the command brew install openfast? If so, then you have already installed a working OpenFAST binary. In fact, the command which openfast shows that you do have one installed and it was compiled with GCC 11.1 on June 26, 2021. This corresponds to the commits where the Homebrew formula was updated: https://github.com/Homebrew/homebrew-core/commit/ad28f76fb845d3d5355b6bf7c998769b4d986c01 and https://github.com/Homebrew/homebrew-core/commit/5a28114225f8839ed78bd3c45f3d9645b50bf377.

I think it might not be totally clear the steps you need to go through to "install" OpenFAST. You have two options on macOS: compile the code yourself or install via conda/brew. If you aren't going to make changes to the source code, I highly recommend using conda/brew. Doing brew install openfast completely installs everything you need to run OpenFAST and you do not need to do anything with CMake or Make or the Intel compilers.

Try running a test case with this command: openfast your_input.fst.

I hope this helps!

[QusayHawari]

Hello Rafael,

Thanks for your quick reply!

I am new to OpenFAST, so I was reading through the documentation and got a little confused. I thought you needed to create the Makefiles by running cmake .. I previously worked on HAWC2, but the tool does not linearize offshore turbines and FOWTs (done using HawcStab2 on onshore).

My confusion is that I could not locate the input files e.g for the 5MW, 10MW, and 15MW (.fst). Each turbine model has its own aerodyn, aerodyn, hydrodyne...etc.

I only found those input files on the ROSCO controller as test cases and tuning cases.

Is there a way I can find those files or be able to access them. I am trying to get the open loop full order and reduced order linearized models of the FOWTs so that I can perform frequency analysis via Matlab?

Apologies for the long email, Qusay,

---

From: Rafael M Mudafort @.> Sent: 05 October 2021 15:31 To: OpenFAST/openfast @.> Cc: Qusay Hawari @.>; Mention @.> Subject: Re: [OpenFAST/openfast] Fortran compiler is not able to compile a simple test program. (#853)

Hi @QusayHawarihttps://github.com/QusayHawari

Did you do the command brew install openfast? If so, then you have already installed a working OpenFAST binary. In fact, the command which openfast shows that you do have one installed and it was compiled with GCC 11.1 on June 26, 2021. This corresponds to the commits where the Homebrew formula was updated: @.https://github.com/Homebrew/homebrew-core/commit/ad28f76fb845d3d5355b6bf7c998769b4d986c01 and @.https://github.com/Homebrew/homebrew-core/commit/5a28114225f8839ed78bd3c45f3d9645b50bf377.

I think it might not be totally clear the steps you need to go through to "install" OpenFAST. You have two options on macOS: compile the code yourself or install via conda/brew. If you aren't going to make changes to the source code, I highly recommend using conda/brew. Doing brew install openfast completely installs everything you need to run OpenFAST and you do not need to do anything with CMake or Make or the Intel compilers.

Try running a test case with this command: openfast your_input.fst.

I hope this helps!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenFAST/openfast/issues/853#issuecomment-934466910, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV5GZZAIZVE2RROZHDUZJ6DUFMD2XANCNFSM5FJ53PGA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jjonkman]

Dear @QusayHawari,

OpenFAST models of the NREL 5-MW baseline wind turbine atop various offshore support structures (OC3-monopile, OC3-tripod, OC4-jacket, OC3-Hywind spar, ITI Energy barge, MIT/NREL TLP, OC4 DeepCwind semisubmersible), are available in the OpenFAST r-test: https://github.com/OpenFAST/r-test/tree/main/glue-codes/openfast.

An OpenFAST model of the land-based IEA Wind 10-MW reference wind turbine (an update of the DTU 10-MW reference wind turbine) is available in the github repository of IEA Wind Task 37: https://github.com/IEAWindTask37/IEA-10.0-198-RWT/tree/master/openfast (but no offshore configurations are included here).

OpenFAST models of the IEA Wind 15-MW reference wind turbine atop various offshore support structures (monopile, UMaine semisubmersible) are available in the github repository of IEA Wind Task 37: https://github.com/IEAWindTask37/IEA-15-240-RWT/tree/master/OpenFAST.

Best regards,

[QusayHawari]

Hello,

Thank you for sending all the input files, much appreciated.

I tried running the 10MW model, but I faced this FATAL error.

I pointed at the correct path for the IEA-10.0-198-RWT_Cp_Ct_Cq.txt in the DISCON file. Should I give the full paths to all the input files?

Thanks in advance, Qusay.

cd /Users/qusayhawari/Downloads/openfast_IEA_10MW openfast_IEA_10MW % openfast IEA-10.0-198-RWT.fst

---

OpenFAST

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.

---

OpenFAST-HEAD-HASH-NOTFOUND Compile Info:

• Compiler: GCC version 11.1.0
• Architecture: 64 bit
• Precision: single
• OpenMP: No
• Date: Jun 26 2021
• Time: 17:11:58 Execution Info:
• Date: 10/05/2021

• Time: 23:32:17+0100

  OpenFAST input file heading: Generated with AeroElasticSE FAST driver

  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.

  FAST_InitializeAll:InflowWind_Init:Steady_ValidateInput: Horizontal wind speed (HWindSpeed) for steady winds must be greater than zero.

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

  Aborting OpenFAST.

[jjonkman]

Dear @QusayHawari,

The pathnames specified in OpenFAST input files can have an absolute or relative path.

Regarding the error you are receiving, my guess is that the input files you are using are formatted for a different version of OpenFAST than you are running. I don't see that the OpenFAST version is stated in the IEA Wind 10-MW reference wind turbine repository, and I can't tell what version you are running. But you should be able to figure those out by reviewing OpenFAST's API documentation: https://openfast.readthedocs.io/en/main/source/user/api_change.html. Enabling the Echo option may also help to debug problems with the input file formatting.

Best regards,

[QusayHawari]

Hello,

Thank you for the clarification.

I have OpenFAST -v3.0.0. The 15MW model is written for v2.4.

As you mentioned I didn't see any documentation on the version for the 10MW.

Is there a possibility I can install previous OpenFAST versions instead of having to update all the input files according to each version? This could help a lot specially when checking other turbine models, which may require other versions :)

Regards, Qusay.

[jjonkman]

Dear @QusayHawari,

You can find older releases of OpenFAST here: https://github.com/OpenFAST/openfast/releases. In general, however, I recommend using the newest version of the software unless there is a strong reason to use an older release, e.g., to ensure consistency with previous results.

Best regards,

[QusayHawari]

Hello,

Thanks for sending the link :)

I changed the input files for the UMaine 15MW) to be compatible with the version I have. Unfortunately, I am still getting an error that the Elastodyn file is improperly formatted.

OpenFAST input file heading: IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform

Running ElastoDyn. Nodal outputs section of ElastoDyn input file not found or improperly formatted. Running AeroDyn.

FAST_InitializeAll:AD_Init:ParsePrimaryFileInfo:ParseSiAry:

A fatal error occurred when parsing data from "./IEA-15-240-RWT_AeroDyn15.dat". The "Properties for tower node 1." array was not assigned valid REAL values on line #107. The text being parsed was : "15. 10. 1."

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

Aborting OpenFAST.

I have attached all the echo and input files (aero and elaso) for you to have a look at. From my understanding is that the eco files truncate the line were there's an error in the input file, but I could see were the error is.

Echos_853.zip Aero_Elasto_INPs.zip

Thanks in advance :) Qusay.

[jjonkman]

Dear @QusayHawari,

I understand that you are using OpenFAST v3.0; is that correct? The table of tower aerodynamic analysis nodes in the AeroDyn primary input file previously had three columns (TwrElev, TwrDiam, and TwrCd), but recently in OpenFAST v2.6 and newer, a fourth column was added (TwrElev, TwrDiam, TwrCd, and TwrTI). It looks like you need to add one column of data.

Best regards,

[QusayHawari]

Hello,

Thanks for you help throughout this process. I finally managed to run OpenFAST on the 15MW (semi-sub).
I am facing an error at a certain time in the simulation. The TSR is quite low, causing the system to go unstable.

The simulation only managed to linearized the model at one of the indicated times only (due to the FATAL error).

I wanted to also ask about the content on the .lin files. The output contained .lin from the following inputs: ED (A,B,C,D), HD(D==>zeros), Inflw (D), SvrD(no state mats), summary (about 11k lines with A,B,C,D).

My question are :

• Does the summary file contain all the linearization info I need? or should I also include all other files in the analysis?
• Are they the open or closed loop state matrices?

Thanks in advance, and apologies for asking too much :) Qusay.

----------------------------OUTPUT FROM RUN---------------------------

OpenFAST input file heading: IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform

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 HydroDyn. Setting WaveTMax to 0.0 since WaveMod = 0 WARNING: The random number generator in use differs from the original code provided by NREL. This pRNG uses 8 seeds instead of the 2 in the input file. Reading in WAMIT output with root name "/Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/HydroData/IEA-15-240-RW T-UMaineSemi". Computing radiation impulse response functions and wave diffraction forces. Time: 0 of 110 seconds.

FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will be suppressed. Additional debugging message from SUBROUTINE SmllRotTrans(): 2.275 s

                                                                             Time: 10 of 110 seconds.  Estimated final completion at 19:25:54.                                                                                               Performing linearization 1 at simulation time 10 s. (RotSpeed=7.42 rpm, BldPitch1=1 deg)         

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

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:SetInputs:TwrInfl:getLocalTowerProps:Tower strike.

OpenFAST encountered an error at simulation time 19.35 of 110 seconds. Simulation error level: FATAL ERROR

Aborting OpenFAST.

[jjonkman]

Dear @QusayHawari,

I'm glad you got the IEA 15-MW model upgraded to OpenFAST v3.0.

Just a few comments:

• Generally, the full system matrices (the .lin file rather than the module-level files like .ED.lin) are what you need as the full system matrices represent the full aero-hydro-servo-elastic coupling.
• Presumably by "open loop" or "closed loop" you are referring to a feedback control system rather than aero-hydro-servo-elastic coupling. The linearized model does have closed-loop control if that has been enabled within the linearization (e.g., the simple variable-speed torque controller), but otherwise, the model is open loop.
• It looks like your model is not reaching a steady state condition suitable for linearization; rather, it looks like your model has gone unstable very quickly. I'm not sure why this is, but perhaps it is because you disabled control for the linearization analysis? If you are linearizing an operating wind turbine, I would suggest using TrimCase = 2 (torque) in Region 2 or TrimCase = 3 (pitch) in region 3, together with an appropriate pitch or torque setting, respectively.

Best regards,

[QusayHawari]

Hello,

Thanks for clarifying the state matrices.

Regarding point three,

the input wind speed I assigned in the InflWind input was 15m/s (which is in region 3), so TrimCase was set to 3.

The problem is that TrimCase input is only active if CalcSteady is active, and if CalcSteady is active I cannot obtain the .lin files, because the LinTimes input will be inactive as it require that both Linearize and CalcSteady be True and False, respectively.

I have attached the .fst file I am using.

IEA-15-240-RWT-UMaineSemi.txt

Regards, Qusay.

[jjonkman]

Dear @QusayHawari,

When CalcSteady = True, LinTimes is not used because the linearization times will be computed internally by OpenFAST (after the steady-state solution is reached). I would recommend setting CalcSteady = True.

With CalcSteady = True and TrimCase = 3, you should ensure that a fixed torque is specified in ServoDyn, e.g., as discussed recently in https://github.com/OpenFAST/openfast/issues/812.

Best regards,

[QusayHawari]

Hello,

• From the previous discussion on linearization, I understood that I should set CompHydro and CompMooring to 1 if I include the platform DOFs. So I did that.
• I also set CalcSteady true, with 3 TrimCase.
• In the Servodyn file, I set VsContrl = 1, VS_RtTq = rated 15MW torque, VS_RtGnSp = Vs_Rgn2K = VS_SlPc = 0.001.

I ran the model and I got the following:

OpenFAST input file heading: IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform

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 HydroDyn. Setting WaveTMax to 0.0 since WaveMod = 0 WARNING: The random number generator in use differs from the original code provided by NREL. This pRNG uses 8 seeds instead of the 2 in the input file. Reading in WAMIT output with root name "/Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/HydroData/IEA-15-240-RW T-UMaineSemi". Computing radiation impulse response functions and wave diffraction forces.

Intialization: MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <(-)> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <1> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <2> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <----------------------> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <0.001> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3.0e6> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3.0e5> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <1.0> MAP_WARNING[1]

FAST_InitializeAll:MAP_Init:MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <(-)> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <1> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <2> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <----------------------> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <0.001> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3.0e6> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file. word: <3.0e5> MAP_WARNING[1] : Extra characters are present in the cable library portion of the MAP input file.

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

Aborting OpenFAST.

This seems to be just a warning, so I am not sure why the simulation is FATAL!

Finally, I have a question also related to linearization. Previously I received an error that I should set PCMode to 0 if I want to linearize. Does this mean that no pitch control will be used, which is creating those unstable results?

I have attached the .fst, ServoDyn, HydroDyn, and MoorDyn for you to look at.

Lin_ERROR.zip

Thanks in Advance, Qusay.

[jjonkman]

Dear @QusayHawari,

When there are are as many warnings as you are showing, then the string being written to the screen may not be long enough to show the actual error. But briefly looking at your files, the problem is that you are calling MAP++, but are using a MoorDyn input file. In OpenFAST v3.0, full system linearization functionality is not available when MoorDyn is enabled. So, you'll need to convert your MoorDyn model to MAP++. (NREL is wrapping up work to allow for the linearization of MoorDyn within the full-system linearization capability of OpenFAST; this functionality should be released soon.)

You are correct that the full system linearization functionality of OpenFAST currently requires that PCMode = 0 in ServoDyn. With TrimCase = 3, there is an internal pitch controller that adjusts the pitch to enable the calculation of the steady-state solution, but there is no pitch control logic included within the linearized system matrices.

Best regards,

[QusayHawari]

Hi,

Thanks for the clarification.

I am not sure if what I did is accurate, but based on what you said, I just copy pasted what's in the MAP file in to the Moordyn.

I ran two simulations:

a- NLinTimes = 1 OpenFAST terminated normally (as seen below), but it only simulated the first time step. I think this is related to the bug reported in #857. The simulation generated a .lin file with all state mats, but just at the first time step.

b- NLinTimes >1 Simulation is FATAL due to a high TSR.

I have attached a .txt file containing all the relevant settings I changed from all the input files. If you have time, please double check if they are correct. Those settings remained the same for a, and b except for NLinTimes.

openfast_Inp_Settings.txt

Thanks in Advance, Qusay.

----------------------------RUN A--------------------------

OpenFAST input file heading:

 IEA 15 MW offshore reference model on UMaine VolturnUS-S semi-submersible floating platform

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

Setting WaveTMax to 0.0 since WaveMod = 0 WARNING: The random number generator in use differs from the original code provided by NREL. This pRNG uses 8 seeds instead of the 2 in the input file. Reading in WAMIT output with root name "openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/HydroData/IEA-15-240-RW T-UMaineSemi". Computing radiation impulse response functions and wave diffraction forces. MAP++ (Mooring Analysis Program++) Ver. 1.20.10 Jun-26-2021 MAP Input file section definitions: Line dictionary definitions: -LineType, --User-defined name of line [-]
-Diam, --Line diameter, used to calculate area and line displacement per unit length [m]
-MassDen, --Mass (in air) per unit length [kg/m]
-EA, --Axial stiffness [N] -CB, --Cable/seabed Coulumb friction coefficient [-]
-CIntDamp, --Internal structural damping coefficient [Pa-s]
-Ca, --Cross-flow added-mass coefficient [-] -Cdn, --Cross-flow drag coefficient [-] -Cdt, --Tangent (skin) drag coefficient[-] Node property definitions: -Node, --Node number; first starts at 1 [-] -Type, --Type of node. Must be one of: VESSEL, FIX, CONNECT [-] -X, --Node X position. '#' must prefix CONNECT nodes; constitutes user initial guess [m] -Y, --Node Y position. '#' must prefix CONNECT nodes; constitutes user initial guess [m] -Z, --Node Z position. '#' must prefix CONNECT nodes; constitutes user initial guess [m] -M, --Applied point mass at node [kg] -B, --Applied point buoyancy module at node [m^3] -FX, --Applied X external force at node. '#' must prefix VESSEL and FIX nodes [N] -FY, --Applied Y external force at node. '#' must prefix VESSEL and FIX nodes [N] -FZ, --Applied Z external force at node. '#' must prefix VESSEL and FIX nodes [N] Line property definitions: -Line, --Line number; first starts at 1 [-] -LineType, --Must match property defined in 'Line Dictions'[-] -UnstrLen, --Unstretched line length [m] -NodeAnch, --Anchor node number corresponding to 'Node Property Definitions' section [-] -NodeFair, --Fairlead node number corresponding to 'Node Property Definitions' section [-] -Flags, --User run-time flag; see below [-] Line run-time options definitions Outputs: -gx_pos, --Fairlead position in global X [m] -gy_pos, --Fairlead position in global Y [m] -gx_pos, --Fairlead position in global Z [m] -gx_a_pos, --Anchor position in global X [m] -gy_a_pos, --Anchor position in global Y [m] -gz_a_pos, --Anchor position in global Z [m] -gx_force, --Fairlead force in global X (include applied forces) [N] -gy_force, --Fairlead force in global Y (include applied forces) [N] -gz_force, --Fairlead force in global Z (include applied forces) [N] -h_fair, --Horizontal force at fairlead (does NOT include applied forces) [N] -v_fair, --Vertical force at fairlead (does NOT include applied forces) [N] -h_anch, --Horizontal force at anchor (does NOT include applied forces) [N] -v_anch, --Vertical force at anchor (does NOT include applied forces) [N] -tension_fair, --Line force-magnitude at fairlead (include applied loads) [N] -tension_anch, --Line force-magnitude at anchor (include applied loads) [N] -azimuth, --Line lateral offset angle global X axis [deg] -altitude, --Line inclination angle relative to global XY plane at fairlead [deg] -lay_length, --Length of line on seabed [m] -line_tension, -- Model features: -omit_contact, --Ignore cable/seabed contact -seg_size <10>, --Number of discrete lines in line -damage_time , --Line breakage occurs at specified time [s] -diagnostic , --Run line solver diagnostics until specified time [s] is reached Model option definitions General model features: -ref_position <0.0> <0.0> <0.0> -repeat ... MSQS solver options: -inner_ftol , -inner_gtol , -inner_xtol , -inner_max_its , -outer_tol , -outer_max_its , -outer_epsilon , -outer_bd, -outer_cd, -outer_fd, -pg_cooked <1000.0> <1.0>, -krylov_accelerator <3>, -integration_dt <0.01>, LM model feature (not suported yet): -kb_default --Seabed stiffness parameter -cb_default --Seabed damping parameter -wave_kinematics --Enables wave kinematics to drag interaction from surface waves -lm_model --Enable the lumped-mass model MAP++ Copyright (C) 2014 and Apache'd by Marco Masciola and others SimCList Copyright (C) 2010 by Mij http://mij.oltrelinux.com/devel/simclist/ MinPack Copyright (C) 1999 by the University of Chicago Modifications to MinPack by Frederic Devernay http://devernay.free.fr/hacks/cminpack/ MAP++ is free software; see the source for copying conditions. This software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See http://www.apache.org/licenses/LICENSE-2.0 forr more details. MAP++ environment properties (set externally)... Gravity constant [m/s^2] : 9.81 Sea density [kg/m^3] : 1025.00 Water depth [m] : 200.00 Vessel reference position [m] : 0.00 , 0.00 , 0.00 Time: 0 of 30 seconds. Performing linearization 1 at simulation time 2.50000E-02 s. (RotSpeed=7.56 rpm, BldPitch1=11.5 deg)

Total Real Time: 9.223 seconds Total CPU Time: 46.322 seconds Simulation CPU Time: 46.168 seconds Simulated Time: 2.50000E-02 seconds Time Ratio (Sim/CPU): 5.41496E-04

OpenFAST terminated normally.

--------------------------RUN B-------------------------- . . . FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_AB4:ED_RK4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will be suppressed. Additional debugging message from SUBROUTINE SmllRotTrans(): 7.50000E-02 s FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates:UpdatePhi(node 3, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx = 1.0202, Vy = -963.33, rlocal = 7.6641, theta = 0.46933, geometric phi = 3.1405. This warning will not be repeated though the condition may persist. (See GeomPhi output channel.) time 0.100000 Calc_output: MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 1. MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 2. MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 3. MAP_FATAL[88] : Line failed. FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:MAP_CalcOutput:MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 1. MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 2. MAP_FATAL[40] : Number of function calls has reached or exceeded INNER_MAX_ITS. Line segment 3. MAP_FATAL[88] : Line failed. OpenFAST encountered an error at simulation time 7.50000E-02 of 30 seconds.

Simulation error level: FATAL ERROR Aborting OpenFAST.

[jjonkman]

Dear @QusayHawari,

I agree that there is a bug associated with NLinTimes = 1 as reported in https://github.com/OpenFAST/openfast/issues/857. But I would generally recommend against setting NLinTimes = 1 when the rotor is rotating anyway.

For you simulation where NLinTimes > 1, I see that you've set GenTiStr = True with TimGenOn = 1, so, the the torque you've set will not be applied until after the simulation already crashes. Does the simulation run properly when TimGenOn = 0.0 s?

Best regards,

[QusayHawari]

Hi,

Thank you for the quick reply,

I Changed TimGenOn to 0.0s, but unfortunately the simulation crashes again. It occurred at a different time (5e-2 s), and due to a low TSR.

Does it have to do with the following changes (in .fst)?

0.455456 TrimGain
0.05 Twr_Kdmp 0.5 Bld_Kdmp

I was not sure what is meant by damping of the tower. Is it the damping for the tower mode? if so is is for the side-side, or fore-aft? similarly for the blade? I just set the damping to be low for the tower, and 50% for the blade. Finally, for TrimGain, I just used the proportional gain factor from the DISCON.IN file at my input wind speed.

Time: 0 of 30 seconds. The BEM solution is being turned off due to low TSR. (TSR = -42.003). This warning will not be repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates:UpdatePhi(node 5, blade 1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx = 13.13, Vy = -311.93, rlocal = 12.337, theta = 0.45069, geometric phi = 3.0995. This warning will not be repeated though the condition may persist. (See GeomPhi output channel.)

FAST_Linearize_T:FAST_CalcSteady:The rotor is spinning too fast. The time step or NLinTimes is too large when CalcSteady=true.

OpenFAST encountered an error at simulation time 5.00000E-02 of 30 seconds. Simulation error level: FATAL ERROR

Thanks, Qusay.

[jjonkman]

Dear @QusayHawari,

Twr_Kdmp and Bld_Kdmp are tower and blade dampings added to all DOFs of the tower and blades within the steady-state solve on top of other intrinsic damping these DOFs may have (from structural or aerodynamic damping) to help speed up the steady-state solve; they have units of N/(m/s) rather than modal damping ratios. Setting these to unrealistic values can drive the model unstable; so, I would recommend setting them to zero, at least to start with.

For TrimCase = 3, TrimGain is the gain in the proportional pitch controller used within the steady-state solve. It should have the units of rad/(rad/s), i.e., change in pitch angle in rad associated with the change in rotor speed in rad/s.

Best regards,

[QusayHawari]

Hi,

There is something strange with DT in the main .fst file. I tried reducing it, and simulation crashed at later times, for example, the following.

0.025s : System ran to 0.025s. 0.0025s : System ran to 1.9125s. 0.001s: System ran to 3.79. 0.0001s: System ran to 4.2052s.

I will keep working on it, and let you know!

Thanks, Qusay.

[jjonkman]

Dear @QusayHawari,

If the time step is having a strong effect on the solution, it sounds like your model is numerically unstable. Are you simulating with Twr_Kdmp = Bld_Kdmp = 0 as I recommended?

Can you run a standard time-domain simulation (with controller enabled) rather than a steady-state solution with the original time step? If so, what exactly do you change between the simulation that runs and the steady-state solve that crashes?

Best regards,

[QusayHawari]

Hi,

I changed PCMode to 5, set linearize, and CalSteady to false, and increased DT to its original value of 0.025s.

The problem is that the libdiscon.so file is for 32-bit. Is there a 64-bit release. otherwise I can use pitch.ipt input file?

Thanks, Qusay.

[jjonkman]

Dear @QusayHawari,

The IEA Wind 15-MW reference wind turbine should be simulated using the ROSCO controller (rather than the old sample pitch controller that relies on a pitch.ipt input file.) To make full use of this controller, you should also set VSContrl = 5.

I don't use Mac/Linux, but I'm surprised the provided *.so file for the ROSCO controller is 32-bit. Perhaps you can find the 64-bit version on the ROSCO github site: https://github.com/NREL/ROSCO? Otherwise, I'd post your question there.

Best regards,

[rafmudaf]

@QusayHawari could you share the error message you encountered? How did you determine you are using a 32-bit version of the DISCON controller?

[QusayHawari]

Hi,

I was using .so instead of the .dylib on MAC :)

Thanks

[rafmudaf]

Ok, and then OpenFAST was giving you the error about either the controller being 32 bit or that the path is not found?

[QusayHawari]

Hi,

OpenFAST was giving either file not found or is for a 32-bit applications shown in the message below:

FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library /Users/qusayhawari/Downloads/openfast_IEA_15MW/IEA-15-240-RWT-UMaineSemi/ServoData/libdiscon.so could not be loaded. Check that the file exists in the specified location and that it is compiled for 64-bit applications.

I asked the ROSCO team about it, and they directed me to the .dylib file :) Still dealing with some numerical instability issues due to a low TSR!

Regards, Qusay

[rafmudaf]

Got it. And is it correct that the fix for this problem was to double check the file path for the controller library and change it use the correct extension for the controller on your system?

(I'm clarifying for the reference of any future readers)

[QusayHawari]

Yes exactly.

It was not clear from the ServoDyn file that there was a .dylib. The comment on the DLL_FileName specified that there is either .dll or .so. I thought the only way was to generate it yourself. Now it's clear.

Qusay

[rafmudaf]

Ah good to know, thanks for the additional information.