New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#2435 (Initialisation top/bottom 'en' value in zdftke) – NEMO

Opened 3 years ago

Closed 3 years ago

#2435 closed Bug (fixed)

Initialisation top/bottom 'en' value in zdftke

Reported by: mathiot Owned by: systeam
Priority: low Milestone:
Component: ZDF Version:
Severity: minor Keywords: ZDF



It is a follow on of ticket #2406. In case of no bottom/top friction (zdfdrg), the model results are different if ln_drg is set to false or true in zdftke.


In zdftke, the MAX( zebot, rn_emin ) used to compute the bottom and top boundary condition due to drag (case ln_drg = .true. in tke namelist) leads to different result between the case:

ln_drg = .false. in zdftke and ln_OFF = .true. in namdrg ⇒ bottom boundary is 0.0 (initialisation)
ln_drg = .true. in zdftke and ln_OFF = .true. in namdrg ⇒ zebot = 0 ⇒ bottom boundary is rn_emin

I think both cases should give the same answer, however I have no idea if the value at the interface should be 0 or rn_emin. I changed MAX( zebot, rn_emin ) by zebot (ie no minimum value for 'en') and in this case both simulations gave the same results.


  • change MAX( zebot, rn_emin ) by zebot


  • initialise 'en' at top and bottom interface to rn_emin.

Commit History (1)


should solve ticket #2435

Change History (3)

comment:1 Changed 3 years ago by gm

Hi Pierre,

I totally agree with your analysis. The behavior you described is a bug that need to be fixed.

Nevertheless I suggest a slightly different fix involving not only TKE bug also GLS.

ln_drg was added to namzdf_tke when we introduce the effect of top/bot friction on TKE equation.
Now, with the changes I introduce in the management of top and bottom drag coefficient, this logical becomes obsolete.
It should be replaced by .NOT.ln_OFF .
Since ln_OFF in not public (and so its name is not explicit outside zdfdrg.F90 module, my recommandation is :

1) namzdf_tke : remove ln_drg and remove its reading/print from zdftke/zdf_tke_ini
2) zdfdrg.F90 : change ln_OFF into ln_drg_OFF and make it PUBLIC.

   LOGICAL, PUBLIC ::   ln_drg_OFF       ! free-slip       : Cd = 0

2) zdftke.F90 : change line 237 into :

      IF( .NOT.ln_drg_OFF ) THEN       !== friction used as top/bottom boundary condition on TKE

3) zdfgls.F90 : the previous switch (ln_drg was missing) but should be used :
line 21 : add the access to ln_drg_OFF

   USE zdfdrg  , ONLY : ln_drg_OFF         ! top/bottom free-slip flag

line 168-1888 should be split such that the surface friction is always computed while top/bot friction are computed only if .NOT.ln_drag_OFF as follows :

      ! Compute surface, top and bottom friction at T-points
      DO_2D_00_00                      !== surface friction
         ustar2_surf(ji,jj) = r1_rho0 * taum(ji,jj) * tmask(ji,jj,1)
 !!gm Rq we may add here r_ke0(_top/_bot) ?  ==>> think about that...
      IF( .NOT.ln_drg_OFF ) THEN       !== top/bottom friction
         !                                ! bottom friction (explicit before friction)
          zmsku = ( 2._wp - umask(ji-1,jj,mbkt(ji,jj)) * umask(ji,jj,mbkt(ji,jj)) )
          zmskv = ( 2._wp - vmask(ji,jj-1,mbkt(ji,jj)) * vmask(ji,jj,mbkt(ji,jj)) )     ! (CAUTION: CdU<0)
          ustar2_bot(ji,jj) = - rCdU_bot(ji,jj) * SQRT(  ( zmsku*( uu(ji,jj,mbkt(ji,jj),Kbb)+uu(ji-1,jj,mbkt(ji,jj),Kbb) ) )**2  &
             &                                         + ( zmskv*( vv(ji,jj,mbkt(ji,jj),Kbb)+vv(ji,jj-1,mbkt(ji,jj),Kbb) ) )**2  )
         IF( ln_isfcav ) THEN             ! top friction
               zmsku = ( 2. - umask(ji-1,jj,mikt(ji,jj)) * umask(ji,jj,mikt(ji,jj)) )
               zmskv = ( 2. - vmask(ji,jj-1,mikt(ji,jj)) * vmask(ji,jj,mikt(ji,jj)) )     ! (CAUTION: CdU<0)
               ustar2_top(ji,jj) = - rCdU_top(ji,jj) * SQRT(  ( zmsku*( uu(ji,jj,mikt(ji,jj),Kbb)+uu(ji-1,jj,mikt(ji,jj),Kbb) ) )**2  &
                  &                                         + ( zmskv*( vv(ji,jj,mikt(ji,jj),Kbb)+vv(ji,jj-1,mikt(ji,jj),Kbb) ) )**2  )


comment:2 Changed 3 years ago by clem

In 13268:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:3 Changed 3 years ago by clem

  • Resolution set to fixed
  • Status changed from new to closed
  • Version v4.0.* deleted

fixed in both trunk (from r13472) and r4.0-HEAD

Note: See TracTickets for help on using tickets.