Opened 9 years ago

Closed 9 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: release-3.4
Severity: Keywords:
Cc: Branch review:
MP ready?: Task progress:


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 :

  1. 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.
  1. 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)


trunk: bugfix in fldread when nn_fsbc * rn_rdt > frcing file period, see #958

Change History (2)

comment:1 Changed 9 years ago by smasson

  • Owner changed from NEMO team to smasson

comment:2 Changed 9 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.

done, see r3851

Note: See TracTickets for help on using tickets.