Changes between Version 5 and Version 6 of Branches/Driver_Improvements


Ignore:
Timestamp:
2012-10-25T15:00:23+02:00 (10 years ago)
Author:
jpolcher
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Branches/Driver_Improvements

    v5 v6  
    11= Improvements of the Driver of ORCHIDEE = 
    22 
    3 These improvements will concern first the specifities of the driver (its capacity to read forcing files), not its performances that will be improved hopefully by the use of the IOServer. 
     3These improvements will concern first the specificities of the driver (its capacity to read forcing files), not its performances that will be improved hopefully by the use of the IOServer. 
    44The focus is mainly on the use of forcing files at a 6 or 3-hourly time resolution (such as re-analysis), for which the driver interpolates the meteorological fields to calculate half-hourly fields. 
    55 
     
    77The driver of ORCHIDEE is expected to read forcing files with a very specific temporal structure. 
    88All time information are defined on UTC time. 
    9 The fields read at a certain time step t in the Netcdf file correspond to: 
    10  * the instantaneous value at t+1 for Temperature, Wind Speed, Air Pressure and Specific Humidity.  
    11  * the mean value between t and t+1 for Long and Short Wave Incomming Radiation and the Precipitation.  
     9The fields read at a certain time step t in the NetCDF file correspond to: 
     10 * the instantaneous value at t of scalar variables :  Temperature, Wind Speed, Air Pressure and Specific Humidity.  
     11 * the mean value between t and t+1 (or t-1 and t) for fluxes : Long and Short Wave incoming Radiation and the Precipitation.  
     12The time interval represented by each variable needs to be documented in the netCDF file (see below). 
     13 
    1214 
    1315Interpolation 
    14   * Instantaneous fields and the Long-Wave Radiation are then linearly interpolated for each t:t+1 time period in order to calculate half-hourly value. 
    15   * The Precipitation field is downscaled to half-hourly resolution using a step distribution function with one parameter (nb_spread, that is the number of half-hourly time steps over which we spread the precipitation). nb_spread can vary from 1 (all precipitations over a forcing time period (3 ou 6 hours) are put on the first time step) to SPLIT_DT (number of integration time steps with a forcing time period, in that case, the precipitation are distributed uniformely). By default, nb_spread is set to 1. We may wonder if it is the most appropriate default value. I (Nicolas Vuichard) would recommend to set nb_spread to SPLIT_DT, by default.  
    16   * The Short-Wave radiation is interpolated using a function distribution that corresponds to the solar angle distribution over a forcing time period. 
     16  * Instantaneous fields and the Long-Wave Radiation are then linearly interpolated for each model time-step t' (typically 1/2 hour) based on the values available a t and t+1 with t < t' < t+1. ''Should we not change that for long-wave radiation so that we have one consistent procedure for scalars and another for fluxes ? '' 
     17  * The Precipitation field is downscaled to model's temporal resolution using a step distribution function with one parameter (nb_spread, that is the number of half-hourly time steps over which we spread the precipitation). nb_spread can vary from 1 (all precipitations over a forcing time period (3 ou 6 hours) are put on the first model time step) to SPLIT_DT (number of integration time steps with a forcing time period, in that case, the precipitation are distributed uniformly). By default, nb_spread is set to 1. This default value is not appropriate for all climates and it would make sense to have typical values for various regions of the world (see thesis of T. d'Orgeval.).  
     18  * The Short-Wave radiation is interpolated using a function distribution that corresponds to the solar angle distribution over a forcing time period and conserving the average flux for the [t,t+1] interval. Under low incidence angles this interpolation gives at times strange values, this needs to be checked and improved. 
    1719 
    1820 
    1921== Add an explicit time information within the forcing files == 
    20 As described above, the driver of ORCHIDEE is relatively rigid because it only assumes 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. 
    21 We suggest to add a time_bounds attribute to the time variable stored in the Netcdf forcing files. See here for instance for a possible use: http://www.cgd.ucar.edu/cms/eaton/netcdf/NCAR-CSM.html 
    22 It is not clear how to use the time_bounds attribute within a multi-variables file, in which the variables have different time specifications (instantaneous vs cumulative variables). The use of a time_op attribute (average, point) for each variable could be a solution. The time specification of a forcing file (based on time_bounds and time_op attributes) should be read by the driver, in order to check for consistency.  
     22As 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. 
     23We 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 
     24 
     25Each file will contain at least 2 time axes, one for the scalar variables and one for the flux variables. Each of the time axes will have its "time_bounds" variable in order to describe the interval each value describes. 
     26 
    2327Questions that remain: 
    24  * How to implement in detail such a solution 
    25  * Is it an optional feature or do we request these specifications for any forcing file.  
     28 * How to implement in detail such a solution without perturbing too much the day-to-day usage of ORCHIDEE. 
     29 * It would be most easily managed if we build a library of forcing files available to all at IPSL and which contains only forcing data sets with all the information. 
     30 * Should we try to support old and incomplete forcing files and for how long ? 
     31 * The improved driver should use all the extra time information in the forcing files but this might require some changes to IOIPSL. 
    2632 
    2733== Restart the last forcing time step read == 
     
    3137When we perform monthly runs using a yearly forcing file, it is managed within the driver to use the appropriate time step in the forcing file but when we perform yearly runs using a yearly file, we process as for a run starting from scratch (while we could use the last values read during the last run). [[BR]] 
    3238We suggest to restart the last time step read of the meteorological variables in order to be make possible this. 
     39 
     40Once the improved driver knows about the time interval over which the forcing is valid, then we can test if the restart date is correct and we can dump the next restart at the end of the time interval.  
    3341 
    3442== Remove the reading of the watchout files ==