New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#2667 (improve fld_read time management) – NEMO

Opened 17 months ago

Last modified 8 months ago

#2667 new Request

improve fld_read time management

Reported by: gsamson Owned by: gsamson
Priority: low Milestone:
Component: SBC Version: trunk
Severity: minor Keywords: fld_read
Cc: greffray, rbourdal, jchanut



"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.


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.

Commit History (0)

(No commits)

Attachments (1)

patch.diff (5.1 KB) - added by ohuziy 17 months ago.
commit diff

Download all attachments as: .zip

Change History (3)

Changed 17 months ago by ohuziy

commit diff

comment:1 Changed 17 months ago by 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..

comment:2 Changed 8 months ago by 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...

Note: See TracTickets for help on using tickets.