Changes between Version 27 and Version 28 of Branches/Driver_Improvements

Timestamp:

2016-05-27T18:04:04+02:00 (8 years ago)

Author:

aducharne

Comment:

--

Branches/Driver_Improvements

@@ -27 +27 @@
 '''AD (26/5/2016):''' I agree on the above general guidelines for interpolation, '''but''' :
 - LW should not be interpolated linearly: the mean value over the appropriate interval ([t0,t0+dt] in dim2driver) is the value read at t0+dt ; if we linearly interpolate LW between t0 and t0+dt, the mean value becomes LW(t0)+LW(t0+dt), which is usually different from LW(t0+dt). So if we do a linear interpolation, we change the amount of energy that is received by the surface compared to what is defined in the forcing file. 
+- Apparently, the default behavior in dim2driver is to linearly interpolate LW (using the same interpolation scheme used for the instantaneous variables like Tair). This results from inter_lin=F by default, which induces netrad_cons=F and leads to use a linear interpolation, in contradiction with inter_lin=F. This needs to be double checked by someone, and reported in a ticket if confirmed.
 - The simplest conservative interpolation is to use a uniform function, but it creates "steps". If we wanted to smooth this and remain conservative, we could use a function to constrain the time variations, as it is done with the zenith angle for SW. Based on the physics of LW and the data we have, we could define T4_mean as the mean of Tair^4^  over the 6 (split) dt' in the interpolation period. Then the value of LW(t0+n*dt') = LW(itau_n) * Tair(t0+n*dt')^4^ / T4_mean. I think this is conservative, but it needs to checked.
 - Shall we understand that the default spred_prec is one in orchidee_driver ? We recently made a collective choice to take spred_prec=split/2, is it overlooked in orchideedriver?
@@ -65 +66 @@
 '''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_n, 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.
+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_n, 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, perfectly coherent with the first panel of the above graphic, and tractable by dim2driver with the good values of inter_lin and netrad_cons.
 
 It further means that, whichever the interpolation we perform, for WFDEI case, the average of the interpolated flux over the 3h that precede t0+dt must equal the value read in record itau_n. It thus implies that any interpolation that does not preserve the mean over [t0,t0+dt] is inappropriate for such a flux. 
@@ -73 +74 @@
 
 == 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.
+As described above, the driver of ORCHIDEE is relatively rigid because it makes strict assumptions on 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.
 We suggest to add a time_bounds attribute to the time variables stored in the Netcdf forcing file according to the CM convention : http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html