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

This version of the coding for ECOCLIMAP-SG is only a first version 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 allows to know what is done at the moment of the V8_1 release.

This article is the presentation of ECOCLIMAP-SG at the moment of the V8_1 release. For more recent informations about ECOCLIMAP-SG, please refer to the ECOCLIMAP-SG wiki

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 for 33 covers (3 water / 20 nature / 10 urban) :
1 Sea and Oceans 12 boreal needleleaf evergreen 23 flooded grassland
2 Lakes 13 temperate needleleaf evergreen 24 urban LCZ1: compact high-rise
3 Rivers 14 boreal needleleaf deciduous 25 urban LCZ2: compact midrise
4 Bare soil 15 shrubs 26 urban LCZ3: compact low-rise
5 Bare rock 16 boreal grassland 27 urban LCZ4: open high-rise
6 Permanent snow 17 temperate grassland 28 urban LCZ5: open midrise
7 Boreal broadleaf deciduous 18 tropical grassland 29 urban LCZ6: open low-rise
8 Temperate broadleaf deciduous 19 winter C3 crops 30 urban LCZ7: lightweight low-rise
9 Tropical broadleaf deciduous 20 summer C3 crops 31 urban LCZ8: large low-rise
10 Temperate broadleaf evergreen 21 C4 crops 32 urban LCZ9: sparsely built
11 Tropical broadleaf evergreen 22 flooded trees 33 urban LCZ10: heavy industry

2) The data parameters needed as input files

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

  • LAI * 17 vegtypes * 36 10-day periods,
  • ALBNIR_VEG * 17 vegtypes * 36 10-day periods (if CALBEDO="CM13"),
  • ALBVIS_VEG * 17 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 * 10 vegtypes (with trees/shrub)

This would represent 1918 maps. Additionally, for :

  • ROOT_DEPTH
  • SOIL_DEPTH
  • ICE_DEPTH

For these 3 parameters, 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 20 types of nature)

All these maps represent a lot of data. 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 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.

Also in this section