id summary reporter owner description type status priority milestone component version severity resolution keywords cc 2263 restartibility issue with bdy_dta dupontf smasson "==== 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...). " Defect closed low BDY v4.0 minor fixed bdy_dta v4.0