Sending RtAeroPwr via ServoDyn to Bladed-Style DLL Controller

Dear all,

In order to develop and test a controller for a variable speed, stall controlled wind turbine, I need the current rotor aerodynamic power RtAeroPwr at each time step being available in a Bladed-Style DLL controller. I am using OpenFAST v2.1.0. and followed the instructions for passing parameters from one module to another given by Bonnie in these posts:

With this help I was able to compile a modified OpenFAST version without errors. However, once I try to run my modified OpenFAST version I get the following error message:
FAST_InitializeAll:Error allocating AD%Input and AD%InputTimes.
forrtl: severe (157): Program Exception - access violation

All my changes to the source code are summarized in the attached document.

Does someone know where this error might come from?
In my investigations I found that this error is triggerd in line 439 of FAST_Subs.f90 (subroutine FAST_InitializeAll), but that doesn’t really help me.
I would be deeply grateful for any help.

Best regards,
Paul
Changes_in_OpenFAST_SourceCode_to_send_RtAeroPwr_to_dll.docx (13.9 KB)

Hi, Paul.

I don’t see anything in your code that would be problematic. I suspect that the code isn’t linking with the new compiled version of the FAST_types.f90 files, which is what causes the access violations. (I have had this problem before, myself. I am not sure if this is a Visual Studio problem or if there is something wrong in the way the FAST project files are set up.)

Any time you change the Registry input files in FAST, I would suggest “cleaning” the FAST project file (highlight the “FAST” project, right click, select “project only->Clean Only FAST”), and then building again. You can also just do a “clean” or “rebuild” of the entire solution, but it takes a while to build everything.

Hi Bonnie,

Thank you very much for your helpful answer. The missing link of the code with the new FAST_types.f90 files was one problem in my version that I would not have found by myself. So, thanks for giving the hint on testing this.

Additionally, I had one other mistake at one call of my modified SrvD_InputSolve routine. After solving this issue my modified OpenFAST version now is compiling without errors and running as expected. Thanks again for helping me in achiving this.

For those trying similar things, I have attached an updated version of the document summarizing all changes to the code, which I have made for my final version.

Best regards,
Paul SchĂĽnemann

P.S.: For anyone new to modifying the OpenFAST source code, I really recommend to use the debug mode, i.e. selecting Debug or Debug_Double in the Solution Configuration when working with MS Visual Studio. With this, compiling will take a while, but afterwards if you have a bug in your code and run your compiled OpenFAST version in command window, you will get useful information where to find the bug in the command window.
Changes_in_OpenFAST_SourceCode_to_send_RtAeroPwr_to_dll.pdf (291 KB)

Hi all,

I am experiencing a similar problem.
When the simulation starts to write output (at TStart) the simulation crashes with
“fstforrtl: severe (157): Program Exception - access violation”.
image
Any idea what might cause this?

This error is seen with and without servodyn/the controller activated.

I am using OpenFAST v3.0.0 compiled with Visual Studio 2019:

OpenFAST-Unversioned from 42a5a8196529ae0349eda6d797a79461c2c03ff0
Compile Info:

  • Compiler: Intel(R) Fortran Compiler 2021
  • Architecture: 32 bit
  • Precision: single
  • OpenMP: No
  • Date: Jan 25 2022
  • Time: 15:45:52

Best regards,
Simon

Dear Simon,

Did you, like Paul, change the OpenFAST source code in some way?

Can you share the full message written to the Command Prompt when you execute OpenFAST?

Best regards,

Hi Jason,

  1. I see the same error also with the compiled version from here: https://github.com/OpenFAST/openfast/releases/download/v3.0.0/openfast_x64.exe
    Thus I don’t expect my changes to OpenFAST and the compiling process to be the cause of the error.

  2. I reduced model complexity (only Elastodyn with 0 DOF and Beamdyn for the blades) in several steps. No other warnings or errors are given by OpenFAST before the crash.

  3. I was able to narrow the problem down to the option in Beamdyn to include outputs for all stations as described here 4.2.4.3. Input Files — OpenFAST v3.3.0 documentation.
    When excluding all sensors for all blades in the nodal-output section in Beamdyn the error does not occur. This is true for the initial model and the simplified model.
    When including only a few sensors (2) the simulation crashes with the above error in about 50% of the runs. With no differences between the runs except the run name and time of execution.

Is there a known limitation to the nodal-output section in Beamdyn that might be influenced by the state of the computer?

Best regards,
Simon

Hi Simon,

It sounds like a potential memory issue with one or more of the BeamDyn nodal outputs. We will take a look and see if we are trying to access an array that isn’t allocated in certain instances.

I agree. It is probably an array not getting allocated, or an index out of bounds. I’ll take a look at it.

1 Like

Hi Simon,

Could you attach the primary BeamDyn and ElastoDyn input files (if it doesn’t contain proprietary information)? I am so far unable to reproduce this with simply adding the nodal-output section to the BeamDyn file using either v3.0.0 or the current dev branch.

Regards,
Andy

Hi Andy,

unfortunately, I can not share these files. Which model were you using for your tests?

I was doing further tests on my side.
In BeamDyn I use 50 keypoints and one member. This results in 30-50% of the runs crashing depending on if I include other outputs in the normal BeamDyn Output section, the number of Blades with nodal outputs, and the number of sensors for the nodal output.

When reducing the number of keypoints to 20 without significantly changing the curvature the number of crashes goes down to 11%.

I am running test cases with TStart = 1 and TMax =2. For each case described above, I ran > 150 runs.

Thus I suggest you increase the number of keypoints to a high number and run at least 100 runs per test.

Do you have a compiled version of OpenFAST with debugging activated? Maybe this tells us more about the origin of the error.

Best regards,
Simon

Hi Simon,

Thanks for your reply. Are you using refinement in your BeamDyn model?

I ran preliminary testing using the 5MW_Land_BD_DLL_WTurb model with aero, inflow, and servo turned off. For this testing, I compiled both the v3.0.0 release and dev branch in both debug and release using gcc on a Mac (this often shows array bounds issues).

I am suspicious we may be triggering a bug that appears only with the Intel compiler in the WriteOutput handling in the glue code (there was a potentially bug fix a few months ago that addressed some strange segmentation faults due to missing ALLOCATABLE statements – only appeared in release and not in debug). I’ll run a few tests with a couple different Intel compilers on Linux and Windws and see what I can find. If what you are observing is related to this, it may be fixed in the dev branch.

Regards,
Andy

update:
I ran some tests on v3 using Intel compiler on linux. There are some missing ALLOCATABLE statements that have been added in the dev branch that take care of the segmentation faults (ElastoDyn.f90::SetBladeParameters). Have you tested your model with the current dev branch?

Strangely I could not reproduce any issues with with Intel Fortran compiler on Windows (OneAPI version 2021 – released v3.0.0 distributed executable is Intel Fortran 1900).

Hi Andy,

I have refine set to default/1 in BeamDyn.
Till now I did not have time to try the current dev branch.

Best regards,
Simon

Hi Andy,

I did some more tests and tried to reproduce the error with the NREL model from "5MW_Land_BD_DLL_WTurb" in the v3.0.0 r-test repository.

With the following changes I see the same error as before running with the x64 compiled version from here.

Without the nodal output section in BeamDyn no error is given.

NRELOffshrBsline5MW_BeamDyn.dat (only nodal output added):

---------------------- OUTPUTS -------------------------------------------------
True SumPrint - Print summary data to “.sum” (flag)
“ES10.3E2” OutFmt - Format used for text tabular output, excluding the time channel.
0 NNodeOuts - Number of nodes to output to file [0 - 9] (-)
1, 2, 3, 4, 5, 6 OutNd - Nodes whose values will be output (-)
OutList - The next line(s) contains a list of output parameters. See OutListParameters.xlsx for a listing of available output channels, (-)
“RootFxr, RootFyr, RootFzr”
“RootMxr, RootMyr, RootMzr”
“TipTDxr, TipTDyr, TipTDzr”
“TipRDxr, TipRDyr, TipRDzr”
END of input file (the word “END” must appear in the first 3 columns of this last OutList line)
---------------------- NODE OUTPUTS --------------------------------------------
99 BldNd_BlOutNd - Blade nodes on each blade (currently unused)
OutList - The next line(s) contains a list of output parameters. See OutListParameters.xlsx, AeroDyn_Nodes tab for a listing of available output channels, (-)
“Mxr” - Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N-m)
“Myr” - Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N-m)
“Mzr” - Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N-m)
END of input file (the word “END” must appear in the first 3 columns of this last OutList line)


5MW_Land_BD_DLL_WTurb.fst (only TMax, feature switches, file paths and TStart changed):

     2   TMax            - Total run time (s)

---------------------- FEATURE SWITCHES AND FLAGS ------------------------------
2 CompElast - Compute structural dynamics (switch) {1=ElastoDyn; 2=ElastoDyn + BeamDyn for blades}
0 CompInflow - Compute inflow wind velocities (switch) {0=still air; 1=InflowWind; 2=external from OpenFOAM}
0 CompAero - Compute aerodynamic loads (switch) {0=None; 1=AeroDyn v14; 2=AeroDyn v15}
0 CompServo - Compute control and electrical-drive dynamics (switch) {0=None; 1=ServoDyn}
0 CompHydro - Compute hydrodynamic loads (switch) {0=None; 1=HydroDyn}
0 CompSub - Compute sub-structural dynamics (switch) {0=None; 1=SubDyn; 2=External Platform MCKF}
0 CompMooring - Compute mooring system (switch) {0=None; 1=MAP++; 2=FEAMooring; 3=MoorDyn; 4=OrcaFlex}
0 CompIce - Compute ice loads (switch) {0=None; 1=IceFloe; 2=IceDyn}

      1   TStart          - Time to begin tabular output (s)

Output at execution:
"**************************************************************************************************
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-v3.0.0
Compile Info:

  • Compiler: Intel(R) Fortran Compiler 1900
  • Architecture: 64 bit
  • Precision: single
  • OpenMP: No
  • Date: Jun 23 2021
  • Time: 21:25:05
    Execution Info:
  • Date: 02/03/2022
  • Time: 11:32:55+0100

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

Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
Running BeamDyn.
Running BeamDyn.
Running BeamDyn.
Time: 0 of 2 seconds.
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
openfast_x64.exe 00007FF7A1313DB6 Unknown Unknown Unknown
openfast_x64.exe 00007FF7A0CC3567 Unknown Unknown Unknown
openfast_x64.exe 00007FF7A02B8F6D Unknown Unknown Unknown
openfast_x64.exe 00007FF7A02A753E Unknown Unknown Unknown
openfast_x64.exe 00007FF7A02988CE Unknown Unknown Unknown
openfast_x64.exe 00007FF7A021AF0B Unknown Unknown Unknown
openfast_x64.exe 00007FF7A021A93C Unknown Unknown Unknown
openfast_x64.exe 00007FF7A01D1CD3 Unknown Unknown Unknown
openfast_x64.exe 00007FF7A27E8362 Unknown Unknown Unknown
openfast_x64.exe 00007FF7A2CE4134 Unknown Unknown Unknown
KERNEL32.DLL 00007FFC0B707034 Unknown Unknown Unknown
ntdll.dll 00007FFC0D702651 Unknown Unknown Unknown"

Hi Andy,

are you able to reproduce the error? We see this on all systems we tested it on.

Best regards,
Simon

Hi Simon,

It took a bit of digging to find what I think is the root cause of the issue. Essentially the problem was an index value that was not getting set, so whatever value was resident in memory was used. Occasionally this value would be so far out of bounds that it would address reserved memory space in Windows and cause a severe access violation. This would only appear in certain compiled versions on Windows and so I could only reproduce this on one of the two Windows computers I tested with.

I believe I have a suitable fix here: [BugFix] BeamDyn nodal outputs occasionally segfaulted by andrew-platt · Pull Request #996 · OpenFAST/openfast · GitHub. This pull request is to apply it to the dev branch of OpenFAST, but could be manually applied to v3.0.0 if you so desired. The change required for the BeamDyn.f90 file is seen here: [BugFix] BeamDyn nodal outputs occasionally segfaulted by andrew-platt · Pull Request #996 · OpenFAST/openfast · GitHub.

Hopefully this will solve the issue you were seeing.

Cheers,
Andy

1 Like

Hi all,

I am experiencing a similar problem.
I am trying to pass the variable PtfmTDyi from elastrodyn to the servodyn file. I followed the method posted by Mr. SchĂĽnemann, and the compiling went well. However, when I tried to actually run the executables, it shows the following error:

Farm_Initialize:Farm_ValidateInput:OutFmt produces a column width of 10 instead of 20 characters.
Farm_Initialize:For efficiency, NumPlanes has been reduced to the number of time steps (134).
Farm_Initialize:T1:Farm_InitFAST:FWrap_Init:FAST_InitializeAll:FAST_Init:FAST_ReadPrimaryFile:Inva
lid numerical input for file

Could anyone provide some advice on how to solve the problem?

Thanks in advance.

Yours sincerely,
Yuan

Dear @Yuan.Gao,

The transfer of platform motions (including PtfmTDyi) from ElastoDyn to ServoDyn is included in the recent release of OpenFAST v3.1 via PR # https://github.com/OpenFAST/openfast/pull/664. You can find documentation here: 4.2.11.2. Extended Bladed Interface — OpenFAST v3.3.0 documentation.

Regarding your error, their appears to be a formatting problem in your OpenFAST primary input file. As with any input file processing issue, I’d recommend enabling the Echo option to debug.

Best regards,

Hello Dr. Jonkman,

Thank you very much for your kind help!

Yours sincerely,
Yuan