strange behaviour or bug in fldread under some circumstances :

[molines]

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.

2. 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 ! :-)

[smasson]

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