New URL for NEMO forge!   http://forge.nemo-ocean.eu

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.
Custom Query – NEMO

Custom Query (2547 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (61 - 63 of 2547)

Ticket Resolution Summary Owner Reporter
#2642 fixed possible bugs: salflx output unit and ln_rnf_icb has no effect systeam mathiot
Description

Context

  • unit of the saltflx variable is in 1e-3/m2/s in field_def_oce.xml. I wonder if it should be instead in 1e-3.kg/m2/s as specified in the comments of ice.F90 for the variable sfx ?
  • I am not convince the icb climatology is used. icb climatology is read in sbcrnf in fwfisf, output as iceberg_cea or hflx_icb_cea (latent heat) but I am unable to find where this is added to rnf or emp in a forced simulation. If cpl, there is in sbccpl a line rnf = rnf + fwfisf. I did a try with ORCA2 and I have the same result whatever the value of ln_rnf_icb.
  • more general question/comments on ln_rnf_icb: I found confusing that the definition of the iceberg climatology is done in the runoff namelist instead of the icb namelist. A master flag ln_icb with ln_icb_clim for the use of the climatology and ln_icb_lagr for the use of the icb lagragian model is maybe more logical. This point could be discussed at the same time of the ticket #2467.

Analysis

It affect NEMO 4 and I didn't check the trunk.

Fix

point 1: If issue on saltflx confirmed, change in field_def_oce.xml is required.

point 2: add fwficb to rnf and add fwficb * rLfus to the runoff heat content flux.

#2641 fixed haloes in traqsr systeam clem
Description

Context

In 4.0-HEAD (and maybe in the trunk), I noticed that qsr_hc is calculated only in the interior (excluding haloes). e.g

            DO jj = 2, jpjm1
               DO ji = fs_2, fs_jpim1
                  qsr_hc(ji,jj,jk) = r1_rau0_rcp * ( zea(ji,jj,jk) - zea(ji,jj,jk+1) )
               END DO
            END DO

It is ok for the temperature trend but not for the output "qsr3d" here:

      IF( iom_use('qsr3d') ) THEN      ! output the shortwave Radiation distribution
         ALLOCATE( zetot(jpi,jpj,jpk) )
         zetot(:,:,nksr+1:jpk) = 0._wp     ! below ~400m set to zero
         DO jk = nksr, 1, -1
            zetot(:,:,jk) = zetot(:,:,jk+1) + qsr_hc(:,:,jk) * rau0_rcp
         END DO
         CALL iom_put( 'qsr3d', zetot )   ! 3D distribution of shortwave Radiation
         DEALLOCATE( zetot )
      ENDIF

It is also written in a restart file as:

CALL iom_rstput( kt, nitrst, numrow, 'qsr_hc_b'   , qsr_hc     , ldxios = lwxios )

But I suppose iom_rstput does a lbc_lnk on this file otherwise we would have reproducibility issues.

Analysis

...

Fix

...

#2640 fixed tra_adv_qck may give incorrect results on the northfold hadcv hadcv
Description

NOTE: This bug fix changes results when using nn_hls = 1

Context

tra_adv_qck gives different run.stat results for nn_hls = 1 compared to nn_hls = 2.

Analysis

In tra_adv_qck_j, the calculation of zfu on the northfold does not appear to be consistent with the rest of the domain.

231            DO jk = 1, jpkm1
232               !
233               !--- Computation of the ustream and downstream value of the tracer and the mask
234               DO_2D( 0, 0, nn_hls-1, nn_hls-1 )
235                  ! Upstream in the x-direction for the tracer
236                  zfc(ji,jj,jk) = pt(ji,jj-1,jk,jn,Kbb)
237                  ! Downstream in the x-direction for the tracer
238                  zfd(ji,jj,jk) = pt(ji,jj+1,jk,jn,Kbb)
239               END_2D
240            END DO
241            IF (nn_hls.EQ.1) CALL lbc_lnk( 'traadv_qck', zfc(:,:,:), 'T', 1.0_wp , zfd(:,:,:), 'T', 1.0_wp )   ! Lateral boundary conditions
242   
243            !
244            ! Horizontal advective fluxes
245            ! ---------------------------
246            !
247            DO_3D( 0, 0, nn_hls-1, 0, 1, jpkm1 )
248               zdir = 0.5 + SIGN( 0.5_wp, pV(ji,jj,jk) )   ! if pU > 0 : zdir = 1 otherwise zdir = 0
249               zfu(ji,jj,jk) = zdir * zfc(ji,jj,jk ) + ( 1. - zdir ) * zfd(ji,jj+1,jk)  ! FU in the x-direction for T
250            END_3D

Substituting zfc and zfd into zfu gives:

zfu(ji,jj,jk) = zdir * pt(ji,jj-1,jk,jn,Kbb) + ( 1. - zdir ) * pt(ji,jj+2,jk,jn,Kbb)

The issue is that the lbc_lnk in the nn_hls = 1 case will mirror zfd, so that:

zfd(:,Nje0,  :) = pt(:,Nje0+1,:)
zfd(:,Nje0+1,:) = pt(:,Nje0,  :)

and therefore the calculation of zfu on the northfold effectively uses a different stencil to the rest of the domain:

zfu(:,Nje0-2,:) = zdir * pt(:,Nje0-3,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0,  :,jn,Kbb)
zfu(:,Nje0-1,:) = zdir * pt(:,Nje0-2,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0+1,:,jn,Kbb)
zfu(:,Nje0,  :) = zdir * pt(:,Nje0-1,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0,  :,jn,Kbb)

In the nn_hls = 2 case, zfd is calculated explicitly and the northfold stencil for zfu is consistent with the rest of the domain, therefore giving different results to the nn_hls = 1 case:

zfd(:,Nje0+1,:) = pt(:,Nje0+2,:)

zfu(:,Nje0-2,:) = zdir * pt(:,Nje0-3,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0,  :,jn,Kbb)
zfu(:,Nje0-1,:) = zdir * pt(:,Nje0-2,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0+1,:,jn,Kbb)
zfu(:,Nje0,  :) = zdir * pt(:,Nje0-1,:,jn,Kbb) + ( 1. - zdir ) * pt(:,Nje0+2,:,jn,Kbb)

Fix

The correct values for zfd on the northfold can be recovered from zfc after the lbc_lnk:

+         IF( nn_hls == 1 .AND. l_IdoNFold .AND. ntej == Nje0 ) THEN
+            DO jk = 1, jpkm1
+               WHERE( tmask_i(ntsi:ntei,ntej:jpj) == 0._wp ) zfd(ntsi:ntei,ntej:jpj,jk) = zfc(ntsi:ntei,ntej:jpj,jk)
+            END DO
+         ENDIF
         !
         ! Horizontal advective fluxes
         ! ---------------------------
         !
         DO_3D( 0, 0, nn_hls-1, 0, 1, jpkm1 )
            zdir = 0.5 + SIGN( 0.5_wp, pV(ji,jj,jk) )   ! if pU > 0 : zdir = 1 otherwise zdir = 0
            zfu(ji,jj,jk) = zdir * zfc(ji,jj,jk ) + ( 1. - zdir ) * zfd(ji,jj+1,jk)  ! FU in the x-direction for T
         END_3D

This makes the results consistent for both nn_hls, but it would be useful to get an independent confirmation that this is indeed a bug.

Note: See TracQuery for help on using queries.