Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#1201 closed Bug (fixed)

Monthly Interpolation Incorrect in fldread.F90

Reported by: sallen@… Owned by: jamesharle
Priority: normal Milestone:
Component: OCE Version: release-3.4
Severity: Keywords: SBC interpolation


Using dev_v3_4_STABLE_2012 @ r3819

At line 534, ztmp is calculated as a fraction of a month
At lines 536 and 538, a time step is added to ztmp in seconds. This needs to be corrected to also be fractions of a month.

(I believe the same mistake is also in the yearly interpolation: Lines 501 versus 503 and 505, but have not corrected those in the attached.)

Commit History (1)


Correction to monthly and yearly interpolation in fld_rec subroutine (see ticket #1201 for details)

Attachments (1)

fldread.F90 (67.6 KB) - added by sallen@… 7 years ago.
Monthly interpolation corrected in fldread.F90

Download all attachments as: .zip

Change History (7)

Changed 7 years ago by sallen@…

Monthly interpolation corrected in fldread.F90

comment:1 Changed 7 years ago by clevy

  • Owner changed from NEMO team to smasson

comment:2 Changed 6 years ago by jamesharle

  • Owner changed from smasson to jamesharle

comment:3 Changed 6 years ago by jamesharle

Issue: A mix of different time formats in the fld_rec subroutine (monthly and yearly interpolations) leads to the addition of a time offset in seconds (only employed in the BDY code at present) to fractions of a month (year). This causes issues with input field record number: sdjf%nrec_a. In addition, there is also an issue if using annual mean boundary/forcing data. The mid-point in the year calculation only works if you start your simulation in the first half of the year. Otherwise, if starting in the latter half of year N, years N-1 and N are used instead of year N and N+1. This wasn't helped by the fact ztmp was also incorrectly calculated using the day in month (nday) in the annual mean interpolation instead of the day in the year (nday_year). This resulted in the current location within the year never getting passed the first month.

In addition the use of nday in calculating the position of the current time-step within the current month/year results in the mid-point being detected ½ a day early and the next monthly/annual file being read in. Switching nday to nsec_month in the case of monthly interpolation and nday (which was incorrect in the first instance - should have been nday_year) to nsec_year in the case of yearly interpolation leads to greater accuracy (other wise the use of the time offset option becomes pointless).

This has been tested for both v3.4 and the trunk (see ticket #1372) in the AMM12 configuration (just before and just after the year end, and at the mid-month/mid-year switch point when the next month/year file is read in). dom_oce.F90 and day mod.F90 were also modified to include the 'next' years length in days (already present in v3.6).

comment:4 Changed 6 years ago by jamesharle

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 Changed 4 years ago by nicolasmartin

  • Keywords SBC added; fld removed

comment:6 Changed 4 years ago by nicolasmartin

  • Keywords month removed
Note: See TracTickets for help on using tickets.