10). A first draft of the new coding related to the further building of ECOCLIMAP-SG

This version of the coding for ECOCLIMAP-SG is only a first draft and will probably be modified in the next version of SURFEX. It will be used in V8_1 to do tests before the official release of ECOCLIMAP-SG.

The present documentation is not definitive but allows to know what is done at the moment of the V8_1 release.

1) Using ECOCLIMAP-SG or not

  • it’s still possible to use the regular ECOCLIMAP. To use ECOCLIMAP-SG, the new key LECOSG is set in namelist NAM_FRAC.
  • if LECOSG=.TRUE., the map defined in NAM_COVER, YCOVER, must contain values:
    • 1 for sea and oceans, 2 for lakes and 3 for rivers
    • from 4 to 23 for the 19 ISBA vegetation types
    • from 24 to 33 from CORINE urban types
      => urban types will be redefined following the standard classification provided by V. Masson.

2) The data parameters input files

To run the PGD with ECOCLIMAP-SG, we need to read from the namelist at least information for parameters:

  • LAI * 16 vegtypes * 36 10-day periods,
  • ALBNIR_VEG * 16 vegtypes * 36 10-day periods (if CALBEDO="CM13"),
  • ALBVIS_VEG * 16 vegtypes * 36 10-day periods (if CALBEDO="CM13"),
  • ALBNIR_SOIL * 36 10-day periods (if CALBEDO="CM13"),
  • ALBNIR_SOIL * 36 10-day periods (if CALBEDO="CM13"),
  • HEIGHT_OF_TREES * 8 tree vegtypes.

This represents 1808 maps. Additionally, for :

  • ROOT_DEPTH
  • SOIL_DEPTH
  • ICE_DEPTH

For these 3 parameters, it’s possible for the user to read its own maps (for the 19 vegtypes, so 57 additional maps), but currently, we use uniform values because we don’t have maps for these parameters. These uniform values are automatically initialized in the code with default values, but the user can prescribe its own values in namelist with XUNIF_ROOT_DEPTH, XUNIF_DICE, XUNIF_GROUND_DEPTH (for the 19 vegtypes)

If these maps are global at 300m-resolution, written in integer 8 bits, it represents 15610 giga-bytes. Moreover, reading these 1808 maps will take a very long time.

So we use a compressed information, according to two ways of compressing:

  • for a given parameter, we put the information for all vegtypes in one only file.
    • For example, for the LAI, the values in the file are calculated following:
      LAI_t = NINT(LAI*10) + (VEGTYPE * 100)
    • This way, the input file for all 16 LAI vegtypes is written in integer 16 bits, with values from 100 to 2000.
    • Such files are identified by a different CFTYP_... value in the namelist NAM_DATA_ISBA: "DIRTYP".
  • then we remove the "sea" information from the input parameters data files. Indeed, there is no value on sea for the ISBA parameters and it represents 70% of the map:
    • the new files are written with ACCESS="STREAM" and no more ACCESS="DIRECT".
    • For each line in the file (1 line = 1 latitude band, coded in integer 2 bits), we replace the zeros following each other by the number of zeros following each other. For example, at 1km-resolution, if a line contains only zeros, this line is coded like this:
      43200
      If this line contains 30 zeros, then 15 values different from 0, then 43155 zeros, this line is coded like this:
      30 val1 val2.... val15 43155
    • Still at 1km-resolution, the 21600 (number of lines in the file = latitude bands in the "DIRECT" file) first data in the new file are coded in integer 4 bits. They contain, for each line / latitude band the number of data written in the following of the new file.
    • In order to distinguish the "numbers of zeros" from the true values in the new files, the value 4000 is added to the "numbers of zeros".
    • At 300m-resolution, if more than 43200 zeros follow each other, in order to stay with integer 2 bits data, we write, for example, if 129600 zeros follow each other:
      47200 47200 47200
      (47200 = 43200 + 4000 and 43200*3 = 129600).
      Another example, if 50000 zeros follow each other,
      47200 10800
      (10800 = 680+4000 and 6800 + 43200 = 50000).
    • these types of files are identified in the .hdr file, with a new entry:
      compress: 1
      if this method of compression is used for this file.
  • The programs allowing to compress and uncompress files can be provided to users.
  • These two methods lead at end to only 184 maps, representing, at 300m-resolution, 728.55 giga-bytes, so a gain factor of 21.42 for the storage capacity.

3) The reading of input data parameters at the PREP and INIT steps

We choose to write the input data parameters for all 36 10-day periods in one only PGD file.

At PREP step, we now read in the PGD file only the 10-day period associated to the date of beginning of simulation.

At the INIT step in the run, we read in the PGD file only the 10-day periods needed for the duration of the simulation. For that, the date of end of simulation is now provided as argument in call to COUPLING_SURF_ATM.