Instructions for Compiling FAST

Sir,

Thank you for your earlier reply. As Added mass matrix(6*6) and force vector(6) are outputs of UserPtfmLd() routine and as seismic internally calculates those matrices, how can I get them.

Thank you.

Dear Dhaneesh,

In Seismic’s version of the UserPtfmLd() routine, the platform added mass matrix, PtfmAD, is always zero. The platform load vector, PtfmFt, is calculated by Seismic. The values of this force can be obtained through the output parameters PtfmFxi/PtfmFyi/PtfmFzi for the three forces and PtfmMxi/PtfmMyi/PtfmMzi for the three moments (when these output parameters are included in the OutList) .

Best regards,

Sir,

In the Seismic version of FASTv7, I observed no change in tower top displacement value for NREL 5MW turbine subjected to Seismic loading alone, when I tried running Seismic with different platform mass values. Can I know where am I going wrong?

Thank you.

Dear Dhaneesh,

I’m not sure what you are trying to do, but the Seismic documentation recommends that you run the simulation with the platform mass set much larger than the full-system turbine mass so that the platform mass itself is not important to the simulation response (but a large value keeps the simulation numerical stable while ensuring that the prescribed seismic excitation is followed well.

Best regards,

Sir,

Thank you for your reply. I want to combine tower top displacement of NREL 5MW turbine when excited to earthquake motion alone in the Seismic module with top tower displacement of NREL 5MW_OC3Monopile turbine subjected to combined wind and wave loading in OpenFast. But the foundation platform mass in Seismic is much higher than the monopile mass in OpenFast. So I tried reducing the mass of the platform and made it behave as monopile by keeping the platform reference point at 20m and tower draft as 0 m to make the onshore turbine look like it is resting on a monopile foundation and earthquake excitation is applied at the platform reference point to look like earthquake excitation applied at the seabed. But it didn’t make any changes to my results. Alternatively, I tried giving an additional platform mass in the Elastodyn input file of NREL 5MW_OC3Monopile in OPenFast to make the whole structure mass the same as that in Seismic module, but it didn’t work either.

  1. In the Seismic module, the turbine subjected to earthquake excitation by allowing Aerodyn to read turbsim.bts file and setting Rotspeed to 12.1rpm or initial speed of 9 rpm but setting aerodynamic loading(CompAero=0) still refers to a turbine in parked condition? Can I combine these results with a turbine subjected to wave loading and operating at a certain wind speed? Because I am feeling that both are two different wind turbine conditions and can’t be superimposed. If not is there any way that I can consider seismic, wind, and wave loads on the NREL 5MW turbine in FAST?

Can you please help me with some suggestions?

Dear Dhaneesh,

I’m not sure what you mean when you say that “it didn’t work”.

Using CompAero = 0 will eliminate all aerodynamic loads from the model.

I have not done this myself, but you should be able to run Seismic in an offshore monopile configuration, with combined wind, wave, and seismic excitation. In this case, you would use PtfmModel = 2 in the FAST v7 primary (*.fst) input file and use FAST tower and platform input files that are similar to the ones for the couple springs (CS) model (found in my post dated Nov 27, 2018 in the following forum topic: http://forums.nrel.gov/t/simulating-oc3-phase-ii-coupled-springs-in-fast-v7/1938/2), but with PtfmSgDOF and PtfmSwDOF (and perhaps PtfmHvDOF) enabled; PtfmRDOF, PtfmPDOF, and PtfmYDOF disabled; and PtfmMass set to be a value much larger than combined mass of the turbine + monopile.

Best regards,

Sir,

Thank you for the information. I got the tower and platform input file and UserPtfmLd file for the coupled spring model. In seismic I replaced the tower and platform files of the onshore model with these files. I have set the platform mass twice that of the combined mass of tower+ monopile and enabled the DOF’s and acceleration time series was mentioned in the seismic.dat input file and tried to run Seismic, but it was aborting with an error trying to read CurrMod. But I have considered no loading due to current. Should code be recompiled after adding these new files?

C:\Users\Bhargav>E:\Seismic\operating\FAST_iwin32_DLL.exe E:\Seismic\operating\NRELOffshrBsline5MW_Onshore.fst

Running NWTC Subroutine Library (v1.07.00b-mlb, 10-Jan-2013).

Running FAST (v7.02.00d-bjj, 20-Feb-2013).

Heading of the FAST input file: NREL 5.0 MW Baseline Wind Turbine for Use in Offshore Analysis.

Invalid numerical input for file “E:/Seismic/operating/NRELOffshrBsline5MW_Onshore_Ptfm.dat”.
The error occurred while trying to read CurrMod.

Aborting FAST.

Thank you.

Dear Dhaneesh,

I would guess that there is a formatting problem in your platform input file. As with any input file error, I would enable the “Echo” option from the FAST primary input file to debug errors with the input file formatting.

Best regards,

Sir,

Thanks for the help, now I can run the program. In the out list parameters excel file provided in the FASTv7 achieve, parameters to get hydrodynamic loading due to the Morison equation are not mentioned.

  1. How to get them in the output file?
  2. In the output section of the platform file for the coupled spring model, how the tower nodes numbering has been distributed from the seabed to mean sea level. And how I can get WaveElev at (0,0,0) i.e, at MSL.

Dear Dhaneesh,

Actually, without changing the source code, it is not possible in FAST v7 to output the hydrodynamic applied loads distributed across the pile. You can output the local pile reaction loads through the local tower load outputs (TwHt1FLxt, TwHt1MLxt, etc. for yt and zt and for gages 2-9).

The locations of the tower analysis nodes are documented on page 69 of the old FAST v7 User’s Guide.

The wave elevation at (0,0) can be output by including output channel “WaveElev” in the OutList in the FAST v7 primary input file.

Best regards,

Sir,

While running Simulations using a coupled spring model for combined seismic, wind, and wave loading, I was getting an error message as below. I tried reducing the time step in the input.fst file and increasing damping for the tower in tower monopile CS.dat file. Even though the same error was displaying. Can I get some help?

WARNING: Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection. The solution may be inaccurate. Simulation continuing, but future warnings will be suppressed.
Timestep: 628 of 630 seconds. Estimated final completion at 21:14:51.
Error: FF wind array was exhausted at 628.65 seconds (trying to access data at 642.75 seconds).
Error getting velocity in AeroDyn/AD_WindVelocityWithDisturbance().

Aborting FAST.

Thank you.

Sir,

I have read your post on Nov 4, 2010, and got cleared my doubt which I mentioned in my earlier post. So I tried doing linearization analysis to find the highest natural frequency for setting proper time step. But I have a problem while doing linearization analysis which I have mentioned in other topic.

Thank you.

Dear Jason/Bonnie,

I have two binaries of OpenFAST v2.2.0, one in Windows (I got the binnaries from github) and one in Linux (Ubuntu 18.04) that I got using git and then I compiled the source code. For the case of Windows I installed the necessary ifortran dlls (as explained in the docs) and for the case in Linux I compiled using GCC-6.3.0 - OpenBLAS-0.2.19-LAPACK-3.7.0.

During compilation the only error that appears in CMakeError.log is: error: “‘undefined reference to 'pthread_create’” but as far as I know this should not be a problem because two steps further the pthread library is found by cmake system and the compilation continues. I have also checked CMakeOutput.log in order to find something wrong but nothing weird appeared.

The problem came when we compared the results for simulations with the same input files and I saw that Windows and Linux outpus are completely different in some cases (for the Linux binaries sometimes they does something unphysical indeed). In that point, I suspected that was something wrong with Linux binaries, so I decided to run the testing suite that comes with OpenFAST and I got some failed tests.

In addition, for the Linux cases, I recive this message when I run simulation with waves: “FAST_InitializeAll:HydroDyn_Init:Waves_Init:VariousWaves_Init: The random number generator in use differs from the original code provided by NREL. This pRNG uses 12 seeds instead of the 2 in the HydroDyn input file

I have been trying to find more clues about where this difference comes from but I am new using OpenFAST, so It would be appreciated if you can guide me to find the error, which I suspect is a compilation error that I cannot find.

Thanks in advance.

Best Regards,

Sergio

Dear Sergio,

I can’t answer your CMake/Linux compiling-related questions; for those, I suggest posting on the OpenFAST github issues page: github.com/OpenFAST/openfast/issues.

Are the simulations that are “failing” all of the offshore cases? The HydroDyn module of OpenFAST currently uses the pseudo random number generator (pRNG) that is intrinsic to the Fortran compiler. This pRNG differs between Intel Fortran, which is what is used to compile the Windows binaries, and gfortran, which it appears you are using to compile on Linux. Thus, even when using the same WaveSeed(s) in the HydroDyn input file, you’ll get different wave time series and resulting structural response on Windows and Linux. This issue has been reported on OpenFAST: github.com/OpenFAST/openfast/issues/89. I’ve heard that Rafael Mudafort is currently working to resolve the issue by implementing the RanLux pRNG into HydroDyn, so, hopefully this issue should be resolved soon.

Best regards,

Dear Jason,

Thanks for your clarifiying response. we will take care with comparisons in between windows/linux when Hydrodyn module is activated.

The tests which are failling are most of them from the offshore pack, but I have three of them which does not seem to be related to HydroDyn module -test numbers: 9, 16 and 17.

Best Regards,

Sergio

Dear Sergio,

I tend to ignore the results for tests 15-17, which are models of the SWRT, which is a furling turbine with a tail fin that is not currently supported in OpenFAST. These tests worked fine in FAST v7, but with the furling and tail-fin capability currently absent from OpenFAST, these models are ill formed. We hope to add back furling capability and tail-fin aerodynamics in a future version of OpenFAST.

I’m a bit surprised about test 9, but I’d probably have to understand what you mean by “failure”. Perhaps the time series are still quite close?

Best regards,

Dear Jason,

With “failure” I mean that the test is not passed because the error norm criterion in between calculated signal and reference values was not satisfied. So, with “failure” I don’t mean that the program blows up and the simulations stops.

Furthermore, I have compared time signals by plotting them and inspecting them visually. For the most of them there is no visual difference although they don’t satisfy error criterion, but for the signals from 6 to 12 it is possible to see some peaks or areas with clear differences. Some of the peaks have relative errors up to 10%.

Just to clarify, I did the comparison of my Ubuntu 18.04 GNU compiled OpenFAST and the results in the folder: “openfast\reg_tests\r-test\glue-codes\openfast\UAE_Dnwind_YRamp_WSt\linux-gnu” of the OpenFAST repository.

Best Regards,

Sergio

Dear Sergio,

From my experience, the pass/fail criteria in the r-test is too strict (and dependent on compiler and platform) and cases fail even when the results are very close, certainly within engineering accuracy. Other than some of the “peaks” are you describing, this certainly seems to match what you are saying. But I’m not sure I can judge whether the “peaks” should be a concern without seeing them.

Best regards,

Dear Jason,

Sorry for my late answer, I have been doing some additional checks. First, I agree with you that maybe r-test faillure criteria is too strict for engineering purposes, because most of the signals fail even when the local differences are quite small. For the test case 9, I have installed a new toolchain for GCC-7.3.0 and compared the results. It seems like there is some differences in between GCC-6.3.0 and GCC-7.3.0 for the same computer and platform (I put the image on the attatchments section, “openfast_comparative.png”). Additionally to this comparison, I did a comparison for all the OpenFAST reference values (Windows/Intel, Linux/Intel, Linux/GNU) and seems that for the “accelleration” channels the differences are on the same order than the presented on “openfast_comparative.png”. So, it seems that this differences in case 9 are compiler dependent and they are not from my compilation.

On the other hand, I have done an additional test. It is a fixed wind turbine which has an initial rotational speed of 9,6 rpms and there is zero inflow wind velocity (Still condition). There is no controller. In this conditions the wind turbine should slow down its rotational speed due to air drag forces. I run this case in Windows (Github binaries) and Linux (GCC-6.3.0). When I compared the results I saw that the rotational speed and the Thrust curves has a significant difference and behaviour. I have put an attatchment (“wind_turbine_decay.png”) where I show this results. Input data are exactly the same, I copied the input folder.

Just to clarify, I do not want to find any bug in OpenFAST, it is simply that for operative reasons of the current project we are working on, we need to compare windows and linux results and we are having some differences that we need to check.

Thanks for your help

Best Regards,

Sergio


Dear Sergio,

I’m a bit surprised by your rotor speed slow down test. I would not expect such differences only as a result of differing compilers or platforms. Are you sure your using the same source code in both cases?

Best regards,