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.
#1800 (Missing initialisation of land value in dynvor/vor_een with vvl) – NEMO

Opened 7 years ago

Closed 7 years ago

#1800 closed Bug (fixed)

Missing initialisation of land value in dynvor/vor_een with vvl

Reported by: mathiot Owned by: nemo
Priority: low Milestone:
Component: OCE Version: v3.6
Severity: Keywords: dynvor



NaN appeared at the first time step when I tried NEMO without the wrk_array using the script.


With vvl activated, in subroutine vor_een in dynvor.F90, ze3f is correctly initialised only for cells into the ocean (ze3 /= 0.0). Masked cell (ze3 == 0.0) are not initialised and can lead, in some case, to NaN.

         ELSE ! new formulation from NEMO 3.6
            DO jk = 1, jpk
               DO jj = 1, jpjm1
                  DO ji = 1, jpim1
                     ze3  = ( fse3t(ji,jj+1,jk)*tmask(ji,jj+1,jk) + fse3t(ji+1,jj+1,jk)*tmask(ji+1,jj+1,jk)   &
                        &   + fse3t(ji,jj  ,jk)*tmask(ji,jj  ,jk) + fse3t(ji+1,jj  ,jk)*tmask(ji+1,jj  ,jk) )
                     zmsk = (                   tmask(ji,jj+1,jk) +                     tmask(ji+1,jj+1,jk)   &
                        &                     + tmask(ji,jj  ,jk) +                     tmask(ji+1,jj  ,jk) )
                     IF( ze3 /= 0._wp )   ze3f(ji,jj,jk) = zmsk / ze3
                  END DO
               END DO
            END DO

Allocated ze3f(:,:,:) to 0, before to start to fill it, fix the issue.

This issue is (I think) also affected the 3.6 version distributed, not only the rewrite version (using the tool).


I think, ze3f(:,:,:) should be initialized to 0 in dynvor.F90/vor_een.

Commit History (1)


fix for ticket #1800

Change History (2)

comment:1 Changed 7 years ago by gm

Hi Pierre,

Thanks for reporting this issue. 

This Bug only concern the 3.6_stable, not the trunk. I correct this issue in the trunk one year ago, and  but apparently not in the v3.6_stable....   sorry!

The problem is related to the use of key_vectopt_loop.

When this key is defined, the calculation in vor_een subroutine is performed from 1 to jpi  (fs_jpim1 is replaced by jpi) in order to allow unrolling of the inner ji-loop (fastest calculation on vector computers) while ze3f is always computed from 1 to jpim1 (even when key_vectopt_loop is defined).  Therefore undefined values of ze3f are used in the calculation.

The solution is to replace jpim1 by fs_jpim1 in the DO loop calculating ze3f (both in case of ln_dynvor_een_old = TRUE or FALSE.)

It is not necessary (and more costly) to initialize ze3f to zero everywhere.

Please, verify what I'm explaining as follow: check that you are effectively using the key_vectopt_loop. Remove it, and check that the current v3.6_stable version works properly.


comment:2 Changed 7 years ago by mathiot

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

In revision 7411:

  • The bound of the ji loop (jpim1) is changed by fs_jpim1.
  • IF test statement
IF( ze3 /= 0._wp )   ze3f(ji,jj,jk) = zmsk / ze3

is replace by

IF     ( ze3 /= 0._wp ) THEN ;   ze3f(ji,jj,jk) = zmsk / ze3
ELSE                         ;   ze3f(ji,jj,jk) = 0.0_wp

in order to initialized ze3f everywhere.

Note: See TracTickets for help on using tickets.