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.
#2263 (restartibility issue with bdy_dta) – NEMO

Opened 5 years ago

Closed 4 years ago

Last modified 2 years ago

#2263 closed Defect (fixed)

restartibility issue with bdy_dta

Reported by: dupontf Owned by: smasson
Priority: low Milestone:
Component: BDY Version: v4.0
Severity: minor Keywords: bdy_dta v4.0
Cc:

Description

Context

Restartibility issue with no time-interpolation option for daily averaged OBC files.

Analysis

bdy_dta is called from step with a recommended value of kt_offset=1. The logic is that the OBC must be valid for the "after" fields (e.g. ua). However, fldread, which is called in the end, is already offset by 0.5*rdt as it is centered between un and ua in order to impose a mean forcing between the two valid times. Therefore, the present code actually offsets too far in the future the OBC. The correct value should be kt_offset=0.5 but the code expects an integer value.

Moreover, using the no time-interpolation option for daily averaged OBC files each containing only one record for the day, the restartibility is broken as kt_offset=1 forces at t=00:00:00-0.5*rdt fld_read to believe that t is actually t=00:00:00+0.5*rdt > 00:00:00 which triggers the search for the next record. However, because the calendar variables have not been updated, fldread searches for a second record in the same old file, which does not exist (there is no crash because fldread just circles back to the first record). The overall behaviour is to delay the whole OBC forcing by one day minus one timestep after day 1 of the simulation, which breaks restartibility.

Recommendation

kt_offset=0 is safer because it only lags the OBC forcing by 0.5*rdt in the case of time-interpolated fields and ensures restartibility. (recall that kt_offset=1 also offsets the OBC by 0.5*rdt, but in the future)

kt_offset=0.5 would solve the validity time issue. However, for un-interpolated fields, at t=00:00:00, which frame is valid is undefined. (could assume that the old one is OK, i.e. kt_offset=0.4999...).

Commit History (8)

ChangesetAuthorTimeChangeLog
12256smasson2019-12-16T13:52:49+01:00

rev12232_dev_r12072_MERGE_OPTION2_2019: bugfix in fldread offset in bdy, see #2263. all sette tests ok

12255smasson2019-12-16T13:52:25+01:00

rev12240_dev_r11943_MERGE_2019: bugfix in fldread offset in bdy, see #2263. all sette tests ok

12250smasson2019-12-14T09:41:16+01:00

rev12240_dev_r11943_MERGE_2019: same as [12246], add modifications from dev_r12114_ticket_2263, results unchanged except SPITZ12 as explained in #2263

12246smasson2019-12-13T16:11:51+01:00

rev12232_dev_r12072_MERGE_OPTION2_2019: add modifications from dev_r12114_ticket_2263, results unchanged except SPITZ12 as explained in #2263

12180smasson2019-12-11T12:16:36+01:00

dev_r12114_ticket_2263: minor bugfix in daymod to follow [12158], see #2263

12127smasson2019-12-09T18:42:54+01:00

dev_r12114_ticket_2263: replace integer kt_offset by real pt_offset, see #2263

12116smasson2019-12-09T08:53:27+01:00

dev_r12114_ticket_2263: new version of fldread calendar, see #2263

12115smasson2019-12-09T08:38:53+01:00

create branche to solve #2263

Change History (13)

comment:1 Changed 5 years ago by clevy

  • Owner changed from systeam to smasson
  • Status changed from new to assigned

comment:2 Changed 5 years ago by smasson

I don't understand the second part of your Analysis.
I agree that "kt_offset=1 forces at t=00:00:00-0.5*rdt fld_read to believe that t is actually t=00:00:00+0.5*rdt > 00:00:00 which triggers the search for the next record.”

In fld_read, we should:

1) enter the following IF as isecsbc should correspond to 00:00:00+0.5*rdt and sd(jf)%nrec_a(2) to 00:00:00

IF( isecsbc > sd(jf)%nrec_a(2) .OR. ll_firstcall ) THEN    ! read/update the after data?

2) call fld_rec that woud define sdjf%nrec_a(1) to 2 because of the following lines

            !
            !           INT( ztmp/ifreq_sec )
            !                     /|\
            !                    2 |           *-----(
            !                    1 |     *-----(
            !                    0 |-----(              
            !                      |--+--|--+--|--+--|--> time
            !                      0 /|\ 1 /|\ 2 /|\ 3    (ztmp/ifreq_sec)
            !                         |     |     |
            !                         |     |     |
            !       forcing record :  1     2     3
            !                            
            ztmp= ztmp / REAL(ifreq_sec, wp)
         ENDIF
         sdjf%nrec_a(1) = 1 + INT( ztmp ) - COUNT((/llbefore/))   ! record number to be read

3) enter the following IF as sd(jf)%nrec_a(1) should be equal to 2 and sd(jf)%nreclast to 1

IF( sd(jf)%nrec_a(1) > sd(jf)%nreclast ) THEN

4) redefine sd(jf)%nrec_a(1) to one with the following line

sd(jf)%nrec_a(1) = sd(jf)%nrec_a(1) - sd(jf)%nreclast   ! 

5) call fld_clopn to open the file corresponding to the following day.

Which point is not correctly carried out?
llstop should be false only for the last day of your simulation.

comment:3 Changed 4 years ago by smasson

In 12115:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:4 Changed 4 years ago by smasson

The calendar part of fldread was completely rewritten in order to be able to solve this ticket.
-> create NEMO/branches/2019/dev_r12114_ticket_2263/

comment:5 Changed 4 years ago by smasson

In 12116:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

This version passes all sette tests (cfgs and tests) on irene machine with -fp-model strict.
It gives the exact same results as the trunk@12072 except for SPITZ12.
This difference comes from a bug that is corrected in this branch : when using 3d forcing files, the record previous of Jan 1st of the first run is at time -0.5 days and not -1.5 days (as coded in the trunk@12072) because 3 does not divide 365. If this bug is voluntary reintroduced in this brach, SPITZ12 results are then identical to those of he trunk@12072

Last edited 4 years ago by smasson (previous) (diff)

comment:6 Changed 4 years ago by smasson

In 12127:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

This version passes all sette tests (cfgs and tests) on irene machine with -fp-model strict.
It does not change any results, and gives the exact same results as this branch@12116

Last edited 4 years ago by smasson (previous) (diff)

comment:7 Changed 4 years ago by smasson

In 12180:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:8 Changed 4 years ago by smasson

In 12246:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:9 Changed 4 years ago by smasson

In 12250:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:10 Changed 4 years ago by smasson

In 12255:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:11 Changed 4 years ago by smasson

In 12256:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:12 Changed 4 years ago by smasson

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

fixed in rev12240_dev_r11943_MERGE_2019 [12255] and rev12232_dev_r12072_MERGE_OPTION2_2019 [12256]

comment:13 Changed 2 years ago by nemo

  • Keywords v4.0 added
Note: See TracTickets for help on using tickets.