Changes between Version 47 and Version 48 of Branches/Driver_Improvements


Ignore:
Timestamp:
2016-06-09T15:37:39+02:00 (8 years ago)
Author:
nvuilsce
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Branches/Driver_Improvements

    v47 v48  
    1616 
    1717>'''AD (26/5/16)''': Note that, in the above case, the time at which we read the forcing is t0+dt.  
    18 >> NVui: To my opinion, the time at which we read the forcing is t0, not t0+dt because the instantaneous value at t0+dt is needed to interpolate the field from the t0+dt' time step and the mean value between t0 and t0+dt is needed from the t0 time step.  
     18>> '''NVui (09/06/16)''': To my opinion, the time at which we read the forcing is t0, not t0+dt because the instantaneous value at t0+dt is needed to interpolate the field from the t0+dt' time step and the mean value between t0 and t0+dt is needed from the t0 time step.  
    1919>>  
    2020>> I would like also to remind that in the current driver, the information stored in the time variable (or timestp variable) is not used for defining the time stamp. Consequently, what is written here about the timestamp and the time at which the data is relevant (instanteneous, +dt, ...) is only implicit here. The time or timestp variable in the Netcdf file is only used for defining the timestep (dt) of the forcing.  
    … …  
    2828>For me, these are general principles which need to be true whichever the forcing if we decide to read together all the variables that have the same time stamp. The fact that fluxes are averages over a period of length dt after or before the time stamp can be dealt with in the above general framework (but the latter is an opinion). 
    2929 
     30>> '''NVui (09/06/16)''': I agree with the above comment 
     31 
    3032 
    3133== Interpolation ==  
    … …  
    3638>'''AD (26/5/2016):''' I agree on the above general guidelines for interpolation, '''but''' : 
    3739>- 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.  
     40>> '''NVui (09/06/16)''': I agree with this. 
    3841>- 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. 
     42>> '''NVui (09/06/16)''': Yes, I confirm. The flag 'inter_lin' controls only the flag 'netrad_cons'. So I think it is useless. The same for the boolean 'no_inter'.   
    3943>- 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 be checked. 
     44>> '''NVui (09/06/16)''': I could eventually test this interpolation at fluxnet stations.  
    4045>- 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? 
    4146>- For the SW, what are the low incidence angle problems? It must be kept in mind that there is no particular reason why the diurnal cycle of SW should be either very smooth or well centered at noon. We do not deal with extra-terrestrial radiation, but incident SW  at the surface, and the noise induced by clouds can be very large. 
    42  
     47>> '''NVui (09/06/16)''': Even if clouds may induce noise, I don't think they can't explain the strange values under low incidence angles that Jan reports. The SWdown interpolated by orchideedriver at 6pm has systematic spikes, with values of the same order than those at noon. This is not realistic. To my opinion, there is by a bug in the interpolation scheme.  
    4348 
    4449=== Jan's understanding of the working of dim2driver (Jan 26/05/2016) ===