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

**URL:** <https://nemo-ocean.discourse.group/t/restart-inconsistencies-when-coupling-water-level-sea-surface-height-analogon-to-wave-model/774>\
**Category:** v4.2.x\
**Tags:** OASIS, SBC\
**Created:** [25 October 2024 10:28 UTC](https://nemo-ocean.discourse.group/t/restart-inconsistencies-when-coupling-water-level-sea-surface-height-analogon-to-wave-model/774 "2024-10-25T10:28:27Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![r-hartmann](https://avatars.discourse-cdn.com/v4/letter/r/59ef9b/32.png) [@r-hartmann](https://nemo-ocean.discourse.group/u/r-hartmann)\
**Post date:** [25 October 2024 10:28 UTC](https://nemo-ocean.discourse.group/t/restart-inconsistencies-when-coupling-water-level-sea-surface-height-analogon-to-wave-model/774/1 "2024-10-25T10:28:27Z")

</div>

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