Changes between Version 3 and Version 4 of Branches/Driver_Improvements


Ignore:
Timestamp:
2012-09-13T10:41:46+02:00 (12 years ago)
Author:
nvuilsce
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Branches/Driver_Improvements

    v3 v4  
    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: 
     9 The fields read at a certain time step t in the Netcdf file correspond to: 
    1010the instantaneous value at t+1 for Temperature, Wind Speed, Air Pressure and Specific Humidity.  
    1111the mean value between t and t+1 for Long and Short Wave Incomming Radiation and the Precipitation.  
    … …  
    1919== Add an explicit time information within the forcing files == 
    2020As 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 
     21We 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 
    2222It 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.  
    2323Questions that remain: 
    … …  
    2828As the driver is built now, the first time step read (for the Temperature for instance) is valid for t+1. This means that for a yearly file at a 6-hourly time resolution, the first temperature read is for "1-JAN 06:00". For a simulation starting from scratch (no restart), the driver uses the first value for the second day ("2-JAN 00:00") in order to interpolate with the first one readed (and to calculate half-hourly values between "1-JAN 00:00" and "1-JAN 06:00". At the end of a simulation, the last forcing file read is not written in the restart file of the driver. When 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). We suggest to restart the last time step read of the meteorological variables in order to be make possible this. 
    2929 
    30      
     30== Remove the reading of the watchout files == 
     31In ORCHIDEE, there is the possibility to write in an output file, the meteorological fields used during the simulation. It is a feature useful when doing a coupled simulation (ORCHIDEE coupled to LMDz) in order to be capable to re-use this 'forcing' in off-line mode. These output files are named WATCHOUT files. These WATCHOUT files are not based on the same template than the standard forcing files read by ORCHIDEE. Consequently, there are specific reading for these WATCHOUT files. We suggest to : 
     32 * either generate the WATCHOUT files in ORCHIDEE under the format than a standard forcing file 
     33 * or, develop a specific tool that convert the WATCHOUT file into the same format than a standard forcing file. This tool will be launch as a pre-treatment. 
     34 
     35 
    3136  
    3237