Custom Query (2349 matches)


Show under each result:

Results (1 - 3 of 2349)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#1985 fixed 10m SSH check too small for tidal runs deazer deazer


stpctl.F90 The limit on SSH of 10m is a bit restrictive on Tidal runs.

   IF( lk_mpp )   CALL mpp_max( zsshmax )                ! min over the global domain
   IF( MOD( kt, nwrite ) == 1 .AND. lwp )   WRITE(numout,*) ' ==>> time-step= ',kt,' ssh max:', zsshmax
   IF( zsshmax > 10.e0 ) THEN
      IF (lk_mpp) THEN
         CALL mpp_maxloc( ABS(sshn(:,:)),tmask(:,:,1),zsshmax,ii,ij)
         ilocs = MAXLOC( ABS(sshn(:,:)) )
         ii = ilocs(1) + nimpp - 1
         ij = ilocs(2) + njmpp - 1


Propose to increase the limit (20m?) if the run has tides (ln_tide)

#2212 fixed 12 months runoff hard coded... systeam smasson


Reported by Rachid: in sbc_rnf_init, the use of 12 record runoff files is hard coded… Indeed we have a nice hard coded declaration…

      REAL(wp), DIMENSION(12)                 :: zrec             ! times records

No need to say that there is no call to any warning/stop or any comment to warn people about this hard coded definition…

This zrec is required but, in fact, not needed in iom_gettime:

         CALL iom_gettime( inum, zrec, kntime=nbrec)

nbrec is next used to allocate a 3D array zrnfcl(jpi,jpj,nbrec) without any test on the error status exit… I let you imagine what happen when nbrec = 365…

Cherry on the cake: this 3D array is not needed as the iom_get is done in a temporal loop:

         DO jm = 1, nbrec
            CALL iom_get( inum, jpdom_data, TRIM( sn_rnf%clvar ), zrnfcl(:,:,jm), jm )
         END DO

Last point, iom_gettime mix-up unlimited dimension size with a time axis variable… this routine requires an input array (that is in fact never used) which size is not know when calling iom_gettime…


Clean up all this mess…


Dont't let this king of crappy code to be commited…

#275 fixed 1D stability issues with surface boundary conditions ctlod momme

The 1D set-up in the ORCA2 configuration has serious issues with the surface forcing. Using the clio surface boundary condition the model interrupts after few timesteps because of unreasonable high zonal velocities. Switching to analytical boundary conditions and setting them all to 0 the model seems to run fine, but as soon as some even small value of windstress is applied the problem reoccurs. As this prpoblem wasn't there in v2 I suppose that this must be a problem with the new SBC interface.

1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.