BDY using monthly data

[julienjouanno]

I have a problem with fld_read when trying to read bdy monthly data (frequency = -1 in the namelist).
The first pass in fld_init is ok (it reads the previous year at day -15.5), but at kt=1 it tries to read record 139 !!!????. For exemple :

fld_read: var sossheig kt = 1 ( 0.0026 days), Y/M/D = 2000/01/01, records b/a: 0012/ 0139 (days -15.5000/*)

This seems to be specific to bdy since it works fine for surface forcing files. For exemple :
fld_read: var u10 kt = 1 ( 0.0043 days), Y/M/D = 2000/01/01, records b/a: 0012/ 0001 (days -15.5000/ 15.5000)

I use Rev: 4664 of nemo3.6_alpha.

Best regards.
J/

[jchanut]

Hi Julien,
I confirm the problem: bdy with monthly data does not work properly.
Apparently, this comes from the use of a time offset during the fld_read call in bdy_dta routine. If you are in a hurry, one simple fix is remove the optionnal use of the time offset in the call to fld_read (it means you interpolate data at now time step instead of after time step: not a big approximation !).
The reason for all of this seems to be in fld_rec, and the way the offset is used with monthly or yearly data.

Jérôme

[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 (see ticket #1201) and the trunk 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)