Opened 10 years ago

Closed 10 years ago

#27 closed defect (fixed)

Problem in the temporal structure of ERA-interim forcing files (ERA_Global_XXXX.nc files)

Reported by: nvuilsce Owned by: jan.polcher
Priority: major Milestone: ORCHIDEE 2.0
Component: Driver files Version: orchidee_1_9_6
Keywords: ERA-interim Cc:

Description (last modified by nvuilsce)

  • In the ERA-interim forcing files (ERA_Global_XXXX.nc), the values stored at the time step t appear to be :
    • for tair, the instantaneous temperature at t
    • for swdown, the mean radiation over the time period t-1:t.

While the driver of ORCHIDEE is expected to 'see' at each time step (t) read in the forcing file, the instantaneous value of Tair at t+1 (not t) and the mean value of swdown on the time period t:t+1. See this page

This leads to have inconsistent diurnal cycle, espicially for swdown, that is interpolated from 3-hourly to half-hourly time step using the solar angle value (see fig below).
Tair and Swdown half-houlry values 'seen' by ORCHIDEE with a ERA-i (ERA_Global) forcing file.

Consequently, I think Tair and Sdown (and presumably all the others atm fields) should start one time step later (= the first value should be removed)

  • There are 2 other problems when using these forcing files with ORCHIDEE. Both are related to the way ORCHIDEE uses the temporal information stored in the forcing files.
    • In ORCHIDEE, the reference date for the beginning of the forcing file (date0) is only defined by reading the attribute UNITS of the time variable (the attribute that contains the keyword "since", see flinopen_work subroutine in IOIPSL). In the case of ERA_Global forcing files, it is 01-01-1979 00:00 for any yearly forcing file. The driver doesn't make use of the values stored in the time variable. For instance, if we use the forcing file for the year 1980, the first value of the time variable is 31536000 (=1year (expressed in second) since 01-01-1979) but if we run ORCHIDEE with this forcing file, it will assume that the year of the forcing file is 1979, not 1980. This is a problem, especially for this type of forcing files defined on a gregorian calendar.
    • In order to know the time resolution of the forcing file, the driver of ORCHIDEE tends to read an attribute of the time variable such as tstep_sec. When this attribute is not in the forcing file (that is the case in ERA_Global), the driver calculates the difference between the 2 first values of the time variable to deduce the time resolution of the forcing file. When using a unique reference date for all the yearly forcing files (here 01-01-1979 00:00), at a certain point there are problems of precision for the values stored in the time variable. For instance, for the forcing file for the year 1989, the first value is 315619200, the second one 315630016. The difference is 10816 seconds (while it should be 10800). So, the driver of ORCHIDEE assumes that the time step of the focing file is 3h00'16'' and not 3h. After one year, this corresponds to a shift of 12h.

I would recommend to generate forcing files with a reference date specific for each year of forcing: so, 01-01-1979 00:00 for the year 1979, 01-01-1980 00:00 for the year 1980, ... This is the case for instance for the NCC forcing files.

Attachments (1)

ERAI_075.gif (9.0 KB) - added by nvuilsce 10 years ago.
Tair and Swdown half-houlry values 'seen' by ORCHIDEE with a ERA-i (ERA_Global) forcing file.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by nvuilsce

Tair and Swdown half-houlry values 'seen' by ORCHIDEE with a ERA-i (ERA_Global) forcing file.

comment:1 Changed 10 years ago by nvuilsce

  • Description modified (diff)

comment:2 follow-up: Changed 10 years ago by jpolcher

I have done a simulation with the HydroMerge? version to test this problem on ERA-Int forcing. I used an hourly output to see how on the Greewich meridian the diurnal cycle was phased.

First all variables are correctly phased with the radiation. So there does not seem to be any inconsistency between SWDOWN and Tair as seen in WFD.

On the other hand the maximum of net surface radiation is systematically at 15:30 UTC. Which is 3 hours too late. Thus it seems indeed that the time axis is shifted by 3hours.

This can be solved with the following command applied to all files :
ncatted -a units,time,o,c,"seconds since 1978-12-31 21:00:00" file_wrong.nc file_corrected.nc

A simulation is under way to test the impact.

comment:3 in reply to: ↑ 2 Changed 10 years ago by jpolcher

Replying to jpolcher:

I have done a simulation with the HydroMerge? version to test this problem on ERA-Int forcing. I used an hourly output to see how on the Greewich meridian the diurnal cycle was phased.

First all variables are correctly phased with the radiation. So there does not seem to be any inconsistency between SWDOWN and Tair as seen in WFD.

On the other hand the maximum of net surface radiation is systematically at 15:30 UTC. Which is 3 hours too late. Thus it seems indeed that the time axis is shifted by 3hours.

This can be solved with the following command applied to all files :
ncatted -a units,time,o,c,"seconds since 1978-12-31 21:00:00" file_wrong.nc file_corrected.nc

A simulation is under way to test the impact.

The solution works perfectly except that annual simulations will restart at 21:00 and not at 24:00 on December 31st. But that is not worse a problem than inventing some forcing for the last time step.

comment:4 Changed 10 years ago by jpolcher

In order to perform a simulation with the trunk version with ERA-Int forcing I had to do 2 things :

  • set the time origin of each file to 1-JAN 00:00 of the year.
  • Correct the estimate of the time step length in the forcing file in readim2.f90. Here is teh code I used :

Index: readdim2.f90
===================================================================
--- readdim2.f90 (revision 1296)
+++ readdim2.f90 (working copy)
@@ -101,7 +101,7 @@

ENDIF
WRITE(numout,*) 'have_zaxis : ', llm_full, have_zaxis
!-

  • ttm_part = 2

+ ttm_part = ttm_full

ALLOCATE(itau(ttm_part))
ALLOCATE(data_full(iim_full, jjm_full),lon_full(iim_full, jjm_full),&

& lat_full(iim_full, jjm_full))

@@ -115,7 +115,9 @@

& (filename, .FALSE., iim_full, jjm_full, llm_full, lon_full, lat_full, &
& lev_full, ttm_part, itau, date0, dt_force, force_id)

IF ( dt_force == zero ) THEN

  • dt_force = itau(2) - itau(1)

+ dt_force = (itau(ttm_part) - itau(1))/(ttm_part-1)
+ ! Round it to the nearest second
+ dt_force = NINT(dt_force)

itau(:) = itau(:) / dt_force

ENDIF
! WRITE(numout,*) "forcing_info : Forcing time step out of flinopen : ",dt_force

I propose to add this correction to the trunk.

Now I need to look at the diurnal cycle I get with this configuration and see if the correction proposed by Fabienne works.

comment:5 Changed 10 years ago by jpolcher

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.