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.
#965 (nn_rstctl=2: why check consistency between namelist and restart?) – NEMO

Opened 12 years ago

Closed 12 years ago

#965 closed Defect (fixed)

nn_rstctl=2: why check consistency between namelist and restart?

Reported by: vichi Owned by: nemo
Priority: low Milestone:
Component: OCE Version: v3.4
Severity: Keywords:
Cc: beppe

Description

Hi all

we are wondering why the check of consistency between dates in the namelist and in the restart file is done also for nn_rstctl=2. This means that there is no way to let the restart file drive the date and it's always needed to keep track of dates in the namelist.

Is there a specific reason for not moving the following lines in daymod.F90

            IF( nit000 - NINT( zkt ) /= 1 .AND. nrstdt /= 0 )                                         &
                 &   CALL ctl_stop( ' ===>>>> : problem with nit000 for the restart',                 &
                 &                  ' verify the restart file or rerun with nrstdt = 0 (namelist)' )

in the else part of the following if statement:

            ! define ndastp and adatrj
            IF ( nrstdt == 2 ) THEN
               ! read the parameters correspondting to nit000 - 1 (last time step of previous run)
               CALL iom_get( numror, 'ndastp', zndastp )
               ndastp = NINT( zndastp )
               CALL iom_get( numror, 'adatrj', adatrj  )
            ELSE
               ! parameters correspondting to nit000 - 1 (as we start the step loop with a call to day)
               ndastp = ndate0 - 1     ! ndate0 read in the namelist in dom_nam, we assume that we start run at 00:00
               adatrj = ( REAL( nit000-1, wp ) * rdttra(1) ) / rday
               ! note this is wrong if time step has changed during run 
            ENDIF

and assigning zkt read from the restart file into nit000?

nit000 = NINT(zkt)

Commit History (0)

(No commits)

Change History (3)

comment:1 Changed 12 years ago by beppe

  • Cc beppe added

comment:2 Changed 12 years ago by smasson

The use of nn_rstctl was quite unclear and we tried to clarified it in changeset:3306 ...
If you define nn_rstctl=2

  • nn_date0 is read in the restart file. the value of nn_date0 defined in the nameliste is not used.
  • we decided to keep a control on nn_it000 as you will have to define nn_itend that is directly linked to nn_it000. We thought that if you are able to define nn_itend you should be able to define nn_it000 and we should control its value.

But we can decide to review this strategy...

comment:3 Changed 12 years ago by vichi

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

Thanks Sebastien

now it's much more clear. Indeed this raises an issue, which is the lack of choice of running a simulation with a given length, and being forced to always loop from an initial time step to a final one. It's not at all an urgent feature, but we are facing it because Beppe is working with the NCAR coupler that works in a different way. We may be thinking in the longer term to have another flag that runs for a given number of time-steps, taking nn_it000 from the restart and computing nn_itend.

Note: See TracTickets for help on using tickets.