Restart inconsistencies when coupling water level (sea surface height analogon) to wave model

Hi everyone,

I recognized some restart inconsistencies in the results external wave model when coupling the sea surface height / water level from NEMO to it via OASIS, if ln_apr_dyn=.true.. (which also will feedback to NEMO if other fields are two-way coupled!)

As I understand the “water level” (O_Wlev) is used as a ssh analogon for the wave coupling. Checking the code (OCE/SBC/sbccpl.F90, l.2725), I see that:

! ! ------------------------- !
! ! Water levels to waves !
! ! ------------------------- !
IF( ssnd(jps_wlev)%laction ) THEN
IF( ln_apr_dyn ) THEN
IF( kt /= nit000 ) THEN
ztmp1(:,:) = ssh(:,:,Kbb) - 0.5 * ( ssh_ib(:,:) + ssh_ibb(:,:) )
ELSE
ztmp1(:,:) = ssh(:,:,Kbb)
ENDIF
ELSE
ztmp1(:,:) = ssh(:,:,Kmm)
ENDIF
CALL cpl_snd( jps_wlev , isec, RESHAPE ( ztmp1, (/jpi,jpj,1/) ), info )
ENDIF

As one can see, the inconsistencies arise from the additional if-condition (IF( kt /= nit000 ) THEN ... ELSE ...), which results in different treatment at coldstarts and restarts. For restarts this results in different ssh values sent to OASIS than for a continous run.

I ran my coupled test setup with ln_apr_dyn=false to ensure this solves the inconsistencies. Longrun and interval results are numerically consistent. Check.

Proposed solution 1: Generalize by removing the IF(kt/=nit000)-condition, as it is done for the internal OCE-SAS coupling for the ssh right after the water level (l. 2740):

!
! Fields sent by OCE to SAS when doing OCE<->SAS coupling
! ! SSH
IF( ssnd(jps_ssh )%laction ) THEN
! ! removed inverse barometer ssh when Patm
! forcing is used (for sea-ice dynamics)
IF( ln_apr_dyn ) THEN ; ztmp1(:,:) = ssh(:,:,Kbb) - 0.5 * ( ssh_ib(:,:) + ssh_ibb(:,:) )
ELSE ; ztmp1(:,:) = ssh(:,:,Kmm)
ENDIF
CALL cpl_snd( jps_ssh , isec, RESHAPE ( ztmp1 , (/jpi,jpj,1/) ), info )
ENDIF

This shows to me that in principle no extra treatment for kt==nit000 is required. I tested this for the “wave water level” and it fixes the restart inconsistencies! So there seems to be no numerical initialization argument for this extra treatment.

Proposed solution 2: Limit the extra treatment to coldstarts only by changing the condition to kt>1 instead of nit000. However, since coldstarts need a spin-up anyways, I wonder if ths would be necesarry.

Right now, I am wondering:

  1. What is/was the reason for the same-same-but-different definitions of the internal ssh and the ssh-analog “water level” for wave coupling? Numerically or physically?
  2. What is/was the reason for the extra treatment for kt==nit000 for the wave-coupled water level? Especially, why is does it not apply to OCE-SAS coupling?

Based on those reason(s), one could then decide for the most appropriate solution.

Thanks,
Robert