Add halo update for Lam2 in wave-enhanced ustar

[gustavo-marques]

This PR ensures that Lam2 is properly halo-updated before being used in the ustar calculation.

#418 fixed a bug in the get_param calls for STOKES_MOST and WAVE_ENHANCED_USTAR, but the tests should have failed due to the missing halo update.

This PR changes answers.

[alperaltuntas]

Thanks @gustavo-marques for this fix. There is at least two related additional issues that tests have revealed:

At line 903, Lam2(i,j) can grow large enough to trigger a floating-point overflow. I suppose this happens when Lam gets close to zero.

IIRC, the legacy wave mixing parameterization clamped the Langmuir multiplier to [1, 5]. Does the new formulation have an equivalent limiter? If not, it seems like we need something similar.

As a quick diagnostic, I capped Lam2 at 1e100 and the overflow went away. Not proposing that as the fix, just flagging that a bound does resolve the symptom.

The other issue happens in CVMix, and I'll submit an issue/PR separately.

[alperaltuntas]

Btw, to reproduce the floating point overflow issue, you may run a GW_JRA case in debug mode with the GNU compiler.

[gustavo-marques]

Thanks, @alperaltuntas!

Here is where Lam2 is calculated. This is different than the Langmuir multiplier.
I will double-check with Bill, but I think we can do something like:

Lam2_max  = 20.0      ! Recommended upper bound; Typical value assuming wind wave equilibrium is Lam2~11
CS%Lam2(i,j)   = MIN(sqrt(US_Hi(1)**2+VS_Hi(1)**2) / surfFricVel, Lam2_max)