Opened 3 years ago

Closed 3 years ago

#2096 closed Bug (fixed)

coastline value of u-, v-tau in presence of sea-ice

Reported by: mathiot Owned by:
Priority: low Milestone: 2018 release-4.0
Component: OCE Version: release-3.6
Severity: minor Keywords: stress, LIM*
Cc: Branch review:
MP ready?: Task progress:

Description (last modified by nicolasmartin)


ocean surface stresses are unmask along coastlines. It seems to be needed for zdftke at least. In case of sea ice, the coastline value (on land) in some places is very different to the adjacent value (on water), especially in area with concentration close to 1. It is because the sea ice concentration interpolated at u- and v-points along coastlines is computed using sic land value (0 I think) in the averaging.



I suggest to do a weighted average using tmask(:,:,1) to compute the sic at u- and v- points in iceupdate (trunk) and sbclim, sbclim_2 (nemo_3.6).
It means replace :

zat_u  = ( at_i(ji,jj) + at_i(ji+1,jj) ) * 0.5_wp   ! ice area at u and V-points
zat_v  = ( at_i(ji,jj) + at_i(ji,jj+1) ) * 0.5_wp


! ice area at u and v-points
! land values on u-, v- points along coastline set to adjacent t-point ocean value 
zat_u  = ( at_i(ji,jj) * tmask(ji,jj) + at_i(ji+1,jj  ) * tmask(ji+1,jj  ) ) / MAX(1.0_wp,tmask(ji,jj)+tmask(ji+1,jj  ))
zat_v  = ( at_i(ji,jj) * tmask(ji,jj) + at_i(ji  ,jj+1) * tmask(ji  ,jj+1) ) / MAX(1.0_wp,tmask(ji,jj)+tmask(ji  ,jj+1))

Commit History (2)


v3.6 correction of ticket #2096


trunk correction of ticket #2096

Change History (4)

comment:1 Changed 3 years ago by nicolasmartin

  • Description modified (diff)

comment:2 Changed 3 years ago by mathiot

In 9774:

trunk correction of ticket #2096

comment:3 Changed 3 years ago by mathiot

In 9778:

v3.6 correction of ticket #2096

comment:4 Changed 3 years ago by mathiot

  • Resolution set to fixed
  • Status changed from new to closed

There was a bug in the suggested fix committed this morning (r9774 and r9778). Thank you Clement. tmask is obviously 3d not 2d. Cray compiler catches it as a warning not an error and assume it is the first level. So compilation and execution went fine. It is now fixed in r9782 (trunk) and r9783 (v3.6).

Note: See TracTickets for help on using tickets.