Compiling in double precision

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,

I have a problem with running FAST which is as below:

WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 25
VNW = 17.794, VNB = -101.75
WARNING: Small angle assumption violated in SUBROUTINE SmllRotTrans() due to
a large platform displacement. The solution may be inaccurate. Simulation continuing, but future
warnings will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans(): 0.1 s
WARNING: High VNB velocity encountered during induction factor calculation.
Blade number 1, Element number 1
VNW = 18.062, VNB = 25718
WARNING: High VNB velocity encountered during induction factor calculation.
Blade number 1, Element number 2
VNW = 18.714, VNB = 24651
WARNING: Blade #1 element #2 is supersonic! Other elements are likely supers
onic as well.
Supersonic mach nos. will be set to 0.7 to attempt continuation.
WARNING: High VNB velocity encountered during induction factor calculation.
Blade number 1, Element number 3
VNW = 19.298, VNB = 23394
WARNING: High VNB velocity encountered during induction factor calculation.
Blade number 1, Element number 4
VNW = 19.777, VNB = 21627
WARNING: Induced velocity warning written 5 times. The message will not be r
epeated, though

I had an investigation through FAST inputs and it’s what I get as a conclusion:

The compile is done by using IVF and command “Compile_FAST.bat dll”

In UserSubs_forBladedDLL.f90 the only subroutine which is activated is UserPtfmLd
In UserPtfmLd subroutine there are two matrices including stiffness and damping as following

Damp (1,:slight_smile: = (/ 545000000.0, 0.0, 0.0, 0.0, 0.0, 0.0 /)
Damp (2,:slight_smile: = (/ 0.0, 545000000.0, 0.0, 0.0, 0.0, 0.0 /)
Damp (3,:slight_smile: = (/ 0.0, 0.0, 911000000.0, 0.0, 0.0, 0.0 /)
Damp (4,:slight_smile: = (/ 0.0, 0.0, 0.0, 30800000000.0, 0.0, 0.0 /)
Damp (5,:slight_smile: = (/ 0.0, 0.0, 0.0, 0.0, 30800000000.0, 0.0 /)
Damp (6,:slight_smile: = (/ 0.0, 0.0, 0.0, 0.0, 0.0, 22300000000.0 /)

Stff (1,:slight_smile: = (/ 56300000000.0, 0.0, 0.0, 0.0, 0.0, 0.0 /)
Stff (2,:slight_smile: = (/ 0.0, 56300000000.0, 0.0, 0.0, 0.0, 0.0 /)
Stff (3,:slight_smile: = (/ 0.0, 0.0, 64200000000.0, 0.0, 0.0, 0.0 /)
Stff (4,:slight_smile: = (/ 0.0, 0.0, 0.0, 6590000000000.0, 0.0, 0.0 /)
Stff (5,:slight_smile: = (/ 0.0, 0.0, 0.0, 0.0, 6590000000000.0, 0.0 /)
Stff (6,:slight_smile: = (/ 0.0, 0.0, 0.0, 0.0, 0.0, 8770000000000.0 /)

By dividing the matrices by 10 (means that reducing order of numbers by 1) the simulation is run properly without any error. Also I checked reducing order of numbers by 2 and made it work without any error.

What I supposed to solve the problem is compiling in double precision instead of single precision. Therefore my question is regarding how to change to double precision and would it solve my problem? Is my conclusion right about source of error?

Regards,

2

I’d be surprised if the problem is caused by running in single precision. I’m guessing your model is going unstable for other reasons. Have you tried making the FAST time step smaller?

That said, if you want to investigate the problem by using double precision in FAST v7, you need to make a couple of modifications to the Compile_FAST.bat file:

  1. change “SingPrec.f90” to “DoubPrec.f90” in the list of NWTC Library files and
  2. change “/real_size:32” to “/real_size:64” in the definition of variable COMP_OPTS
3

Thanks a lot dear Jonkman

I did the compile with double precision and it didn’t solve my problem. Instead by reducing the time step from 0.0125 to 0.0025 and single precision, the error has gone.
In past, DecFact was 10 (output every time step), now by reducing time step to 0.0025, is it necessary to keep the DecFact in 10 or could it be changed to 50 in order to reducing cpu time without lost in precision?

4

Dear Feizbakhshi,

It sounds like you introduced a high stiffness (and thus natural frequency) in your model, which requires a smaller time step for the solution to remain numerically stable.

Input DecFact will not impact the simulation time much at all. DecFact only controls the rate at which the results are written to the output file (DecFact = 1 = once per step, DecFact = 10 once every 10 time steps). DecFact has a strong influence on the size of the output file.

Best regards,

5

Hi,

I got the same error messages as discussed above when simulating a floating 10MW turbine. The warning came from AeroDyn, it was proved by disabling AeroDyn and the simulation worked well.
According to the previous suggestions, I tried to reduce the time step to 0.001 and it didn’t work. I was guessing if it is caused by the high platform yaw frequency, so I disabled platform yaw DoF in ElastoDyn, the simulation than went well and terminated normally. To reduce the yaw frequency, I trued to decrease the additional yaw stiffness and increase the additional linear damping in HydroDyn, but the crush happened again as before with the supersonic blade warning.

I would appreciate it if you can give suggestions regarding to the problem I met.

Regards,
Yajun

6

Dear Yajun,

I doubt a floating platform would have a very high platform-yaw natural frequency, at least physically. I would guess there something not set up properly with your floating platform model, but it is difficult for me to guess as to what that would be.

Does the model give you results that you expect in terms of rotor response when you’ve disabled the platform DOFs?

Does the model give you results that you expect in terms of platform response when you enable the platform DOFs, but park the rotor and disable aerodynamics?

Best regards,

7

Dear Jason,

Thank you for your reply.

When I disabled the Platform DOF, the rotor responses seem reasonable. When I parked the rotor with all DOFs enabled, the platform motions are good to me. Only when the rotor worked with freely floating platform, the crush happened.

best regards,
Yajun

8

Dear Yajun,

Do you get the results you expect when you disable the generator DOF (GenDOF = False)? If so, perhaps the turbine controller you are using is not appropriate for floating wind applications?

Best regards,

9

Dear Jason,

I do get the ecpected result when disable the DoF of generator.

I also ever doubted if it was the controller problem. The controller I used is NREL’s Reference OpenSource Controller (ROSCO) for the DTU 10MW wind turbine. However, when I tried NAUTILUS FAST model from [url]Files · master · DTU 10MW RWT / dtu-10mw-rwt · GitLab, the program worked well. The crush came out only when I changed the ElastoDyn and HydroDyn file for a scaled spar model. That was the reason that I doubt if it is the platform frequency problem.

Best regards,
Yajun

10

Dear Yajun,

I would guess that the controller gains need to be updated for the new floating platform you are using.

Best regards,

11

Dear Jason,

When I disabled the pitch control (PCMode = 0) and set variable speed control to simple VS (VSContrl = 1), I still got the same error. Does this still refer to a controller problem?

Best regards,
Yajun

12

Dear Yajun,

Have you set the variable speed control parameters (VS_RtGnSp, VS_RtTq, VS_Rgn2K, VS_SlPc) appropriately for your turbine? Does your simulation not require pitch control (i.e., you are only simulating below-rated conditions)?

You haven’t really provided enough information to offer specific advice.

Best regards,

13

Dear Jason,

According to the information for DTU 10MW wind turbine which is the turbine model I used, I set VS_RtGnSp = 480, VS_RtTq = 1560000 and VS_RtTq = VS_RtTq = 0.001.

I set disabled the pitch control only for checking if the problem comes from pitch control, I ever guessed if it was the blade pitch frequency resonant with the structure natural frequency.

Sorry for the lack of information, please let me know if you need any other information for advising.

Best regards,
Yajun

14

Dear Yajun,

I don’t think the values you are using for the variable-speed controller parameters make sense. I would expect VS_RtGnSp*VS_RtTq to equal approximately 10 MW, but I don’t see that in your results. Also, you seem to have a typo in your e-mail because you define VS_RtTq three times.

Best regards,