Bug: arcsin lower bound not clamped in get_apparent_wind(), causes silent NaN

[abhinavsudhik]

THE DESCRIPTION

In direct_power_boat.py , the method get_apparent_wind() (/WeatherRoutingTool/ship/direct_power_boat.py) computes np.arcsin() for apparent_wind_angle[iang] using the arg_arcsine as the argument.
But due to the floating-point rounding , the value of the arg_arcsin can land slightly outside its range --> [-1 ,1].

This can be rectified using clamping the value back into the bounds.

But the issue is that only the upper bound is clamped and not the lower bound.

THE EFFECTS OF THIS ERROR ARE :-

--> np.arcsin() returns NaN with no exception, silently corrupting apparent_wind_angle and all values that depend on it.
--> A single NaN segment can affect any aggregation (sum/average) across the entire route.
-->If NaN is absorbed as 0 in numpy operations, fuel consumption is silently underestimated.
-->Route comparisons built on corrupted estimates can select a worst route as optimal.
-->hard to debug.
-->Exported CSVs or JSON logs containing NaN break downstream data pipelines and monitoring tools.

THE CODE WHICH HAS THE ERROR IS :-

diff_to_one = arg_arcsin - 1 * u.radian
if diff_to_one > 0:
    assert diff_to_one < 0.000001 * u.radian
    arg_arcsin = 1 * u.radian```

[RitikaSen27]

Hi! I’d like to work on this issue.

My plan is to clamp the arg_arcsin value to the valid domain [-1, 1] before calling np.arcsin() to prevent NaN values caused by floating-point rounding. I’ll ensure both the upper and lower bounds are handled consistently.

Please let me know if there are any preferred constraints or testing requirements for this fix.

[RitikaSen27]

Hi! I’ve implemented a fix that clamps the argument of np.arcsin() to the valid range [-1, 1] to prevent NaN values caused by floating-point rounding.

PR: #176

[shreyadesai20042009]

Hi, I noticed that multiple fixes have been proposed.

I suggest using np.clip() instead of manual checks, as it ensures both bounds are handled cleanly and reduces code complexity.

Would you prefer this approach?

[harinimuthuu-del]

he issue was caused by floating-point rounding errors allowing arg_arcsin to slightly exceed the valid domain of np.arcsin() (i.e., [-1, 1]). While the upper bound was partially handled, the lower bound was not, leading to potential NaN values and silent corruption of downstream calculations.

This has been resolved by clamping arg_arcsin to the valid range using np.clip, ensuring numerical stability and preventing NaN propagation.

arg_arcsin = np.clip(arg_arcsin, -1 * u.radian, 1 * u.radian)
apparent_wind_angle[iang] = np.arcsin(arg_arcsin)

This fix ensures:

Valid input to np.arcsin()
Prevention of silent NaN generation
More reliable route and fuel computations