Changes between Version 25 and Version 26 of Branches/Driver_Improvements

Timestamp:

2016-05-27T16:55:33+02:00 (8 years ago)

Author:

aducharne

Comment:

--

Branches/Driver_Improvements

@@ -62 +62 @@
 The lower panel will show that this error '''does not occur''' only if, the fluxes are averages centred on the time corresponding at which the scalars are valid. Thus the old driver is only correct if the fluxes at time step ''itau_n'' are exactly valid over the time interval ''t(itau_n-1/2)'' and ''t(itau_n+1/2)''.
 
+
+'''AD(27/05/2016): I disagree with the above statement that motivates the development of a new interpolation method''' : "The time-stepping is done independently from the physical time. [...] The issue becomes more complicated when we consider fluxes which are averaged over an interval. The only valid assumption is that the dates corresponding to index itau_n is within the time interval over which the average was performed. In readim2.f90 there is no information if the date of n is at the start, end or anywhere else within the averaging period." 
+
+First, the time is defined without ambiguity from the initial time and the nb of records that were read.  Second, when we read a flux at the record itau_nm1, we perfectly know to which interval it corresponds. For WFDEI for instance, we know from http://www.eu-watch.org/gfx_content/documents/README-WFDEI%20(v2016).pdf that the record at itau_n holds the average flux over the 3-hourly period that precedes the "time stamp" of itau_n (t0+dt according to the above notations). This is perfectly clear, and perfectly coherent with the first panel of the above graphics, thus with dim2driver.
+
+
 == Add an explicit time information within the forcing files ==
 As described above, the driver of ORCHIDEE is relatively rigid because it makes strict assumptions one temporal specification for the forcing files. At first, we do not expect to develop a more flexible driver but we would like to add explicit time information in the driver in order to avoid misuse.