Context

the minimum domain size was defined to 4*nn_hls, it cant be reduced to 3*nn_hls

Analysis

This change will allow 1d configurations and "slab configurations" such as OVERFLOW or LOCK_EXCHANGE to run with nn_hls = 1, 2 or 3

Fix

replace 4 by 3 and add a clean error message when the domain is too small for the value of nn_hls we want to use.

Context

There is still implicit loops in dynspg_ts that are using jpim1/jpjm1. This creates errors (in debug mode) when nn_hls > 1. I thought these variables should no more be used in the code...

Analysis

in

zhU(1:jpim1,1:jpj  ) = e2u(1:jpim1,1:jpj  ) * ua_e(1:jpim1,1:jpj  ) * zhup2_e(1:jpim1,1:jpj  )   ! not jpi-column

we use zhup2_e(1:jpim1,1:jpj ) that was computed above in a DO_2D( 1, 0, 1, 1 ) loop. => zhup2_e not defined in jpj when nn_hls = 2

Recommendation

suppress jpim1 et jpjm1 from the code!

The ocean temperature trend coming from isf melting is wrong when cavities are closed and melting is parameterized. The part that is wrong is the sensible flux, so I guess it was undetected since it is small wrt latent heat flux. Moreover the way this trend is written is extremely confusing. In the following, I try to explain the best I can.

If I understand correctly, the ocean temperature "trend" must be written as: fwf * (cp*T-Lfus) / (rho*cp) in degC*m/s, with fwf being the positive freshwater, T the freezing temperature and Lfus the latent heat of fusion. Hence melting is responsible for cooling the surrounding ocean. In ISF routines, there are two ways of defining temperature "trend": in isfcav.F90 if the cavity is open or in isfpar.F90 if the cavity is closed and melting is parameterized. Sign is opposite in the two routines and if I did my maths ok, I end up with temperature trends as: fwf * (cp*T-Lfus) / (rho*cp) for isfcav => ok fwf * (-cp*T-Lfus) / (rho*cp) for isfpar => not ok (sensible flux has the wrong sign)

In details, in isfcav.F90 the temperature trend is defined as:

zqh(:,:) = ( zqhc (:,:) + zqoce(:,:) )
...
! set temperature content
ptsc(:,:,jp_tem) = -zqh(:,:) * r1_rho0_rcp

with qhc (sensible flux) and qoce (latent flux) defined in isfcavmlt.F90 (here for specified melt):

pqfwf(:,:) = - sf_isfcav_fwf(1)%fnow(:,:,1)      ! fwf                ( >0 out)
pqoce(:,:) = - pqfwf(:,:) * rLfusisf             ! ocean heat flux    ( >0 out)
pqhc (:,:) =   pqfwf(:,:) * ztfrz(:,:) * rcp     ! heat content flux  ( >0 out)

In isfpar.F90 the temperature trend is defined as:

zqh(:,:) = ( zqhc (:,:) + zqoce(:,:) )
...
! set temperature content
ptsc(:,:,jp_tem) = zqh(:,:) * r1_rho0_rcp

with qhc and qoce defined in isfparmlt.F90 (here for specified melt):

pqfwf(:,:) = - sf_isfpar_fwf(1)%fnow(:,:,1)      ! fresh water flux from the isf (fwfisf <0 mean melting) 
pqoce(:,:) =   pqfwf(:,:) * rLfusisf             ! ocean/ice shelf flux assume to be equal to latent heat flux
pqhc (:,:) =   pqfwf(:,:) * ztfrz(:,:) * rcp     ! heat content flux 

I see a couple of other problems: 1) Signs are confusing (not the same between isfpar and isfcav). 2) The freshwater flux (qfwf or fwfisf) is negative when melting. It does not really follow the nemo general rule of having positive runoffs.

Fix

Correcting temperature trend and solving point 1) is pretty easy. Solving point 2) is much harder since isf freshwater is used in many places of the code and we do not have configurations to test all of the options. I recommend to first correct the temperature trend, then solve the signs confusion and maybe change the sign of freshwater flux