Context

ln_zad_Aimp = T (courant number dependent implicit vertical advection)

Analysis

in diawri.F90, when outputting a quantity that involves vertical velocity (ww+wi, the sum of explicit plus implicit part) ww = ww + wi then output with iomput the return back to ww value : ww = ww - wi This change the last digit value of ww, changing the run.stat after 55 timestep in OVERFLOW configuration.

For diagnostic purposes, one should never alter a variable that is used to compute the RHS of prognostic Eqs.

Fix

in trunk: lines 253-256 (v4.0 : lines 213-226 with "wn" instead of "ww")

      IF( ln_zad_Aimp ) wn = ww + wi               ! Recombine explicit and implicit parts of vertical velocity for diagnostic output
      !
      CALL iom_put( "woce", ww )                   ! vertical velocity
      IF( iom_use('w_masstr') .OR. iom_use('w_masstr2') ) THEN   ! vertical mass transport & its square value
         ! Caution: in the VVL case, it only correponds to the baroclinic mass transport.
         z2d(:,:) = rau0 * e1e2t(:,:)
         DO jk = 1, jpk
            z3d(:,:,jk) = ww(:,:,jk) * z2d(:,:)
         END DO
         CALL iom_put( "w_masstr" , z3d )  
         IF( iom_use('w_masstr2') )   CALL iom_put( "w_masstr2", z3d(:,:,:) * z3d(:,:,:) )
      ENDIF
      !
      IF( ln_zad_Aimp ) wn = wn - wi               ! Remove implicit part of vertical velocity that was added for diagnostic output

becomes

      !                                            ! vertical velocity
      IF( ln_zad_Aimp ) THEN   ;   CALL iom_put( "woce", ww + wi )   ! explicit plus implicit parts
      ELSE                     ;   CALL iom_put( "woce", ww )
      ENDIF

      IF( iom_use('w_masstr') .OR. iom_use('w_masstr2') ) THEN   ! vertical mass transport & its square value
         !                     ! Caution: in the VVL case, it only correponds to the baroclinic mass transport.
         DO jk = 1, jpk
            IF( ln_zad_Aimp ) THEN
               z3d(:,:,jk) = rau0 * e1e2t(:,:) * ( ww(:,:,jk) + wi(:,:,jk) )
            ELSE
               z3d(:,:,jk) = rau0 * e1e2t(:,:) * ww(:,:,jk)
            ENDIF
         END DO
         CALL iom_put( "w_masstr" , z3d )  
         IF( iom_use('w_masstr2') )   CALL iom_put( "w_masstr2", z3d * z3d )
      ENDIF

Context

As halos are no more read in the input files, we must fill them by applying the boundary conditions just after reading any file.

In consequence, a call to lbc_lnk was included in iom_get. This requires to know the type of point and the sign to properly apply the NP folding. By default, this is 'T' and +1._wp. This can be changed through the optional arguments cd_type and psgn.

This is the same story for data read with fld_read which uses iom_get.
We therefore added in the fldread structure (TYPE(FLD)) 2 new elements : cltype and zsgn to attach to the variable to be read its grid type an the sign to use in the NP folding. By default, they are defined to 'T' and +1._wp in fld_fill.
If the filed to be read by fldread is not a scalar value at T point, we must overwrite this default definition as it is done for example in src/OFF/dtadyn.F90 or src/SAS/sbcssm.F90.

Analysis

The following errors have been identified:

• in sbcblk.F90:
  • jp_wndi, jp_wndj, jp_uoatm, jp_voatm, jp_hpgi, jp_hpgj must have their sign defined to -1._wp: sf(...)%zsgn = -1._wp
• in sbcflx.F90:
  • we must add: sf(jp_utau)%cltype = 'U' and sf(jp_utau)%zsgn = -1._wp
  • we must add: sf(jp_vtau)%cltype = 'V' and sf(jp_vtau)%zsgn = -1._wp
  • the first cal to lbc_lnk can be removed (it was in fact fixing the bug)
• in sbcwave.F90:
  • jp_usd and sn_vsd must have their sign defined to -1._wp: slf_i(...)%zsgn = -1._wp

However, in sbcblk.F90 and sbcwave.F90 the computation of the stress at U and V points forces a call to lbc_lnk which corrects the problem. But the bug should be fix as we plan in the future to compute the stress at T point.
In sbcflx.F90, the bug is hidden by a call to lnc_blk that will become useless once the bug is fixed.

I haven't seen other vector field read by fld_read (except bdy staff but it is not compatible with the NP folding).

Note that this fix does not concern previous version of NEMO.

Context

There are multiple errors messages when compiling PPR with gcc

Error: Type mismatch in argument 'aa' at (1); passed REAL(16) to REAL(8)

Analysis

PPR uses the notation .d (for example 1.d0) to promote double precision.
As NEMO is compiled in double precision by default, this means that these ".d" variables are promoted to real*16.
All reals in PPR are declared as real*8 which creates the compilation error seen above.

Note that ifort does not complain when compiling PPR but I guess it is doing implicite real*8 <-> real*16 conversions...

Fix

replace all .d by a .e in all PPR/src files, for example with this small piece of shell :

for ff in ext/PPR/src/*90
do
   sed -e "s/\.d/.e/g" $ff > tmp
   mv tmp $ff
done