Setup Error after Following Documentation

[wvshelu]

Bug description I am trying to use the C++ API to run OpenFAST. I followed all instructions in the documentation and am able to successfully compile the simulator. However, when I run the compiled executable, I get the following error:

HDF5-DIAG: Error detected in HDF5 (1.10.6) thread 0:
  #000: H5Pdcpl.c line 2025 in H5Pset_chunk(): all chunk dimensions must be positive
    major: Invalid arguments to routine
    minor: Out of range

Have I set something up incorrectly? Are there any inputs I need to change?

Thanks in advance!

To Reproduce Steps to reproduce the behavior:

1. Verified that I have all necessary dependencies, at least according to documentation in https://openfast.readthedocs.io/en/master/source/install/index.html#compile-from-source:
   • cmake version 3.15.2
   • make version GNU Make 3.81
   • gfortran version GNU Fortran (GCC) 6.3.0
   • gcc version 11.0.0
   • g++ version 11.0.0
   • ifort version 19.0.5.281 20190816
   • hdf5 version 1.10.6
   • yaml-cpp version 0.6.3_1
2. Ran the following commands to set up directory structure:
   • git clone https://github.com/OpenFAST/OpenFAST.git
   • cd OpenFAST
   • mkdir build
   • cd build
3. Ran cmake .. -DBUILD_OPENFAST_CPP_API=ON (output displayed in next section)
4. Ran make and successfully built target opencpp in OpenFAST/build/glue_codes/openfast-cpp/
5. Put the cDriver.i file (content in next section) in same directory
6. Created a directory called inputs in the same directory as cDriver.i and copied over the directories 5MW_Land_DLL_WTurb and 5MW_Baseline from the r-test repository
7. Ran mpiexec -np 1 openfastcpp (output displayed in next section)
8. See the error at the top

CMake Output

-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- The C compiler identification is AppleClang 11.0.0.11000033
-- The Fortran compiler identification is Intel 19.0.5.20190816
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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/local/bin/ifort
-- Check for working Fortran compiler: /usr/local/bin/ifort  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/local/bin/ifort supports Fortran 90
-- Checking whether /usr/local/bin/ifort supports Fortran 90 -- yes
-- Could NOT find MKL (missing: MKL_LIBRARIES MKL_IFACE_LIB MKL_SEQ_LIB MKL_CORE_LIB) 
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Looking for Fortran dgemm
-- Looking for Fortran dgemm - found
-- Found BLAS: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework  
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- A library with LAPACK API found.
-- Setting system file as: src/SysIFL.f90
-- Found MPI_C: /usr/local/Cellar/open-mpi/4.0.2/lib/libmpi.dylib (found version "3.1") 
-- Found MPI_CXX: /usr/local/Cellar/open-mpi/4.0.2/lib/libmpi.dylib (found version "3.1") 
-- Found MPI_Fortran: /usr/local/Cellar/open-mpi/4.0.2/lib/libmpi_usempif08.dylib (found version "3.1") 
-- Found MPI: TRUE (found version "3.1")  
-- Found LibXml2: /usr/lib/libxml2.dylib (found version "2.9.4") 
-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.11") 
-- HDF5: Using hdf5 compiler wrapper to determine C configuration
-- Found HDF5: /usr/local/Cellar/hdf5/1.10.6/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib (found version "1.10.6") found components:  C HL 
-- Found YAMLCPP: /usr/local/include  
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/sherryluo/git/openfast/build

cDriver.i Content

# -*- mode: yaml -*-
#
# C++ glue-code for OpenFAST - Example input file
#

#Total number of turbines in the simulation
nTurbinesGlob: 1
#Enable debug outputs if set to true
debug: True
#The simulation will not run if dryRun is set to true
dryRun: False
#Flag indicating whether the simulation starts from scratch or restart
simStart: init # init/trueRestart/restartDriverInitFAST
#Start time of the simulation
tStart:  0.0
#End time of the simulation. tEnd <= tMax
tEnd:    1.0
#Max time of the simulation
tMax:    4.0
#Time step for FAST. All turbines should have the same time step.
dtFAST:  0.00625
#Restart files will be written every so many time steps
nEveryCheckPoint: 160

Turbine0:
  #The position of the turbine base for actuator-line simulations
  turbine_base_pos: [ 0.0, 0.0, 0.0 ]
  #The number of actuator points along each blade for actuator-line simulations
  num_force_pts_blade: 0
  #The number of actuator points along the tower for actuator-line simulations.
  num_force_pts_tower: 0
  #The checkpoint file for this turbine when restarting a simulation
  restart_filename: "banana"
  #The FAST input file for this turbine
  FAST_input_filename: "inputs/5MW_Land_DLL_WTurb/5MW_Land_DLL_WTurb.fst"
  #A unique turbine id for each turbine
  turb_id:  1

Output After Running

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

 Copyright (C)  National Renewable Energy Laboratory
 Copyright (C)  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.2.0
 Compile Info:
  - Architecture: 64 bit
  - Precision: double
  - Date: Feb 24 2020
  - Time: 17:14:25
 Execution Info:
  - Date: 02/24/2020
  - Time: 17:28:06-0800

 OpenFAST input file heading:
     FAST Certification Test #18: NREL 5.0 MW Baseline Wind Turbine (Onshore)

 Running ElastoDyn.
 Running AeroDyn.
 Running AirfoilInfo.
 Running BEM.
 Running UnsteadyAero.
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 3
 Running InflowWind.

    Reading a 31x31 grid (145 m wide, 17.5 m to 162.5 m above ground) with a characteristic wind
    speed of 12 m/s. This full-field file was generated by TurbSim (v1.06.00, 21-Sep-2012) on
    07-Jan-2014 at 12:50:45.

    Processed 1442 time steps of 20-Hz full-field data (72.05 seconds).
 Running ServoDyn.
 Running ServoDyn Interface for Bladed Controllers.
HDF5-DIAG: Error detected in HDF5 (1.10.6) thread 0:
  #000: H5Pdcpl.c line 2025 in H5Pset_chunk(): all chunk dimensions must be positive
    major: Invalid arguments to routine
    minor: Out of range
 T1 Time: 0 of 4 seconds.
[Sherrys-MacBook-Air:50492] *** Process received signal ***
[Sherrys-MacBook-Air:50492] Signal: Segmentation fault: 11 (11)
[Sherrys-MacBook-Air:50492] Signal code: Address not mapped (1)
[Sherrys-MacBook-Air:50492] Failing at address: 0x0
[Sherrys-MacBook-Air:50492] [ 0] 0   libsystem_platform.dylib            0x00007fff5d81eb5d _sigtramp + 29
[Sherrys-MacBook-Air:50492] [ 1] 0   ???                                 0x2020202020202020 0x0 + 2314885530818453536
[Sherrys-MacBook-Air:50492] [ 2] 0   openfastcpp                         0x00000001049c8b9c main + 556
[Sherrys-MacBook-Air:50492] [ 3] 0   libdyld.dylib                       0x00007fff5d6333d5 start + 1
[Sherrys-MacBook-Air:50492] [ 4] 0   ???                                 0x0000000000000001 0x0 + 1
[Sherrys-MacBook-Air:50492] *** End of error message ***
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 0 on node Sherrys-MacBook-Air exited on signal 11 (Segmentation fault: 11).

System Information (please complete the following information):

• OS: macOS 10.14.6
• Compiler: * GFortran 6.3.0, gcc 11.0.0, g++ 11.0.0
  • Compiler settings: -DBUILD_OPENFAST_CPP_API=ON

[andrew-platt]

@gantech do you have any thoughts on this?

[gantech]

Hello @wvshelu Are you able to run the same openfast model with the fortran driver? Like so openfast model.fst? This does not seem to be related to the HDF5 error.

I do see the messages you see related to the HDF5 library. We are in the process of making those outputs more robust by moving to netcdf.

[arodriguezluis]

Hello @gantech , I am getting the same error as described by @wvshelu, but using latest version: OpenFAST-v3.0.0-dirty. I am able to run the openfast model with the fortran driver. I can provide the details of my case if needed, but I wanted to ask first if there were some advances in how to solve this issue.

[Yuksel-Rudy]

I'm facing the same error when running a simulation through openfastcpp. After initialization is done, the following error message shows up:

HDF5-DIAG: Error detected in HDF5 (1.13.1) thread 0:
  #000: /home/buildbot/bb-workers/centos7-vm01/hdf5trunk-StdRelease-dist-centos7/build/hdfsrc/src/H5Pdcpl.c line 2132 in H5Pset_chunk(): all chunk dimensions must be positive
    major: Invalid arguments to routine
    minor: Out of range

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 16879 RUNNING AT GNPT7M3
=   EXIT CODE: 11
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES`
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions

Is there something wrong with the HDF5 setup? I tried installing hdf5-1.12.0 instead but similar error occurred:

HDF5-DIAG: Error detected in HDF5 (1.12.0) thread 0:
  #000: /home/rudy/hdf5build/CMake-hdf5-1.12.0/hdf5-1.12.0/src/H5Pdcpl.c line 2025 in H5Pset_chunk(): all chunk dimensions must be positive
    major: Invalid arguments to routine
    minor: Out of range

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 20227 RUNNING AT GNPT7M3
=   EXIT CODE: 11
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================

Please note that the same .fst model is perfectly runnable with default openfast executable.

[rafmudaf]

@Yuksel-Rudy which version of OpenFAST are you using?

[Yuksel-Rudy]

latest, main branch. As an alternative, would it be a good idea to install OpenFAST with C++ API option through Spack instead?

[rafmudaf]

v3.2 is the latest on main and was released just a few days ago. It would be helpful if you could try v3.1 to understand whether there's a bug introduced in the latest release. Spack might help resolve any dependency version issues, if that is indeed the problem.

[Yuksel-Rudy]

Forgive me, the version I was using was a forked and modified one. I reinstalled everything from scratch with both versions 3.1 and 3.2. The error persisted but the simulation was completed regardless. I'll investigate further as to why when I modified the source code it didn't run. But for now at least we know it works on both versions.

P.S. v3.2 does not allow user to clone with --recursive flag on. It returns 'permission denied'. Just an FYI.

[andrew-platt]

@Yuksel-Rudy, how did you clone the repository?

git clone --recursive https://github.com/OpenFAST/OpenFAST.git or git clone --recursive git@github.com:/OpenFAST/OpenFAST.git

The submodules are cloned using ssh by default (git@github.com:/OpenFAST/r-test.git) and may fail if you don't have ssh git credentials stored. @rafmudaf, any other thoughts?

[Yuksel-Rudy]

permission denied either way.

[rafmudaf]

This was a surprise to me @andrew-platt. I thought read-access would be allowed via ssh. I've started a new thread for this at https://github.com/OpenFAST/openfast/discussions/1191.

[LeonardWilleke]

Hi everyone,

I am facing a similar problem as the original post from @wvshelu, but with OpenFAST v3.5.0

Installation I installed OpenFAST v3.5.0 from source following the instructions. CMAKE had to be linked to HDF5 and yaml manually during the building process, but once that was done the installation worked. I am running on Ubuntu 20.06.

What works? I have no trouble when executing OpenFAST from the command line:

openfast ../nrel5mw-onshore.fst

It is also possible to run the example script FASTProg provided in the official repository, if debug=False in the input file cDriver.i:

./FAST_Prog cDriver.i

This means, certain functionalities like FAST.init(), FAST.step() and FAST.end() are called without a problem.

What fails? If I try to run FASTProg with debug=True in the input file cDriver.i I get the following error after OpenFAST initialized successfully:

HDF5-DIAG: Error detected in HDF5 (1.10.4) MPI-process 0:
  #000: ../../../src/H5Pdcpl.c line 2036 in H5Pset_chunk(): all chunk dimensions must be positive
    major: Invalid arguments to routine
    minor: Out of range
[leonard-MacBookPro:04115] *** Process received signal ***
[leonard-MacBookPro:04115] Signal: Segmentation fault (11)
[leonard-MacBookPro:04115] Signal code: Address not mapped (1)
[leonard-MacBookPro:04115] Failing at address: (nil)
[leonard-MacBookPro:04115] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x43090)[0x7f6f4df71090]
[leonard-MacBookPro:04115] [ 1] /home/leonard/Tools/openfast/install/lib/libopenfastcpplib.so(_ZN4fast8OpenFAST4stepEv+0x6e4)[0x7f6f4e195ff4]
[leonard-MacBookPro:04115] [ 2] ./FAST_Prog(+0x1289c)[0x55acedaf789c]
[leonard-MacBookPro:04115] [ 3] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f6f4df52083]
[leonard-MacBookPro:04115] [ 4] ./FAST_Prog(+0x1101e)[0x55acedaf601e]
[leonard-MacBookPro:04115] *** End of error message ***
Segmentation fault (core dumped)

If debug=True, the script FAST_Prog fails at the call of FAST.computeTorqueThrust(0,torque,thrust) where torque and thrust are vectors handed to OpenFAST. Other functions that also handle data exchange like FAST.setVelocity(...) or FAST.getForce(...) fail with the same error message.

As noted by @Yuksel-Rudy before, the HDF5 error also persists in runs that do succeed. Any help is appreciated.

Best, Leonard

[LeonardWilleke]

I resolved the issue by adapting my ElastoDyn input file.

What was the problem? I didn't specify any blade nodes with strain gages to measure the forces on the blade. The force values were not stored and could therefore not be accessed by the C++ API function FAST.getForce(...). This probably lead to the HDF5 out of range error. It would also explain why certain functions like FAST.step() who didn't access that data were not affected.

How to solve it? Make sure to define strain gages in the output section of your ElastoDyn input file as shown in the example below.

---------------------- OUTPUT--------------------------------------------------
...
          3   NTwGages    - Number of tower nodes that have strain gages for output [0 to 9] (-)
         6,         12,         18    TwrGagNd    - List of tower nodes that have strain gages [1 to TwrNodes] (-) [unused if NTwGages=0]
          3   NBlGages    - Number of blade nodes that have strain gages for output [0 to 9] (-)
          5,          9,         13    BldGagNd    - List of blades that have strain gages [1 to BldNodes] (-) [unused if NBlGages=0]
...

[andrew-platt]

@LeonardWilleke, thanks for reporting back on what the issue was!

This looks like a bug that should be addressed at some point (I'm not entirely certain what the best fix would be).