Changes between Version 124 and Version 125 of Documentation/Forcings


Ignore:
Timestamp:
02/26/21 18:37:16 (2 months ago)
Author:
xnwang
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/Forcings

    v124 v125  
    4343Last, depending on the options activated within a run of ORCHIDEE, additional maps might be used for irrigation, slope for routing scheme, ... 
    4444 
    45 ==  0. General information == 
     45==  1. General information == 
    4646 
    4747(a) '''Usually, the forcing files are stored in the shared accounts''' in IGCM/SRF/METEO directory.  
     
    8181* '''Physical definition of the forcing variables''': both drivers follow the same conventions. In particular, the following measurement heights are assumed by default: 2m for Tair and Qair; 10m for Wind. Further details in [attachment:Description_Forcing_Files.pdf]. 
    8282 
    83 == 1. Drivers for interpolating forcing data in ORCHIDEE == 
    84 We have two drivers available, src_driver/dim2driver and src_driver/orchideedriver. We would like to have only one standard driver for ORCHIDEE in the end. 
    85  
    86 == 1.1 the old driver (src_driver/dim2driver) == 
    87    This driver assumes that scalar variables (Tair,Qair,Psurf,Wind) are instantaneous values at the timestamp, while flux variables (Rainf,Snowf, SWdown, LWdown) are mean values over the interval ending at the timestamp. This driver also requires that the first value of the annual files corresponds to 00UTC+dt_forcing (for instance 03UTC for a 3hourly forcing), and that the last value is for Dec 31st at 24UTC = 00UTC on Jan 1st of the following year. Your files must be prepared accordingly.  
    88  
    89 * '''Cell-method time attribute''':  
    90    - The time attributes are optional but recommended, so the files can also be used by the new driver. 
    91    - This time attributes should be "time: instantaneous" for the scalars (Tair,Qair,Psurf,Wind), and "time: mean(end)" for the fluxes (Rainf,Snowf, SWdown, LWdown). If the physical definitions of your forcing variables do not fit this scheme, then you should avoid using this forcing with dim2driver, unless you manage to adapt your files to these constraints.  
    92  
    93 * '''SPRED_PREC''': By default, we spread the precipitation over half the forcing time step (1.5h and 3h respectively for 3-hourly and 6-hourly files).  
    94  
    95 == 1.2 the new driver (src_driver/orchideedriver.f90) == 
    96   This driver is expected to be more flexible and to deal with any temporal structure of the forcing datasets, provided the required attributes are inserted in the forcing files. This document [attachment:Description_Forcing_Files.pdf] provides details of how forcing files need to be prepared. It addresses in particular the issues one may face when the fluxes are averaged and scalar variables are instantaneous. The driver needs to take this into account,otherwise the diurnal cycle can be misplaced. Some data providers have different conventions for representing averaged fluxes, and such information is important to know.   
    97  
    98 * '''cell_methods time attribute''': you need to add a time attribute to each variable, e.g. "time: instantaneous" our "time: mean(end)", further details in [attachment:Description_Forcing_Files.pdf]. The new driver can work with forcing files of various cell methods, while the old driver works with specific forcing data (CRU). 
    99   
    100  
    101 * '''SPRED_PREC''': In the driver files precipitation is the accumulated value over the time step of the driver file (e.g. 6 hours). In ORCHIDEE it needs to be decided whether over which time period (in seconds) this precip will come down. Short periods make rain storms, long periods make drizzel. In the new driver, we have '''SPRED_PREC_SEC''' in PARAM/run.def with a relative small value, ie., 3600 (ie., 1hour) by default. 
    102  
    103 * '''restart file''': The new driver does not need the restart file in the orchideedriver.card, while the old driver does have restart file in the orchidee_ol.card.  
    104  
    105 The structure and the organisation of the new driver code is quite different from the older driver. While the older driver has the main code dim2_driver.f90 by calling readdim2.f90, the main code of new driver is  orchideedriver.f90 by calling globgrd.f90, forcing_tools.f90, forcingdaily_tools etc.  
    106  
    107 * The organisation and the structure of orchideedriver.f90 are improved compared to dim2_driver.f90, with more comments in the codes. 
    108  
    109 * forcing_tools.f90: deals with forcing files, open, interpolation, writing.  The most important routines of foring_tools are forcing_open and forcing_getvalues. 
    110       
    111 * globgrd.f90:  manage the spatial grid of the forcing. It can either read a file containing the grid information, as is the case for WRF forcing, or obtain the grid from the forcing files. 
    112  
    113 == 1.3 Previous discussion and recent efforts about the new driver == 
    114 A long discussion on the differences between the two drivers (dated in 2016) can be found on https://forge.ipsl.jussieu.fr/orchidee/wiki/Branches/Driver_Improvements. 
    115  
    116 The work on the new driver has been picked up since July 2020 by X. W. A short report summarizes the first part of this efforts and can be found on https://forge.ipsl.jussieu.fr/orchidee/attachment/wiki/Documentation/Forcings/nouveau_driver_doc.2.pdf. 
    117  
    118 '''Summary of recent progress ''' on the integraton of new driver in the trunk (until the end of 2020): 
    119  
    120 * the recent version of new driver from Jan. P is included in the trunk  
    121 * fixed a bug when using the forcing file of coarse resolution: corresponding to the ticket https://forge.ipsl.jussieu.fr/orchidee/ticket/575 
    122 * modified several places in orchidee in order that the new driver can be used not only for FG3, but also for spinup analytic and fg1trans. 
    123 * identified that the old and the new drivers have the reversed order of latitude when writing the restart file 
    124  
    125 '''Codes or files modified or added:''' 
    126  
    127 * fortran code: significant modification to src_driver/forcing_tools.f90, slight change to src_driver/orchideedriver.f90 
    128 * libIGCM : libIGCM/libIGCM_config/libIGCM_config.ksh 
    129 * configuration files: COMP/orchideedriver.driver ( mainly for spinup analysitic and fg1trans) , PARAM/run.def ( mainly for spinup analysitic and fg1trans), PARAM/orchidee.def : routing=n (in the tests by using forcing files of coarse resolution) 
    130 * A new script AddYears : to prepare for the forcing files, which is to be integrated to the modele/utils. (This script was modified and generalized based a script of Jan). 
    131  
    132  
    133 '''Remarks for the knowledge of users of the new driver:''' 
    134  
    135 1) The new driver need the forcing files of previous, current, and next year. 
    136         Suppose that we have forcing files over 1901-1910, we need forcing files for 1900 and 1911 when using the new driver. The script AddYears is to prepare for such forcing files. 
    137         * If we can put the new forcing files into the forcing repository: the users do not need run this script, or modify the data path in .card. Running a simulation with new driver will be the same as the old one, since the good configuration files .card should be in the experiment folder. 
    138         * If the additional forcing files are not in the IGCM repository, the users need to: a) run the script AddYears firstly, b) then modify the forcing path in the orchideedriver.card by using the right path to the forcing files before launching simulation.c) be careful about the calendar type for different forcing files. 
    139  
    140 2) The number of MPI is 63 in the config.card by default if using WFDEI 0.5 degree, and it is smaller if using CRU 2degree. So the users should choose the right forcing files for their simulation firstly, and then use a good MPI number.  
    141  
    142 3) in PARAM/orchidee.def: if we use forcing file of coarse resolution, it would be better to set RIVER_ROUTING = n to avoid possible errors. 
    143  
    144                    
    145 '''A few more things to do:''' 
    146  
    147 * to make sure of the complete integration of the new driver in the recent version of trunk (libIGCM, script) 
    148 * to test the new driver in the recent version of trunk by running spinup analytic, fg1trans and fg3 
    149 * to discuss if we would like to do more comprehensive comparisons of the simulation results from the new and the old driver 
    150 * if yes, need decide some strategy of the comparisons, ie., which parameters to evaluate (gpp, evaporation, lai and others), which statistics, using some observations for comparison or not etc 
    151  
    152  
    153  
    154  
    15583 
    15684