Gauss velocity deficit fails with 0 m/s inflow

[mr483]

Simple gauss fails at 0 m/s

If you run the Gauss velocity deficit model without secondary_steering, yaw_added_recovery, enable_transverse_velocities, the model returns NaN when you provide an inflow of 0 m/s.

How to reproduce

I took the gch.yaml in the inputs folder, and changed:

  # Can be "true" or "false".
  enable_secondary_steering: false

  ###
  # Can be "true" or "false".
  enable_yaw_added_recovery: false

  ###
  # Can be "true" or "false".
  enable_transverse_velocities: false

Then, a simple script:

fmodel = FlorisModel("inputs/gch.yaml")
fmodel.set(layout_x=[0, 500.0], layout_y=[0.0, 0.0],wind_directions=np.array([270.0]), wind_speeds=[0])
fmodel.run()
turbine_powers = fmodel.get_turbine_powers() / 1000.0

Relevant output

turbine_powers returns nan for each of the two turbines, rather than expected 0.

The problem is coming from :
sigma_z0 = rotor_diameter_i * 0.5 * np.sqrt(uR / (u_initial + u0))

which returns nan when u_initial and u0 are 0.

Floris version

FLORIS v4.2.2 (actually discovered the issue in older version, but then separately installed 4.2.2 and saw it still exists).

[Bartdoekemeijer]

Hi @mr483,

Thanks for flagging this. It's something I have encountered in the past too. The wake models were implemented according to their quite literal mathematical equations. Like you rightfully pointed out, in those equations there is no exception for the wind_speed = 0.0 case, and indeed the mathematics return a nan rather than a 0.0. I think NREL is trying to avoid implementing edge cases or unique rules as much as possible, and instead rely on the mathematics. Hence, nan might just be the desired behavior, even though I agree it can be painful/annoying to work around. Something easy you can do is just add a small epsilon to your wind speeds.

So for the wind_speed = 0.0 case, use wind_speed = 1.0e-8. This should give you the same result but circumvents the divide by zero problem. Alternatively, you can just circumvent FLORIS altogether and avoid running the wake model for such low wind speeds, already knowing that the result will be zero. This is going to save you in computation time as well.

Curious to hear what the NREL colleagues think of this!

[misi9170]

Hi @mr483 , @Bartdoekemeijer , thank you for raising this issue and just pointing out that I've started a discussion on this topic as part of a larger topic on NaN handling over in #1076.