FAST - Tmax < 9999.999 seconds; need 3 hrs

Hi Jason,

I understand that starting in version v6.02c-jmj, you added an upper limit of 9999.999 seconds (2.77 hours) to the input parameter TMax in order to avoid an overflow problem in the output file. What is the overflow problem? If I wanted to do 3-hour long simulations with the 5MW Spar Buoy-Supported Floating Offshore Wind Turbine, how would I do that?

I tried and increased the limit on Tmax in FAST_IO.f90 to a bigger number, say 120000 (see below) and recompiled FAST.

IF ( ( TMax < 0.0 ) .OR. ( TMax > 12000.0 ) ) CALL ProgAbort ( ’ TMax must be between 0.0 and 12000.000 (inclusive).’ )

When I put in a Tmax that is greater than 9999.999s, FAST runs fine with a normal sea state (e.g. V = 6.30 m/s; Hs = 0.50 m; Tp = 8.77 s) but crashes with a more severe sea-state (e.g. V = 14.69 m/s; Hs = 8.50 m; Tp = 16.19 s) when the time passes 9999.999 seconds. Please refer to the error message below. The warning on the violation of small angle assumption does not appear until time passes 10000 seconds. Does this warning have anything to do with the 9999.999s time limit? Do you think if there is some kind of numerical instability before FAST crashes? As I mentioned above, in a less severe sea-states, FAST can finish 3hr-long simulations without problems, however in the output, the time column displays ******** for time > 9999.999 seconds.

Please give me some advice

Thank you for your support

Error message
Timestep: 9975 of 10860 seconds. Estimated final completion at 14:42:43.
Timestep: 10000 of 10860 seconds. Estimated final completion at 14:40:59.

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
Timestep: 10025 of 10860 seconds. Estimated final completion at 14:40:10.
Error FF wind array boundaries violated: Grid too small in Y direction. Y=70.031; Y boundaries =
[-70, 70]

Error getting velocity in AeroDyn/AD_WindVelocityWithDisturbance().

Aborting FAST.

Dear Hieu,

The “overflow problem in the output file” just means that the field isn’t large enough to display values larger than “9999.999” seconds. If you have a larger number, it will print ‘**********’ instead (as you noticed when you removed the limit).

However, I do not believe that 9999.999-s limit is the direct cause of the instability you see. I would guess that the large simulation time exceeds the limits of single-precision arithemetic. For instance, we have seen that some controllers get called multiple times per time step after the time gets somewhere in the 800-1000-s range. For now, I’d recommend that you recompile in double precision (use DoubPrec.f90 instead of SingPrec.f90 from the NWTC Library, and add the compile-option /real_size:64).**

[size=85]**If you have a large full-field turbulent wind file, compiling in double precision may also cause you to exceed the 2GB of memory allowed in a single 32-bit process in Windows. To get around that issue, you can use a 64-bit version of the compiler (and keep in mind that any DLLs called by the 64-bit executable must also have been compiled with a 64-bit version of the compiler). [/size]

Dear Bonnie,

Thanks so much for your reply. I did try double precision option and FAST gave me same results, i.e. numerical instability after t = 9999.999 seconds. I mentioned in previous post that with normal sea-states (less severe), FAST can finish the 3-hr simulations without crashing; however when I took a close look at response time series, I noticed too numerical instability. I am not sure where the problem is. I would really appreciate it if someone could try similar 3-hr simulations with the same wind turbine model and report the results.

Thank you!