improve fld_read time management

[gsamson]

Context

"fld_read" routine always considers that the field timestep is centred on the middle of the time window separating two successive fld_read calls.
This is usually true when the field is a time-averaged variable valid at the middle of the corresponding time bounds.
But in the case of instantaneous fields, they are valid at the exact timestep of the fld_read call. Consequently, fld_read shifts the field valid timestep by half its frequency, which is wrong and can significantly offset atmospheric forcings for example.

Proposal

introduce a new argument in fld_read structure to specify whether the field read by fld_read is (time-)averaged or instantaneous, and shift field valid timestep accordingly in fld_read.

[ohuziy]

commit diff

[ohuziy]

There is already code to handle this case in our version of the model (implemented by Michael Dunphy). I have added the patch as an attachment. Not sure what would be a proper way to propagate this upstream..

[fdupont]

Merci Sasha, I guess one advantage of Mike's approach is that it does not require any new argument to the fld_read structure as only 3 cases need attention: is the variable centered over the given period (e.g., an average of 0-1h as already coded; i.e., nothing to add), or as an instantaneous value valid either at the beginning (e.g., 0h; i.e., add prefix "-") or at the end of the period (e.g., 1h; i.e., add prefix "+") [which leaves the flexibility to concatenate forcing timeframes from snapshots starting from either 0h or 1h]. An additional argument would be required if the offset was less predictable but it is hard to imagine why a model would output fields at each 0h25, 1h25, etc...