[BugFix] WrVTK with VTK_fps fails

[andrew-platt]

Ready to merge

Feature or improvement description
If WrVTK is non-zero, setting VTK_fps=0 causes a failure as follows:

  Time: 0 of 6 seconds.
At line 321 of file /Users/aplatt/software-development/GitHub/openfast-5/modules/nwtc-library/src/ModMesh.f90
Fortran runtime error: Nonnegative width required in format
(i-5.-5)
   ^

Error termination. Backtrace:
#0  0x103f22d2f
#1  0x103f238d7
#2  0x103f241a7
#3  0x10400a48b
#4  0x104019b0f
#5  0x102eac47b
#6  0x1022d301f
#7  0x1022d7acf
#8  0x1022ec2cf
#9  0x1022ec5f7
#10  0x1021c9e53
#11  0x102f6671f

The intent of VTK_fps=0 was to output at T=0 and at the last step of the simulation. However, due to the way it was setup, this wasn't working due to a negative value for the field width for the time step in the VTK filenames. Internally the math for calculating the width was as follows:

      if ( EqualRealNos(p%VTK_fps, 0.0_DbKi) ) then
         TmpTime = p%TMax + p%DT
...
      ... IF (TmpTime > p%TMax) THEN
         p%n_VTKTime = HUGE(p%n_VTKTime)
...
 p_FAST%VTK_tWidth = CEILING( log10( real(p_FAST%n_TMax_m1+1, ReKi) / p_FAST%n_VTKTime ) ) + 1

which evaluated to CEILING( log10( 2000 / 2147483647 )) + 1 = -5 causing the format failure.

This has been corrected so that now p%n_VTKTime = NINT( p%TMax / p%DT ) giving VTK_tWidth will evaluate to 1 and triggering VTK writes at the last time step.

Related issue, if one exists
#2827

Impacted areas of the software
VTK outputs only when VTK_fps=0

Test results, if applicable
No results change

[rafmudaf]

I'm curious what the context was for the existing form. With the HUGE denominator, the argument to log10 will practically always be less than 1, so the result of that will practically always be negative. That seems intentional - what do you think @andrew-platt?

I agree that the NINT form is the fix for the problem I mentioned, but I'm wondering if this has a side effect if something else was expecting the other form for p_FAST%n_VTKTime.

[rafmudaf]

Also thanks for fixing this so quickly!

[andrew-platt]

Looking at the history, I'm a bit suspicious that something merged incorrectly in those sections of code when the FSI CFD coupling was added. So I suspect that the original functionality was to do T=0 and the ending time step, but a bad merge clobbered that and we didn't notice until now (there were a lot of merge conflicts in that integration).