Opened 14 months ago

Closed 5 months ago

#2263 closed Defect (fixed)

restartibility issue with bdy_dta

Reported by: dupontf Owned by: smasson
Priority: low Milestone:
Component: BDY Version: release-4.0
Severity: minor Keywords: bdy_dta
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 (12)

comment:1 Changed 12 months ago by clevy

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

comment:2 Changed 11 months 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 6 months ago by smasson

In 12115:

create branche to solve #2263

comment:4 Changed 6 months 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 6 months ago by smasson

In 12116:

dev_r12114_ticket_2263: new version of fldread calendar, see #2263

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 6 months ago by smasson (previous) (diff)

comment:6 Changed 6 months ago by smasson

In 12127:

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

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 6 months ago by smasson (previous) (diff)

comment:7 Changed 6 months ago by smasson

In 12180:

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

comment:8 Changed 5 months ago by smasson

In 12246:

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

comment:9 Changed 5 months ago by smasson

In 12250:

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

comment:10 Changed 5 months ago by smasson

In 12255:

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

comment:11 Changed 5 months ago by smasson

In 12256:

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

comment:12 Changed 5 months 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]

Note: See TracTickets for help on using tickets.