Dear ROSCO team,

first of all thanks a lot for your work!
I am trying to run your examples on mac but I am having some issues at the interface with openfast. More specifically example_06.py fails with the following output:

Using ofTools in ROSCO_toolbox...
-----------------------------------------------------------------------------
Loading wind turbine data for NREL's ROSCO tuning and simulation processeses
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
   Tuning a reference wind turbine controller using NREL's ROSCO toolbox    
-----------------------------------------------------------------------------
Loading FAST model: IEA-15-240-RWT-UMaineSemi.fst 
Loading rotor performace data from text file: /Users/claudio/repositories-git/wind-turbine-DRC/ROSCO/Test_Cases/IEA-15-240-RWT-UMaineSemi/Cp_Ct_Cq.IEA15MW.txt
Loading rotor performace data from text file: /Users/claudio/repositories-git/wind-turbine-DRC/ROSCO/Examples/../Test_Cases/IEA-15-240-RWT-UMaineSemi/Cp_Ct_Cq.IEA15MW.txt
-----------------------------------------------------------------------------
   Tuning a reference wind turbine controller using NREL's ROSCO toolbox    
-----------------------------------------------------------------------------
Writing new controller parameter file parameter file: /Users/claudio/repositories-git/wind-turbine-DRC/ROSCO/Examples/DISCON.IN.
Using IEA-15-240-RWT-UMaineSemi.fst to run OpenFAST simulation
Running OpenFAST simulation for IEA-15-240-RWT-UMaineSemi.fst through the ROSCO toolbox...

 **************************************************************************************************
 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: 01/14/2022
  - Time: 18:04:36+0100

 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.
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 1)
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 1)
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 2)
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 2)
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 1, blade 3)
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. (node 2, blade 3)
 Running InflowWind.
 Running ServoDyn.
 Running ServoDyn Interface for Bladed Controllers (using GNU Fortran for Linux, ).

 FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library
 ./../../ROSCO/install/lib/libdiscon.so could not be loaded. Check that the file exists in the
 specified location and that it is compiled for 64-bit applications.

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

  Aborting OpenFAST.

Traceback (most recent call last):
  File "/Users/claudio/repositories-git/wind-turbine-DRC/ROSCO/Examples/example_06.py", line 87, in <module>
    run_openfast(
  File "/Users/claudio/repositories-git/wind-turbine-DRC/ROSCO/ROSCO_toolbox/utilities.py", line 493, in run_openfast
    subprocess.run([fastcall, os.path.join(fastfile)], check=True, cwd=cwd)
  File "/usr/local/Cellar/[email protected]/3.9.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['openfast', 'IEA-15-240-RWT-UMaineSemi.fst']' returned non-zero exit status 1.

It seems to me that openfast looks for the libdiscon.so instead of libdiscon.dylib (as that is the output of the ROSCO build on mac that I obtained following these instructions: https://rosco.readthedocs.io/en/latest/source/install.html?highlight=build#compile-using-cmake)

I managed to get it to run by changing the file extension on this line. It then runs but I will get a number of warnings and it complains that the fairlead tesions did not converge. This is the output (omitted the first part as it is the same as above):

Running ServoDyn Interface for Bladed Controllers (using GNU Fortran for Linux, ).
 Using legacy Bladed DLL interface.
 Running HydroDyn.
   Setting WaveTMax to 0.0 since WaveMod = 0
  WARNING:  The requested output channel is invalid: WavesF1xi
  WARNING:  The requested output channel is invalid: WavesF1zi
  WARNING:  The requested output channel is invalid: WavesM1yi
  WARNING:  The requested output channel is invalid: WavesF2xi
  WARNING:  The requested output channel is invalid: WavesF2zi
  WARNING:  The requested output channel is invalid: WavesM2yi
  WARNING:  The requested output channel is invalid: WavesF2xi
  WARNING:  The requested output channel is invalid: WavesF2yi
  WARNING:  The requested output channel is invalid: WavesF2zi
  WARNING:  The requested output channel is invalid: WavesM2xi
  WARNING:  The requested output channel is invalid: WavesM2yi
  WARNING:  The requested output channel is invalid: WavesM2zi
  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.
  Calculating second order difference frequency wave kinematics.
  Reading in WAMIT output with root name "./HydroData/IEA-15-240-RWT-UMaineSemi".
  Computing radiation impulse response functions and wave diffraction forces.
  Calculating second order difference-frequency force using the full quadratic transfer function.
 Running MoorDyn (v1.01.02F, 8-Apr-2016).
   MD_Init: Opening MoorDyn input file:  ./IEA-15-240-RWT-UMaineSemi_MoorDyn.dat
 Warning: invalid output specifier FX.  Starting character must be C or L.
 Warning: invalid output specifier FY.  Starting character must be C or L.
 Warning: invalid output specifier FZ.  Starting character must be C or L.
   Creating mooring system.   3 fairleads, 3 anchors, 0 connects.
    Finalizing ICs using dynamic relaxation.

   t=60  FairTen 1: 2.76325E+06, 2.75740E+06, 2.76559E+06                                             Fairlead tensions did not converge within TMaxIC=60 seconds.

 FAST_InitializeAll:HydroDyn_Init:HydroDynInput_ProcessInitData: A requested output channel is
 invalid

  Time: 0 of 150 seconds.
                                                                               
------------------------------------------------------------------------------
Running ROSCO-v2.4.1
A wind turbine controller framework for public use in the scientific field    
Developed in collaboration: National Renewable Energy Laboratory              
                            Delft University of Technology, The Netherlands   
------------------------------------------------------------------------------

 FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:RotCalcOutput:BEMT_CalcOutput(node 3,
 blade 1):UA_CalcOutput:UA_BlendSteady:Temporarily turning off UA due to high angle of attack or
 low relative velocity. This warning will not be repeated though the condition may persist.

Generator speed:    6.9 RPM, Pitch angle:   1.7 deg, Power: 10088.6 kW, Est. wind Speed:   9.3 m/s
 Time: 10 of 150 seconds.  Estimated final completion at 18:11:60.                                Generator speed:    6.6 RPM, Pitch angle:   1.6 deg, Power: 11089.4 kW, Est. wind Speed:   9.6 m/s
 Time: 20 of 150 seconds.  Estimated final completion at 18:11:59.                                Generator speed:    6.7 RPM, Pitch angle:   1.0 deg, Power: 10054.9 kW, Est. wind Speed:   9.5 m/s
 Time: 30 of 150 seconds.  Estimated final completion at 18:11:59.                                Generator speed:    6.5 RPM, Pitch angle:   1.2 deg, Power: 10563.5 kW, Est. wind Speed:   9.3 m/s
 Time: 40 of 150 seconds.  Estimated final completion at 18:11:59.                                Generator speed:    6.7 RPM, Pitch angle:   1.0 deg, Power: 10796.7 kW, Est. wind Speed:   9.8 m/s
 Time: 50 of 150 seconds.  Estimated final completion at 18:11:59.                                Generator speed:    6.9 RPM, Pitch angle:   1.7 deg, Power: 11537.7 kW, Est. wind Speed:   9.8 m/s
 Time: 60 of 150 seconds.  Estimated final completion at 18:11:60.                                Generator speed:    7.1 RPM, Pitch angle:   2.2 deg, Power: 12213.9 kW, Est. wind Speed:  10.2 m/s
 Time: 70 of 150 seconds.  Estimated final completion at 18:11:60.                                Generator speed:    7.2 RPM, Pitch angle:   2.6 deg, Power: 12440.2 kW, Est. wind Speed:  10.3 m/s
 Time: 80 of 150 seconds.  Estimated final completion at 18:11:60.                                Generator speed:    7.2 RPM, Pitch angle:   2.6 deg, Power: 12382.5 kW, Est. wind Speed:  10.2 m/s
 Time: 90 of 150 seconds.  Estimated final completion at 18:11:60.                                Generator speed:    7.1 RPM, Pitch angle:   2.2 deg, Power: 12115.4 kW, Est. wind Speed:  10.1 m/s
 Time: 100 of 150 seconds.  Estimated final completion at 18:11:60.                               Generator speed:    7.0 RPM, Pitch angle:   1.8 deg, Power: 11778.1 kW, Est. wind Speed:   9.9 m/s
 Time: 110 of 150 seconds.  Estimated final completion at 18:11:60.                               Generator speed:    6.9 RPM, Pitch angle:   1.2 deg, Power: 11372.0 kW, Est. wind Speed:   9.8 m/s
 Time: 120 of 150 seconds.  Estimated final completion at 18:11:60.                               Generator speed:    6.8 RPM, Pitch angle:   0.7 deg, Power: 11109.5 kW, Est. wind Speed:   9.6 m/s
 Time: 130 of 150 seconds.  Estimated final completion at 18:11:60.                               Generator speed:    6.9 RPM, Pitch angle:   0.6 deg, Power: 11080.0 kW, Est. wind Speed:   9.7 m/s
 Time: 140 of 150 seconds.  Estimated final completion at 18:11:60.                               Generator speed:    6.9 RPM, Pitch angle:   0.7 deg, Power: 11229.4 kW, Est. wind Speed:   9.7 m/s
                                                                                                  
  Total Real Time:       46.223 seconds
  Total CPU Time:        45.32 seconds
  Simulation CPU Time:   42.487 seconds
  Simulated Time:        150 seconds
  Time Ratio (Sim/CPU):  3.5305

  OpenFAST terminated normally.

OpenFAST simulation complete.

thanks a lot in advance for the help!
Claudio

Hi,

I'm trying to create a Bladed version of the IEA 15MW turbine to share on the IEA 15MW repository. I'm really struggling to create a .dll of the controller though - Bladed requires a 32bit version of the DISCON.dll file.

I've managed to successfully compile a libdiscon.so file, but I think Bladed needs a dll (it's throwing an error saying the controller has a divide by zero error).

What do I need to edit to get the compiler to spit out a dll instead of .so? I can't actually find where the compiler is being called to change the output type.

Thanks,

Pete

When I load parameters, OL_RAAW cannot be found.

Hello,

We have witnessed issues with the functions truncating precision as they are declared REAL rather than REAL(8), in particular PIController and Saturate clip the values of GenA/BrTq. This causes issues with VS_State being incorrectly set when saturation/clipping occurs. We also saw that perhaps an attempt at fixing this issue was associated with a hardcoded 1.01 multiplicative factor.
I would recommend using ReKi as for the remainder of OpenFAST, as mentioned earlier on the topic of hard-coded constants, to keep all variables and functions consistent; however. I managed to get things to work with REAL(8) in the function declaration.
Best,
Rick

If I want to run this test on Windows, which DLL do I need?
I am currently using the release version of Discon. DLL provided by OpenFast, which can be run. However, the BTS turbulent wind file generated by myself has the following error when running. Is it because of the controller?

This is my .inp file:

Hello developers,
So I was trying to use the reading and writing capabilities of fast-io in ROSCO toolbox. I ran into an issue with the method write_ServoDyn in FAST_writer.py, specifically when writing input data under - STRUCTURAL CONTROL - section. The issue was with writing StC file names. For example:

Intended output for line 67 in ServoDyn input file:
"unused" BStCfiles - Name of the files for blade structural controllers (quoted strings) [unused when NumBStC==0]
actual output using write_ServoDyn:
"u" "n" "u" "s" "e" "d" BStCfiles - Name of the files for blade structural controllers (quoted strings) [unused when NumBStC==0]

I fixed the issue in my forked version by changing lines 1296, 1298,1300, and 1302 in FAST_writer.py as follows:

Old:
f.write('{!s:<22} {:<11} {:}'.format('"' + '" "'.join(self.fst_vt['ServoDyn'] ...
New:
f.write('{!s:<22} {:<11} {:}'.format('"' + ''.join(self.fst_vt['ServoDyn'] ...

To replicate the error using a simple python script:

import os
from ROSCO_toolbox.ofTools.fast_io.FAST_reader import InputReader_OpenFAST
from ROSCO_toolbox.ofTools.fast_io.FAST_writer import InputWriter_OpenFAST 

this_dir = os.path.dirname(os.path.abspath(__file__))

fast = InputReader_OpenFAST(FAST_ver='OpenFAST')

fast.FAST_InputFile = 'IEA-15-240-RWT-UMaineSemi.fst'  # FAST input file (ext=.fst)
fast.FAST_directory = os.path.join(this_dir,'../Test_Cases/IEA-15-240-RWT-UMaineSemi') # FAST directory

fast.read_ServoDyn()

fastout = InputWriter_OpenFAST(FAST_ver='OpenFAST')
fastout.fst_vt = fast.fst_vt

fastout.write_ServoDyn()

I hope this helps.
Best

Containment issue for erros/bugs in documentation.

Bugs related to the documentation, it felt like creating individual issues for each one would be bloating the repo

F_NotchType > 2 is not allowed

Docs say values 0-3 are accepted

When F_NotchType = 1, ROSCO exits with error

When F_NotchType = 1, Fl_Mode = 1, F_NotchCornerFreq=3.24210, ROSCO exits with error:

F_NotchType and F_NotchCornerFreq must be specified for Fl_Mode greater than zero.

This does not happen if F_NotchType = 2.

PS_Mode > 1 will exit ROSCO

Docs say values 0-3 are accepted

'F_FlpCornerFreq must be greater than zero' when FL_Mode = 0

From #72

Hello,

I am new to using the ROSCO controller on FAST. And I encountered the following runtime error while running OpenFAST using ROSCO generated DISCON.IN and libdiscon.dll. I followed all steps in the Standard ROSCO Workflow, and properly point the Cp_Cq_Ct.txt file in the DISCON.IN.

At line 400 of file C:\Users\Yisehak\ROSCO\ROSCO\src\ReadSetParameters.f90 (unit = 89)
Fortran runtime error: Cannot open file 'Cp_Ct_Cq.DTU10MW.txt': No such file or directory

Would you please help me in resolving this issue?

Yisehak A.

In the develop branch, when using the Kalman wind estimator, the estimated wind speed equals to Nan.

This behavior does not exist in the master branch.

Hi,
I need some help for running the example files, when I start to run, it showed this erro:
ModuleNotFoundError: No module named 'wisdem.inputs'
What should I do? I have already installed wisdem in conda install, it shows:
(rosco-env) D:\ROSCO>conda install -y wisdem
Collecting package metadata (current_repodata.json): done
Solving environment: done

All requested packages already installed.

Thanks.

In order to make a Windows DLL with just a single exported function DISCON I think you need to use a .def file. I included the following file:

LIBRARY libdiscon.dll

EXPORTS
    DISCON = DISCON

which does the trick. I added it to the list of source files in CMakeLists.txt and the subsequent build had the desired export table. But I know absolutely nothing about CMake and probably this is the wrong way to do it!

Having this baked in to the repo would be helpful.

First: thanks for the setup.py option to compile the discon controller -- I think it's an extremely useful and quite elegant solution to helpng end-uders update, compile and test ROSCO.

The cmake package is not installed with the toolbox, so following the instructions on the docs will unfortunatley result in an error: command 'cmake' failed: No such file or directory.

I'll happily make an MR to put cmake as a dependency, but my question is do you want it as a required dependency, or an extra? I would say required makes the most sense, but I defer to you.

As the title says, despite what controller binary I use, if I use VS_ControlMode to either 2 or 3, the simulation fails after approximately 2 minutes of simulated time with the following errors:

However, if I set VS_ControlMode to 0 or 1, I have been able to simulate up to 3 hours without even the "mach > 0.3" warnings.

I'm unsure if this is caused by the platform model itself, ROSCO or openFAST, but I don't understand why this only happens when VS_ControlMode > 1

This happens with all binaries i've tried (downloaded v2.3.0, Visual Studio + ifort, mingw32 64 bit)

I'm unsure if this bug comes from ROSCO or WISDEM.

I created a new venv to isolate the issue.

If i follow all the installation steps from the docs and run certain tools from the toolbox, I get the following warning:

Using ofTools in ROSCO_toolbox...
WARNING: Be sure to pip install simpy and marmot-agents for offshore BOS runs

If I then run pip install marmot-agents and simpy, I get the following warning:

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
wisdem 3.3.0 requires pyside2, which is not installed

Lastly, if I pip install pyside2 (which also installs shiboken2 as a dependency), it breaks the venv. Any time I try to run any script I get the following output:

python .\example_04.py
PySide2/__init__.py: Unable to import shiboken2 from C:\Users\gus_h\Documents\GitHub\EnerOcean\ROSCO\Examples, C:\Users\gus_h\miniconda3\envs\rosco-env3\python38.zip, C:\Users\gus_h\miniconda3\envs\rosco-env3\DLLs, C:\Users\gus_h\miniconda3\envs\rosco-env3\lib, C:\Users\gus_h\miniconda3\envs\rosco-env3, C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages, C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\rosco-2.4.0-py3.8.egg, C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\future-0.18.2-py3.8.egg
Traceback (most recent call last):
  File ".\example_04.py", line 14, in <module>
    import matplotlib.pyplot as plt
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\pyplot.py", line 2500, in <module>
    switch_backend(rcParams["backend"])
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\__init__.py", line 621, in __getitem__
    plt.switch_backend(rcsetup._auto_backend_sentinel)
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\pyplot.py", line 257, in switch_backend
    switch_backend(candidate)
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\pyplot.py", line 277, in switch_backend
    class backend_mod(matplotlib.backend_bases._Backend):
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\pyplot.py", line 278, in backend_mod
    locals().update(vars(importlib.import_module(backend_name)))
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\backends\backend_qt5agg.py", line 11, in <module>
    from .backend_qt5 import (
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\backends\backend_qt5.py", line 13, in <module>
    import matplotlib.backends.qt_editor.figureoptions as figureoptions
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\backends\qt_editor\figureoptions.py", line 11, in <module>
    from matplotlib.backends.qt_compat import QtGui
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\backends\qt_compat.py", line 174, in <module>
    _setup()
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\matplotlib\backends\qt_compat.py", line 87, in _setup_pyqt5
    from PySide2 import QtCore, QtGui, QtWidgets, __version__
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\PySide2\__init__.py", line 107, in <module>
    _setupQtDirectories()
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\PySide2\__init__.py", line 58, in _setupQtDirectories
    import shiboken2
  File "C:\Users\gus_h\miniconda3\envs\rosco-env3\lib\site-packages\shiboken2\__init__.py", line 30, in <module>
    _init_pyside_extension()
NameError: name '_init_pyside_extension' is not defined

As I stated at the start, I don't know if this comes from WISDEM or if it comes from ROSCO. I also don't know what "offshore BOS" means. Do i need those venv-breaking packages if I want to use FOWT platforms with ROSCO_toolbox?

Hi everyone, I encountered this error but I cannot find the file in my computer...how can I fix it? Thanks

At line 77 of file D:\bld\rosco_1615353392809\work\src\ReadSetParameters.f90
Fortran runtime error: Attempting to allocate already allocated variable 'cntrpar'

I have not the D unit on my computer and I don't know how to find this file to fix the problem...what can I do?
Thanks a lot

Dear all,
When I run 5MW_Land_Simulink.fst in the file " ROSCO-main\Test_Cases\5MW_Land_Simulink", it often occures fatal errors like "Invalid numerical input" or "Invalid logical input". I dout if the ROSCO_2.4 only refers to OPENFAST_2.4？ Because I use OPENFAST_3.1 but I only find the latest version ROSCO_2.4 on this web.

I'm trying to run example 04 to tune a controller to a platform:
(I had a pre-existing conda env "rosco-env" from the now old ROSCO_toolbox repo)

1. I activate rosco-env

2. I navigate to the new ROSCO dir and run python run_setup.py install, exits with no errors

3. I go to /Examples and run example_04.py

4. I get the following error:

File ".\example_04.py", line 20, in <module>
from ROSCO_toolbox.inputs.validation import load_rosco_yaml
ModuleNotFoundError: No module named 'ROSCO_toolbox.inputs'

I am trying to compile the ROSCO controller on Windows 10 x64 with the following tools:

• CMake GUI
• MinGW-w64
• the modified CMakeLists.txt file #8 (it would be nice to merge the commit so that other users can access this file from the master branch)

However, I am getting the following error when running the compiled DLL in OpenFAST:
FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library ..\..\ROSCO\build\libdiscon.dll could not be loaded. Check that the file exists in the specified location and that it is compiled for 64-bit applications.

Do you know how to resolve this issue ?

FYI, compiling ROSCO on UNIX systems is extremely easy but rather tedious on Windows, even when using Anaconda and the ROSCO toolbox.

I've been trying to build on Windows, which was a bit of a struggle. I am using mingw-w64 under the MSYS2 system which is pretty slick.

However, the CMakeLists.txt file in the repo doesn't have settings for this environment. I found that I needed to set CMAKE_Fortran_FLAGS like this to achieve a successful build:

set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -DIMPLICIT_DLLEXPORT -ffree-line-length-0 -static-libgcc -static-libgfortran -static")

It would be nice if you could amend CMakeLists.txt to include this, to make it easier for Windows users to build.

By the way, when I followed the build instructions, make install failed because the make file has no install target.

Some recent changes in ROSCO seem to have broken it for use with the IEA15MW model. The control is highly unstable around rated wind speed – continuously oscillating between 6 & 15MW. Example plot below.

We have tried with Bladed, HAWC2 and FAST, and using both ROSCO pre-built dlls downloaded from this github project and building the source ourselves. We see the instability with ROSCO version 2.2.0 & 2.3.0, but not with version 2.0.3. We’re using the same DISCON.IN and Cp_Ct_Cq.IEA15MW.txt text in all cases – exactly what is supplied for IEA15MW in the ROSCO source code package.

Does this work for other people? I can’t see what we could be doing wrong.

Thanks,
Will

Dear Rosco team,

Thank you so much for your contribution to the open source wind industry knowledged.

I try to compile ROSCO in 32 bits for use with bladed but I didn't managed at the moment.
I try with your Cmake+MINGW32 procedure and also with IVF.
I managed to compile with IVF but then Bladed crash when using it.

Would it be possible that you share a 32bits compile version of your libdiscon.dll ? I could then see if my errors are during the compilation process or when I try to implement the .dll in Bladed.

Best regards,

Cyril

I am trying to use ROSCO for the IEA 15MW semisubmersible case with openfast v2.4.0 with the restart option after the checkpoint file is generated in the first run. I found openfast is aborting due to some segmentation fault arising in ROSCO code (see below). I think there may be some memory problem with the "interp1d" function inside the Functions.f90. I have used the latest code (17 Nov 2020) from ROSCO repo on GitHub. can you please help me fix this issue?

OpenFAST

Copyright (C) 2020 National Renewable Energy Laboratory
Copyright (C) 2020 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-v2.4.0
Compile Info:

• Compiler: GCC version 7.1.0
• Architecture: 64 bit
• Precision: double
• Date: Nov 17 2020
• Time: 10:04:53
  Execution Info:
• Date: 11/17/2020
• Time: 17:16:07+0530

Restarting simulation at 5 seconds.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7ff66cac92ef in ???
#1 0x7ff66c18fa87 in __functions_MOD_interp1d
at /soft/opensoft/ROSCO/src/Functions.f90:170
#2 0x7ff66c18d63c in __controllers_MOD_pitchcontrol
at /soft/opensoft/ROSCO/src/Controllers.f90:63
#3 0x7ff66c18dce5 in DISCON
at /soft/opensoft/ROSCO/src/DISCON.F90:74
#4 0x1099c06 in ???
#5 0x1099cd3 in ???
#6 0x1099f60 in ???
#7 0x109b958 in ???
#8 0x10a357b in ???
#9 0x8706b5 in ???
#10 0x5892c7 in ???
#11 0x58abdc in ???
#12 0x524686 in ???
#13 0x4162fe in ???
#14 0x7ff66cab5444 in ???
#15 0x41632e in ???
#16 0xffffffffffffffff in ???
Segmentation fault (core dumped)

When I using the 'runFAST.m' to run openfast_simulink, it appears "WARNING: no outputs found in OutList", and
" The expression: u(strmatch('Azimuth',OutList))
in 'ROSCO/Cyclic Pitch controller/extract Azimuth'
has a syntax error"
I don't know how to fix this, and I'd like to get your help. Thanks!
Best regards.

Hi,

The nacelle yaw controller currently does not account for the platform yaw in case of floating wind turbines.

In the older version with the ROSCO_toolbox repo. When the floating platform yawed, the nacelle was considered also yawed and the yaw controller was activated to force the nacelle to face the wind.

In the current version, the controller starts working only when the nacelle is yawed relative to the tower reference frame, and not relative to the fixed (inertial) reference frame.
For floating, when this is not considered this means there are cases where there will be constant yaw misalignment.

I was using the ROSCO_toolbox earlier, but I had problems understanding what the fast and slow low pass filters meant, and how to set them.

I hope my issue is clear, and thanks a lot for guiding me to this repo and answering my question earlier.

Best regards,
Youssef

Hi, Experts:
I am currently learning Rosco, I think I have installed Rosco successfully and run the example in 'standard_use. RST', the 4 examples from 01-04 are running with no problem, but when running 'example_05.py' I get an error like this:

Using ofTools in ROSCO_toolbox...
WARNING: Be sure to pip install simpy and marmot-agents for offshore BOS runs
Loading FAST model: NREL-5MW.fst
Loading rotor performace data from text file: D:\z各种资料\小工具汇总\ROSCO-main2022-2.5.0\ROSCO-main\Test_Cases\NREL-5MW\Cp_Ct_Cq.NREL5MW.txt
Loading rotor performace data from text file: D:\z各种资料\小工具汇总\ROSCO-main2022-2.5.0\ROSCO-main\Examples../Tune_Cases../Test_Cases/NREL-5MW/Cp_Ct_Cq.NREL5MW.txt

Tuning a reference wind turbine controller using NREL's ROSCO toolbox

Writing new controller parameter file parameter file: D:\z各种资料\小工具汇总\ROSCO-main2022-2.5.0\ROSCO-main\Examples\DISCON.IN.
Backend TkAgg is interactive backend. Turning interactive mode on.
-------------- Turbine Info --------------
Turbine Name: NREL-5MW
Rated Power: 5000000.0 [W]
Total Inertia: 43702538.1 [kg m^2]
Rotor Radius: 63.0 [m]
Rated Rotor Speed: 1.3 [rad/s]
Max Cp: 0.47

Running ROSCO-v2.5.0
A wind turbine controller framework for public use in the scientific field
Developed in collaboration: National Renewable Energy Laboratory
Delft University of Technology, The Netherlands

At line 227 of file C:\Windows\System32\ROSCO\ROSCO\src\ReadSetParameters.f90 (unit = 89)
Fortran runtime error: Cannot open file 'D:\z各种资料\小工具汇总\ROSCO-main2022-2.5.0\ROSCO-main': No such file or directory

I do not have any clue about this mistake, I hope you can help me find out what is the reason. Thanks.

Regards.

Hello,

I found that input variables for the controller (DISCON-UMaineSemi.IN) were changed when I compared the version on 4/20/21 with on 06/20/21. Do you have any background for this revision? Should I go with the newest version? Or, is the old version okay?

Best regards,
Chungkuk Jin

Hi all,

I have been using ROSCO v2.4.1 for a while, and tried to install the latest version. Following the docs, I have done two little workarounds that may be useful (or require minor code fixing).

The first one has been mentioned in some conversations (#121).
conda install -y wisdem seems to install an older version of wisdem, and conda install wisdem=3.5.0 seems to fix this.

The second, as far as I know, is not known.
python setup.py install --compile-rosco raises an error, being the most relevant information:

File "setup.py", line 92, in build_extension if "gfortran" in os.environ["FC"].lower(): File "C:\Users\Pablo\miniconda3\envs\env_rosco\lib\os.py", line 675, in getitem raise KeyError(key) from None KeyError: 'FC'

For me, declaring the env variable inside the conda env to "gfortran" solved the issue

To set environment variables, run conda env config vars set my_var=value

I hope this is useful!

Hi,

A user of pyDatView sent me a ".dbg" output file, where some units were missing.
The columns with missing units were:
axisTilt_1P axisYaw_1P axisTilt_2P axisYaw_2P YawState
I've fixed the reader of pyDatView to support missing units, but I think it might be nicer if units are always present (e.g. [NA] or [-]).

Sorry if that's already been fixed.

Cheers!

Dear all,

I am using ROSCO to control a wind turbine model, that is similar to the IEA 15 MW. I have a strange behavior in using TSR tracking control (VS_ControlMode = 2). In particular, in the correspondence of the wind step, I have a large decrease of the generator torque, that goes almost to zero for like 20 seconds, than the torque signal goes to reasonable values. I don't have this problem when using k-w^2 control logic in below rated operations. I am not using the EKF wind estimator but just a filtered wind speed estimate.
Is this problem related to the controller or to the turbine model? Do you have any suggestion to solve it?
In the figure below i report generator speed and torque for the two cases.

Thank you
Elio

Dear ROSCO developers,

I've been looking through your fortran code and have found there's a small discrepancy between what's in the code and what's stated in the WES paper (A reference open-source controller for fixed and floating offshore wind turbines). The specific function is PIController in Functions.f90.

In the paper, the integral gain is outside of the error integration as in the following equation:

However, in the code, the integral gain has been effectively placed inside of the error integration, as in this equation:

Note that in this equation I quoted the integral gain as a function of pitch angle (beta).

This doesn't make a difference for when the integral gain is constant, but with gain scheduling this makes a noticeable difference. I did a test run and even over 10 seconds of simulation we can see the difference as follows:

Please note the pitch angle convention shown in this figure is opposite to normal.

I was wondering which format you think would be more correct?

Kind regards

Sam

Dear all,

I am using ROSCO 2.4.1 to perform some simulations using openfast 2.4.0. I have changed the Cp_Ct_Cq.txt file with my own version and I have the following problem:
"At line 427 of file D:\bld\rosco_1636590340414\work\ROSCO\src\ReadSetParameters.f90 (unit = 89, file = 'C:\Users\Simulation\Files\Cp_Ct_Cq.txt')
Fortran runtime error: Bad real number in item 1 of list input"

Looking at the file ReadSetParameters.f90 at the line 427, it seems that the problem is in the Ct table but i don't have "strange" numbers in that table. What am I missing?
Thank you.
I attache my Cp_Ct_Cq.txt file.
CpCqCt.txt.txt

The complied 64 bit NREL 5-MW reference controller load in simpack can run well，but the complied 64 bit ROSCO controller libdiscon.dll cannot calculate in simpack 2019.
The input file Cp_Ct_Cq.NREL5MW.txt with DISCON.IN in same foleder or with libdiscon.dll?

This has been a nagging issue for a bit. Trying to keep it on our radar here.

I think we can probably borrow some OpenFAST routines and get it figured out.

Hi，

I compiled the ROSCO on Win10 and tried to replicate your simulation of torque control from your published paper as follows.
"Abbas, Nikhar J., Alan Wright, and Lucy Pao. "An Update to the National Renewable Energy Laboratory Baseline Wind Turbine Controller." Journal of Physics: Conference Series. Vol. 1452. 2020."
The comparison of the results is attached below. I do not know why the generator torque has an immediate dropdown after the velocity change?
From you paper:

From my simulation:

Thank you for any comments.

I have been trying to compile ROSCO using the instructions given at: https://github.com/NREL/ROSCO. I am using visual studio community 2019 with Intel's FORTRAN compiler (version 2020) and cmake (3.17.2) of course. When running cmake, the build files are generated to the created directory but the libdiscon dynamic link library is not compiled to the directory. Does one need to edit the cmake list in order for this to happen (generate the libdiscon dynamic link library) or is the dynamic link library generated by default?
Thanks in advance

when using the khalman-filter wind speed estimator, ROSCO terminates with error "forrtl: severe (59): list-directed I/O syntax error, unit 89, file C:\Users\username\Cp_Ct_Cq.NREL5MW.txt"

this also brings me to another issue, ROSCO does not read the file from the directory where the DISCON.IN file is located, isntead it treats my home folder as the cwd

output files however are generated in the correct directory

of coures, a workwaround is just not using the kahlman filter

Hi everyone,
I am trying to verify from the time response of the turbine the controller parameters that are set in the .yaml file for the pitch controller. I am testing the monopile IEA-15-240-RWT turbine and the desired controller parameters are 1.0 for damping and 0.2 rad/s for the natural frequency (as reported in the .yaml file). To observe this parameters in the rotor speed response, a step input on the reference signal should be applied. Since adding a step input on the reference on the DISCON.IN file is not possible (as far as I know), I run OpenFAST with the Simulink controller. I keep the wind constant at 15 m/s and after 100 s of transient, I apply a step input on the reference generator rotational speed of 0.2 rad/s (red curve). The blue curve is the response of the rotational speed. However, as the figure shows, the system is responding as an underdumped system: large overshoot and few oscillations before reaching the steady-state value. However, since the desired dumping with which the gains are computed is critical, I would expect a response without oscillations and overshoot. I know that the desired controller parameters are used to compute the gains schedule on a linearized model and what I am testing is a full non-linear model, however I believe the difference is way too large. Is there anything else that I am missing for which this type of analysis is wrong?

Any help is really appreciated. Thanks in advance,
Giorgio

however valid values are 0, 1 and 2?

Hi Folks,

I have just updated ROSCO to the latest, and am running a controller with, basically, the same input parameters <>.in as before. It does not render a reasonable torque control at all. It used to be fine.

After updating ROSCO, there was an issue with the WE_FOPoles_v that had the rated wind speed repeated and ROSCO's new CheckInputs would complain about non-decreasing values. I then regenerated that list of wind speeds (via the latest toolbox), and that issue went away. Other than that, the new <>.in is the same as my previous one except for
0.0 ! WE_CP that is showing one value rather than 3 zeros. I do not think this matters, however.

Yet the EKF (2 ! WE_Mode ) does not behave anymore. I had it working with constant wind speeds (a stepped ramp) and it used to be accurate, and the torque controller was just fine. Now it is stuck on the initial wind speed (3m/s, just below cut-in). When I set '0 ! WE_Mode', the controller works as expected.

Could you please help me understand what has changed that triggers this different behavior in EKF?

Hello,
Can someone explain for me example 12, i need to understand the meaning of stability margin and how it is calculated.

Generating the makefiles and compiling rosco using Visual Studio and Intel Fortran compiler seems to produce erroneous results

even after modifying the source code to resolve the REAL(8), and d0 explicit types, when compiling the .sln produced, the out are 3 files:
discon.dll
discon.exp
discon.lib

libdiscon.dll is nowhere to be found

Hello,

I am performing turbulence cases on the IEA 15 MW UMaine model in the above rated region.

I wanted to ask about the operation of the ROSCO controller in that case.

I can see from the DISCON.IN file that there are 28 gain scheduled parameters for the P and I for the PI pitch controller. I assume that in the above rated region those 28 values will be selected depending on the wind speed in the increments of 0.5m/s, because assuming pitching starts at 11m/s and ends at 25m/s, meaning we have 14*2 = 28 values for P and I?

In the case of turbulence, is there any interpolation between those 28 values depending on the wind speed?

Thanks in Advance,
Qusay.

Hello,

I am having difficulties compiling the latest ROSCO with Visual Studio on Windows. I used to be able to compile through the provided .vcxproj without issues. However now I get issues in the custom build step that is using CMake (I believe).
My CMake executable is under *D:* but it looks like there is a 'source' that is supposed to be under **C:/**Program Files/[...], which I cannot quite understand. Could you please help me figure this out?
Thank you,

Build started...
1>------ Build started: Project: ZERO_CHECK, Configuration: Release x64 ------
1>Checking Build System
1>CMake is re-running because D:/[...]/ROSCO/build/CMakeFiles/generate.stamp is out-of-date.
1> the file 'C:/Program Files/CMake/share/cmake-3.15/Modules/CMakeCommonLanguageInclude.cmake'
1> is newer than 'D:/[...]/ROSCO/build/CMakeFiles/generate.stamp.depend'
1> result='0'
1>-- The Fortran compiler identification is Intel 19.1.2.20200623
1>-- Detecting Fortran compiler ABI info
1>-- Detecting Fortran compiler ABI info - done
1>-- Determine Intel Fortran Compiler Implicit Link Path
1>CUSTOMBUILD : CMake error : The source "D:/Program Files/CMake/share/cmake-3.20/Modules/IntelVSImplicitPath/CMakeLists.txt" does not match the source "C:/Program Files/CMake/share/cmake-3.15/Modules/IntelVSImplicitPath/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
1>CMake Error at D:/Program Files/CMake/share/cmake-3.20/Modules/CMakeDetermineCompilerABI.cmake:155 (try_compile):
1> Failed to configure test project build system.
1>Call Stack (most recent call first):
1> D:/Program Files/CMake/share/cmake-3.20/Modules/CMakeTestFortranCompiler.cmake:20 (CMAKE_DETERMINE_COMPILER_ABI)
1> CMakeLists.txt:2 (project)
1>
1>
1>-- Configuring incomplete, errors occurred!
1>See also "D:/[...]/ROSCO/build/CMakeFiles/CMakeOutput.log".
1>CMake Configure step failed. Build files cannot be regenerated correctly. Attempting to stop IDE build.
1>D:\Program Files\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): error MSB8066: Custom build for 'D:[...]\ROSCO\build\CMakeFiles\5e62dfd0aa8c79d2f8a7b19e54b36a0a\generate.stamp.rule' exited with code 1.
1>Done building project "ZERO_CHECK.vcxproj" -- FAILED.
2>------ Build started: Project: discon, Configuration: Release x64 ------
2>Building Custom Rule D:/[...]/ROSCO/CMakeLists.txt
2>CMake is re-running because D:/[...]/ROSCO/build/CMakeFiles/generate.stamp is out-of-date.
2> the file 'C:/Program Files/CMake/share/cmake-3.15/Modules/CMakeCommonLanguageInclude.cmake'
2> is newer than 'D:/[...]/NREL_CODES/ROSCO/build/CMakeFiles/generate.stamp.depend'
2> result='0'
2>-- The Fortran compiler identification is Intel 19.1.2.20200623
2>-- Detecting Fortran compiler ABI info
2>-- Detecting Fortran compiler ABI info - done
2>-- Determine Intel Fortran Compiler Implicit Link Path
2>CMake Error: The source "D:/Program Files/CMake/share/cmake-3.20/Modules/IntelVSImplicitPath/CMakeLists.txt" does not match the source "C:/Program Files/CMake/share/cmake-3.15/Modules/IntelVSImplicitPath/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
2>CMake Error at D:/Program Files/CMake/share/cmake-3.20/Modules/CMakeDetermineCompilerABI.cmake:155 (try_compile):
2> Failed to configure test project build system.
2>Call Stack (most recent call first):
2> D:/Program Files/CMake/share/cmake-3.20/Modules/CMakeTestFortranCompiler.cmake:20 (CMAKE_DETERMINE_COMPILER_ABI)
2> CMakeLists.txt:2 (project)
2>
2>-- Configuring incomplete, errors occurred!
2>See also "D:/[...]/ROSCO/build/CMakeFiles/CMakeOutput.log".
2>The system cannot find the batch label specified - VCEnd
2>discon : error PRJ0019: A tool returned an error code
2>Build log written to "file://D:[...]\ROSCO\build\discon.dir\Release\BuildLog.htm"
2>discon - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========

Dear all，

I found trailing edge flap control parameters in the rosco.dll. The input channels of the S-function of FAST nonlinear model in rosco Simulink demo also contain flap control angles.

How can I use the flap control？

Shall I make any modification on Fast S-Func or source code，or aerodynamic input files？

Dear ROSCO Community

I am looking for IEA_10MW_offshore_ROSCO .dll file based on 32-bit for DNV Bladed(v.4.10) simulation.

I found DISCON_IEA_offshore.dll from IEAWindTask37 / IEA-10.0-198-RWT in Github and it was built with 64-bit.

So I put issues there and couldn't get enough information.

I saw similar issues about compiling IEA_15MW_RWT_Controller based on 32-bit but it's too difficult to understand.

Someone recommended documentation but there isn't detailed information.

Does anyone have ROSCO 2.6.0 for IEA_10MW_offshore?

If not, Would you please guide me specifically how to build .dll file based on 32-bit, IEA_10MW_offshore? (I have .IN File)

I just stepped into wind industry as a student and don't know how to start.

I really need a information from experts and want to study.

Currently, I am using DNV Bladed 4.10, OpenFAST 3.2.0, ROSCO 2.6.0, Visual Studio 2019.

Best regards,
wonny

Hi,

I am operation on MACOS, and I wanted to ask about the libdiscon file for the IEA15MW-UMaine found in
https://github.com/IEAWindTask37/IEA-15-240-RWT/tree/master/OpenFAST/IEA-15-240-RWT-UMaineSemi/ServoData

Is there a libdiscon.dylib 64-bit that I can use as there's only the .so, and .dll files?

I tried to generate it using cmake .. , but I ran through the following error!

Thanks in Advance,
Qusay.

% cd ROSCO
ROSCO % mkdir build
mkdir: build: File exists
% cd build
% cmake ..
-- The Fortran compiler identification is Intel 19.1.3.20200925
-- 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/ROSCO/build/CMakeFiles/CMakeTmp

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

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

-- Configuring incomplete, errors occurred!
See also "/Users/qusayhawari/ROSCO/build/CMakeFiles/CMakeOutput.log".
See also "/Users/qusayhawari/ROSCO/build/CMakeFiles/CMakeError.log".
qusayhawari@wireless-staff-pt3-119-81 build %

Hello,

I am simulating the behavior of ROSCO on the IEA-15-240-Fixed OpenFast model. When using VS_ControlMode different from 2 combined with the pitch saturation routine (PS_Mode = 1), I obtain negative rotor speed and the Kalman filter cannot estimate the wind speed correctly. I am using uniform laminar wind, increasing wind speed of 1 m/s every 50 seconds (starting from the cut-in speed). I have tried different initial conditions of the rotor speed but the problem persists. I cannot understand why I get this strange behavior and why everythinf works properly when using VS_ControlMode = 2 with the same initial conditions and keeping constant all the other parameters.
Thank you.
Elio

I think this is a pretty easy fix, I already changed it locally.
AeroDyn14 is not developed anymore, but some old reference models are still using it.

I am newbie to open-source contributions, but I'd be happy to contribute...

When using the develop branch, I get significantly lower power (GenPwr) than when using the master branch. This comparison has been performed using the same discon file and rotor performance file.

Enhancement request: S-Function implementation similar to that of OpenFAST.

This would be useful for combining ROSCO and OpenFAST in a MATLAB-Simulink environment