#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)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
12256 | smasson | 2019-12-16T13:52:49+01:00 | rev12232_dev_r12072_MERGE_OPTION2_2019: bugfix in fldread offset in bdy, see #2263. all sette tests ok |
12255 | smasson | 2019-12-16T13:52:25+01:00 | rev12240_dev_r11943_MERGE_2019: bugfix in fldread offset in bdy, see #2263. all sette tests ok |
12250 | smasson | 2019-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 |
12246 | smasson | 2019-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 |
12180 | smasson | 2019-12-11T12:16:36+01:00 | dev_r12114_ticket_2263: minor bugfix in daymod to follow [12158], see #2263 |
12127 | smasson | 2019-12-09T18:42:54+01:00 | dev_r12114_ticket_2263: replace integer kt_offset by real pt_offset, see #2263 |
12116 | smasson | 2019-12-09T08:53:27+01:00 | dev_r12114_ticket_2263: new version of fldread calendar, see #2263 |
12115 | smasson | 2019-12-09T08:38:53+01:00 | create branche to solve #2263 |
Change History (13)
comment:1 Changed 6 years ago by clevy
- Owner changed from systeam to smasson
- Status changed from new to assigned
comment:2 Changed 6 years ago by smasson
comment:3 Changed 5 years ago by smasson
In 12115:
comment:4 Changed 5 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 5 years ago by smasson
In 12116:
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
comment:6 Changed 5 years ago by smasson
In 12127:
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
comment:7 Changed 5 years ago by smasson
In 12180:
comment:8 Changed 5 years ago by smasson
In 12246:
comment:9 Changed 5 years ago by smasson
In 12250:
comment:10 Changed 5 years ago by smasson
In 12255:
comment:11 Changed 5 years ago by smasson
In 12256:
comment:12 Changed 5 years ago by smasson
- Resolution set to fixed
- Status changed from assigned to closed
comment:13 Changed 3 years ago by nemo
- Keywords v4.0 added
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:
Which point is not correctly carried out?
llstop should be false only for the last day of your simulation.