Resolution scaling not applied to KHTR output?

[iangrooms]

In the output of our G cases resolution scaling is being applied to KHTH (GM) but not to KHTR (Redi). See below for the time-mean of the two coefficients (at the surface) for a run with RESOLN_SCALED_KHTR = True: Top=GM, Bottom=Redi. (Some differences are because they have a different minimum value. Don't be distracted by that: focus on the tropics). Our standard setting is RESOLN_SCALED_KHTR = True so resolution scaling should be applied to KHTR. I have run a case for 5 days with RESOLN_SCALED_KHTR = True and with RESOLN_SCALED_KHTR = False and the results are different. So I expect that resolution scaling is being applied to KHTR online, but it is not being applied to the diagnostic output.

[mnlevy1981]

I was poking around MOM_tracer_hor_diff.F90, trying to follow the changes made when Resoln_scaled=True. It looks like it modifies Kh_u, but then later in the module there's a block of code that could overwrite the effect of Resoln_scaled=True in some columns:

    if (CS%max_diff_CFL > 0.0) then
      if ((CS%id_KhTr_u > 0) .or. (CS%id_KhTr_h > 0)) then
        !$OMP parallel do default(shared) private(khdt_max)
        do j=js,je ; do I=is-1,ie
          khdt_max = 0.125*CS%max_diff_CFL * min(G%areaT(i,j), G%areaT(i+1,j))
          if (khdt_x(I,j) > khdt_max) then
            khdt_x(I,j) = khdt_max
            if (dt*(G%dy_Cu(I,j)*G%IdxCu(I,j)) > 0.0) &
              Kh_u(I,j,1) = khdt_x(I,j) / (dt*(G%dy_Cu(I,j)*G%IdxCu(I,j)))
          endif
        enddo ; enddo

Note the last line before the endif / enddo ; enddo: Kh_u(I,j,1) = khdt_x(I,j) / (dt*(G%dy_Cu(I,j)*G%IdxCu(I,j))). Since this is not an additive effect, this would replace whatever value of Kh_u was set based on RESOLN_SCALED_KHTR. For that first if statement, CS%max_diff_CFL is the following variable from MOM_parameter_doc.all:

MAX_TR_DIFFUSION_CFL = 2.0      !   [nondim] default = -1.0

So by default the Kh_u(I,j,1) = khdt_x(I,j) / (dt*(G%dy_Cu(I,j)*G%IdxCu(I,j))) line would never run, but given the CESM defaults it will be updated when G%dy_Cu(I,j)*G%IdxCu(I,j) is positive. Anyway, my suggestion would be to run with RESOLN_SCALED_KHTR and MAX_TR_DIFFUSION_CFL = -1 in user_nl_mom and see if that makes a difference in the plots above.

[iangrooms]

I ran it for a month with RESOLN_SCALED_KHTR = True and MAX_TR_DIFFUSION_CFL = -1. Still doesn't look like it's applying the resolution function. KHTH has a big blue band around the equator, like in the top plot (not shown).

[iangrooms]

I noticed that the GM implementation uses the resolution function at u and v points, while the Redi implementation uses the resolution function at h points. This was suspicious, so I modified the code here and here to use VarMix%res_fn_{u,v} directly instead of interpolating ``VarMix%res_fn_h` to the edges. This led to the following diagnostic output for the Redi coefficient (KHTR; colorscale below is different from above - 'detail' colormap in ncview skewed towards low values):

So it appears that the resolution function is not being applied to KHTR; it's not just an output/diagnostics problem.

A PR with this change is coming soon.

[gustavo-marques]

Was the problem caused by Res_fn_h not being set correctly?

[iangrooms]

I haven't figured that out yet. Regardless of the underlying problem with Res-Fn_h I think it makes sense to replace interpolation from centers to edges in MOM_tracer_hor_diff.F90 with values at edges that are already computed in the VarMix struct, but I should also try to track down and fix the underlying problem. It would be good to have a more complete solution, but given the short timescale for CESM3 I wanted to put up a quick fix too.

[iangrooms]

The resolution function is computed in MOM_lateral_mixing_coeffs.F90. It is calculated at h, q, u, and v points. There's some strange logic going on here.

• The value at h and q points is computed using the VISC_RES_FN_POWER and VISC_RES_SCALE_COEF values, which are 6 and 0.4 in our standard configuration.
• The value at u and v points is computed using the KH_RES_FN_POWER and KH_RES_SCALE_COEF values, which are 6 and 0.9 in our standard configuration.
• Before my PR KHTR resolution scaling #400, the values at h and q points are used to scale both lateral harmonic viscosity and the Redi coefficient. The values at u and v points are used to scale the GM coefficient.
• If you set INTERPOLATE_RES_FN = True (we set it to False), it will compute the resolution function at h points using VISC_RES_FN_POWER and VISC_RES_SCALE_COEF and then interpolate to the u and v points, then use it for GM.

At the moment there are three things that you might want to scale - GM, Redi, and lateral viscosity - and two scaling functions. You can use a different scaling function for GM from the function used for the other two, but lateral viscosity and Redi use the same scaling function. (You can elect to scale Redi but not viscosity and vice versa, but you can't use a different scaling function for Redi and viscosity.)

In our current configuration the GM scaling function reduces the coefficient by an extra factor of 100 at the equator, as compared to the Visc/Redi scaling function. So that probably explains why, when comparing GM and Redi coefficients, I thought the scaling was not being applied to Redi.

[iangrooms]

The documentation is incorrect. It says

Symbol	Module parameter
$\alpha $	KH_RES_SCALE_COEF (for thickness and tracer diffusivity)
$p $	KH_RES_FN_POWER (for thickness and tracer diffusivity)
$\alpha $	VISC_RES_SCALE_COEF (for lateral viscosity)
$p $	VISC_RES_FN_POWER (for lateral viscosity)

#439 fixes this by changing it to

Symbol	Module parameter
$\alpha $	KH_RES_SCALE_COEF (for thickness diffusivity)
$p $	KH_RES_FN_POWER (for thickness diffusivity)
$\alpha $	VISC_RES_SCALE_COEF (for lateral viscosity and tracer diffusivity)
$p $	VISC_RES_FN_POWER (for lateral viscosity and tracer diffusivity)