Opened 12 years ago
Closed 11 years ago
#958 closed Bug (fixed)
strange behaviour or bug in fldread under some circumstances :
Reported by: | molines | Owned by: | smasson |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | OCE | Version: | v3.4 |
Severity: | Keywords: | ||
Cc: |
Description
We found the following bug in running a ORCA2 configuration with 3 hourly forcing files, and nn_fsbc=5 (standard). (nn_fsbc * rn_rdt > 3h ) time interpolation.
Despite the fact that it is not probably a good choice to use a large nn_fsbc that triggers call to forcing routine at lower frequency than the forcing data, doing so we observed the following :
- interpolation is performed between 'Before' and 'After' data at the time of the call. 'After' is ok, ie the nearest time after the current time. But 'Before' is just the old-after field of the previous interpolation, thus leading to unfair interpolation. This behavior differs from 3.2.2 where 'Before' and 'After' were evaluated at the time of the call.
- This strange behaviour turns into a bug when performing a run overlapping the new-year (Jan 01) : although the record numbers are OK (or at least consistent with point 1 ...), the used data file remains the previous year data file.
The minimum security fix would be to emit an error message if nn_fsbc is to large with respect to the forcing frequency, but fixing the problem would be better, of course ! :-)
Commit History (1)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
3851 | smasson | 2013-03-27T11:03:54+01:00 | trunk: bugfix in fldread when nn_fsbc * rn_rdt > frcing file period, see #958 |
Change History (2)
comment:1 Changed 12 years ago by smasson
- Owner changed from NEMO team to smasson
comment:2 Changed 11 years ago by smasson
- Resolution set to fixed
- Status changed from new to closed
This bug was quite hard to solve. I had to review (and clean) a large part of fldread...
This bugfix is too large (and may therefore include new bugs) to be introduced in the version 3.4.1.