Bug in nn_stocklist behaviour in some cases

[timgraham]

Context

When providing a list of restart timesteps to the model (via nn_stocklist) there is currently a problem if either of the following are met:

• The first restart is requested at a timestep smaller that nit000
• The first restart is requested at timestep nit000
• If restarts are requested at consectutive time steps (I think this is an issue).

Analysis

In rst_opn this if statement sets the first value of nitrst based on nn_stocklist

      IF( kt == nit000 ) THEN   ! default definitions
         lrst_oce = .FALSE.
         IF( ln_rst_list ) THEN
            nrst_lst = 1
            nitrst = nn_stocklist( nrst_lst )
         ELSE
            nitrst = nitend
         ENDIF
      ENDIF

Later in the subroutine this line triggers the opening of a restart file
IF( kt == nitrst - 1 .OR. nn_stock == 1 .OR. ( kt == nitend .AND. .NOT. lrst_oce ))
but if the first requested timestep is <= nit000 then this if statement is never satisfied until kt==nitend and the final restart file will be written out with an incorrect name (based on the first value of nn_stocklist).

Fix

Still being investigated.

[acc]

Will something like:

nitrst   = MIN( nitend, MINVAL( nn_stocklist, MASK=nn_stocklist.gt.nit000) )
nrst_lst = MAX( 1, FINDLOC( nn_stocklist, nitrst, DIM=1 ) )

be enough to catch any inappropriate input from the user?

[timgraham]

Replying to acc:

Will something like:

nitrst   = MIN( nitend, MINVAL( nn_stocklist, MASK=nn_stocklist.gt.nit000) )
nrst_lst = MAX( 1, FINDLOC( nn_stocklist, nitrst, DIM=1 ) )

be enough to catch any inappropriate input from the user?

I think that solves the first point. I've done something similar with a DO WHILE statement but I think your syntax is probably neater. There is still an issue if the user requests a restart on the first time step. At the moment this case still gets missed by the later IF statement.

[acc]

In 15596:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[smasson]

FINDLOC function is a fortran 2008 intrinsic.
This looks old enough to be used in the code but FINDLOC is supported by gcc only from ​version 9.0 (2018-10-28).
We decide to replace it by an old style loop to avoid any compilation issue.

[smasson]

fixed in [15810]