FAST.Farm: fix indexing on dropping wake planes that get dropped

[andrew-platt]

Ready to merge

Feature or improvement description
If a FAST.Farm wake plane passes another, an error in the indexing was causing the wake plane getting passed to be dropped, but also causing the very last wake plane to get dropped as well. This would result in the end of the wake jumping backwards whenever a wake was dropped from the middle of the sequence.

https://github.com/user-attachments/assets/6ad85fa8-2cc7-4208-bd20-b7a4748af6fd
Figure 1: single turbine case before bugfix.

https://github.com/user-attachments/assets/5a3ac9c8-aa62-4de2-b0b8-8cc58cc2ab46
Figure 2: single turbine case after bugfix. Note the artifacts from the first wake plane - these will be addressed in a separate PR.

In the above simulations, the fast moving plane that is catching up to a slower moving plane is dropped. This could be modified in a later PR.

In addition to fixing the above issue, a couple other minor modifications are included in this PR:

• in calculating MaxNumPlanes, increased coefficient from 15 to 30. One of the test cases run during diagnostics unexpectedly hit this limit. The calculation itself should be looked at sometime as it doesn't appear to account for the low res timestep between planes, which is likely why this limit was hit.. Will diagnose this later
• changed NumDFull and NumDBuff from integer to real. There was no reason for these to be integers.

Related issue, if one exists
#3277 -- this was due to this bug

Impacted areas of the software
FAST.Farm wake, but only in cases where the simulation is setup poorly and wake planes are passing each other and getting dropped as a result.

Additional supporting information
Note that the are some strange artifacts in the first plane. These will be corrected in different PR.

Generative AI usage
Bug diagnostics assisted by Anthropic Claude claude@anthropic.com

Test results, if applicable
Regression tests are properly setup, so they did not show this behavior,

[andrew-platt]

This bug was introduced in #3071

[jjonkman]

I'm not sure I fully understand why 15 was changed to 30 when calculating MaxNumPlanes, but the derivation of the original equation is included in the implementation plan FAST.Farm_PLan_WakeExtentAndBuffering_Rev2.docx. Effectively, DT_Low cancels out. A safety factor of 1.25 was used originally, but increasing to 30 effectively doubles this to 2.5, which sounds excessive to me.

What is causing the issue with the initial plane? How is this case set up to have step change in wake response? The wake solution looks odd to me overall, but perhaps the turbine operation set-up is odd?

[andrew-platt]

@luwang00 and I weren't entirely sure where the 1.25 came from. I'll change the 30 back to 15 to keep in line with the original derivation.

I'm still tracking down the issue with the initial plane. I suspect an uninitialized variable someplace - we see different results for certain vtk points depending on compilation with gcc, but no notable issues with intel (double precision giving NaN or 6 digit velocity values, and single precision giving closer to reasonable outlier garbage for the same points). This appears only on the first timestep, and gradually clears up on later timesteps (some artifacts still persist for a long time due to wake interactions). Since that's a completely separate issue from this one, I'll track it down separately and address it with a separate PR.

[andrew-platt]

There are also oddities in this particular setup. But it is highlighting some issues we should fix anyhow.