Changes between Version 23 and Version 24 of Branches/Driver_Improvements

Timestamp:

2016-05-27T15:49:33+02:00 (8 years ago)

Author:

jpolcher

Comment:

--

Branches/Driver_Improvements

@@ -36 +36 @@
 
 It is important to understand that readim2.f90 is written in time steps and not physical time. There are 2 time step counters in the driver :
-- ''n'' : is the list of indices of the time axis in the forcing file and readdim2.f90 will step from n-1 to n.
-- ''itau'' : is the time stepping of ORCHIDEE and takes 'split' values between n-1 and n.
+- ''itau_n'' : is the last read index of the time axis in the forcing file and readdim2.f90. ''itau_nm1'' is the previously read value and will be used with ''itau_n'' for the interpolation. Note that ''itau_nm1 = itau_n - 1''.
+- ''itauin'' : is the time stepping of ORCHIDEE and takes 'split' values between ''itau_nm1' and ''itau_n''.
 
-The readdim2.f90 will then interpolate using values at ''n-1'' and ''n'' to obtain the forcing at ''itauin'', which is the current time step of ORCHIDEE. Once ''itau'' has stepped through ''split'' values, the forcing values of ''n'' will be copied to ''n-1'' and the new values for ''n'' will be read from the netCDF file.
-Because of this time-step approach the physical time chosen at ''n=1'' is very important.
+The dates at each of the time steps is given by ''t(itau_n)'' or ''t(itauin)'' for ORCHIDEE and we can write ''t(itau_nm1)=t0'' et ''t(itau_n)=t0+dt''.
 
-The time-stepping is done independently from the physical time. Thus it is the choice of the physical time at ''n=1'' which will determine at which dates the values of the forcing at ''n-1'' and ''n'' are valid. This poses no problem for instantaneous variables in the forcing file as then the indexing space (''n'') and the physical time are identical.
+The readdim2.f90 will then interpolate using values at ''itau_nm1'' and ''itau_n'' to obtain the forcing at ''itauin'', which is the current time step of ORCHIDEE. Once ''itauin'' has stepped through ''split'' values, the forcing values of ''itau_n'' will be copied to ''itau_nm1'' and the new values for ''itau_n'' will be read from the netCDF file.
+Because of this time-step approach the physical time chosen at ''itau_n=1'' is very important.
 
-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 ''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.
+The time-stepping is done independently from the physical time. Thus it is the choice of the physical time at ''itau_n=1'' which will determine at which dates the values of the forcing at ''itau_nm1'' and ''itau_n'' are valid. This poses no problem for instantaneous variables in the forcing file as then the indexing space (''itau_n'') and the physical time are identical.
+
+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.
 
 The graphic below explains probably better the above description.
@@ -51 +53 @@
 
 
-The upper panel of the figure is meant to illustrate that the interpolation for fluxes in all generality (here for fluxes valid over the forcing time step before the instantaneous values) will not produce an interpolated value at the same time as the scalar field. readdim2.f90 assumes implicitly that the interval of validity of the fluxes at index ''n'' are between ''n-1/2'' and ''n+1/2'' else the flux and scalar interpolations give results at different physical times.
+The upper panel of the figure is meant to illustrate that the interpolation for fluxes in all generality (here for fluxes valid over the forcing time step before the instantaneous values) will not produce an interpolated value at the same time as the scalar field. readdim2.f90 assumes implicitly that the interval of validity of the fluxes at index ''itau_n'' are between ''itau_n-1/2'' and ''itau_n+1/2'' else the flux and scalar interpolations give results at different physical times.
 
-The following explanations will probably help understand the meaning of the interpolated values in physical time. Let us suppose ''itauin'' is exactly the middle of the interval ''n-1'' and ''n''.
+The following explanations will probably help understand the meaning of the interpolated values in physical time. Let us suppose ''itauin'' is exactly the middle of the interval ''itau_nm1'' and ''itau_n''.
 From the upper panel of the figure we can deduce the following :
-- ''Tair(itauin) = (Tair(n-1)+Tair(n))/2'' will be valid at ''t(itauin) = (t(n-1)+t(n))/2'' thus the interpolated value is exactly in the middle of the physical time interval.
-- ''LWdown(itauin) = (LWdown(n-1)+LWdown(n))/2'' will be valid at ''t(itauin) = (t(n-2)+t(n))/2 = t(n-1)''. This is thus different from the time at which ''Tair(itauin)'' is valid. Exactly half a forcing time step away.
+- ''Tair(itauin) = (Tair(itau_nm1)+Tair(itau_n))/2'' will be valid at ''t(itauin) = (t(itau_n-1)+t(itau_n))/2'' thus the interpolated value is exactly in the middle of the physical time interval.
+- ''LWdown(itauin) = (LWdown(itau_nm1)+LWdown(itau_n))/2'' will be valid at ''t(itauin) = (t(itau_n-2)+t(itau_n))/2 = t(itau_nm1)''. This is thus different from the time at which ''Tair(itauin)'' is valid. Exactly half a forcing time step away.
 
-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 ''n'' are exactly valid over the time interval ''t(n-1/2)'' and ''t(n+1/2)''.
+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)''.
 
 == Add an explicit time information within the forcing files ==