# Seasonal forecast data 'soilLayer' values for each model **URL:** \ **Category:** C3S - Datasets and Usage\ **Tags:** seasonal\_forecast\ **Created:** [28 May 2025 13:24 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242 "2025-05-28T13:24:31Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Lluis\_Fita\_Borrell](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/d07c76/32.png) [@Lluis\_Fita\_Borrell](https://forum.ecmwf.int/u/Lluis_Fita_Borrell)\ **Post date:** [28 May 2025 13:24 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242/1 "2025-05-28T13:24:31Z")
Dear all, I am working using available data from the ‘seasonal forecast’ data-set. When using the variable ‘vsw’ (volumetric soil moisture) it has a vertical dimension called `soilLayer` with different extent for each available model. ```auto vsw(number, forecast_reference_time, forecast_period, soilLayer, latitude, longitude) ``` However, in the downloaded files (netcdf version) it is not provided the actual value in `cm` or `m` of the ‘soilLayer’, instead only the index is provided. ```auto double soilLayer(soilLayer) ; soilLayer:_FillValue = NaN ; soilLayer:long_name = "original GRIB coordinate for key: level(soilLayer)" ; soilLayer:units = "1" ; ``` where it should be 2-dimensional to indicate, beginning and end of each layer, or assume that it is centered to the depth of the layer I can not compare the differences between models, because I can not ensure the correspondence in depth of the actual values. Is there a way to know at which vertical levels corresponds each value of the variable for each GCM? I understand that for the ECMWF data would be: ```auto soilLayer=[(0.,7.), (7.,28.), (28.,100.), (100.,255.)] cm ``` Many thanks in advance ---
**Author:** ![Eduardo\_Penabad](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/e/6a8cbe/32.png) [@Eduardo\_Penabad](https://forum.ecmwf.int/u/Eduardo_Penabad)\ **Post date:** [28 May 2025 13:43 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242/2 "2025-05-28T13:43:09Z")
Hi @Lluis_Fita_Borrell unfortunately the information about the layers depths is currently not available within the GRIB files which are the base of the C3S seasonal forecast archive and therefore the netCDF files (created from the archived GRIB files) don’t contain that information. Currently users can find the information about soil layer depths for each forecast system in its description page, for instance for the recently introduced Météo-France System 9 you would have them [here](https://confluence.ecmwf.int/display/CKB/Description+of+System9-v20250101+C3S+contribution#:~:text=Soil%20levels%20(layers)). Similar tables are available for each one of the forecast systems. Unfortunately, that information is currently not available in any machine-readable format and it can be only extracted from those documentation pages. I hope that sounds useful. Best regards, Eduardo Penabad ---
**Author:** ![Lluis\_Fita\_Borrell](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/d07c76/32.png) [@Lluis\_Fita\_Borrell](https://forum.ecmwf.int/u/Lluis_Fita_Borrell)\ **Post date:** [28 May 2025 14:37 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242/3 "2025-05-28T14:37:57Z")
Thank you Eduardo, I see, following your web page I tried to figure it out, and I got the following values which I share here if any one is looking for something similar (all in meters), hope I do not misunderstood something: - ‘BOM’: [[0.,0.1], [0.1,0.35], [0.35,1.], [1.,3.]] - ‘CMCC’: [[0., 0.0175], [0.0175,0.0451], [0.0451,0.0906], [0.0906,0.1655], [0.1655,0.2891], [0.2891, 0.4929], [0.4929, 0,8289], [0.8289, 1.3828], [1.3828, 2.2961], [2.2961, 3.8019]] - ‘DWD’: [[0., 0.065], [0.065, 0.319], [0.319, 1.232], [1.232, 4.134], [4.134, 9.834]] - ‘ECCC’: [[0.,0.10], [0.1, 2.8]] - ‘ECMWF’: [[0.0, 0.07], [0.07, 0.28], [0.28, 1.], [1., 2.89]] - ‘MeteoFrance’: [[0., 0.01], [0.01, 0.04], [0.04, 0.1], [0.1, 0.2], [0.2, 0.4], [0.4, 0.6], [0.6, 0.8], [0.8, 1.0], [1.0, 1.5], [1.5, 2.0], [2.0, 3.0], [3.0, 5.0], [5.0, 8.0], [8.0, 12.0]] - ‘JMA’: [[0.,0.02], [0.02, 0.07], [0.07, 0.19], [0.19, 0.49], [0.49, 0.99], [0.99, 1.99], [1.99, 3.49]] - ‘NCEP’: [[0.,0.1], [0.1, 0.4], [0.4, 1.], [1.,2]] - ‘UKMetOffice’: [[0., 0.1], [0.1, 0.35], [0.35, 1.0], [1.0, 3.0]] When comparing between models, one should integrate the levels from each GCM that lay within a common set of levels used as reference. **NOTE:** I realize that there are different forecast systems for some models. In some cases, there use different amount of soil layers. When downloading data from Copernicus, we only can choose from a given set of `system` numbers (e.g. ECMWF: 4, 5, 51) that I choose accordingly to the dates I am working with, but I can not refer to which version of the forecast system to they correspond (this could be provided as additional metadata as global attributes in the netCDF format) Thanks ---
**Author:** ![Eduardo\_Penabad](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/e/6a8cbe/32.png) [@Eduardo\_Penabad](https://forum.ecmwf.int/u/Eduardo_Penabad)\ **Post date:** [28 May 2025 15:03 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242/4 "2025-05-28T15:03:00Z")
The tables in this section of the CKB (Copernicus Knowledge Base) documentation can be useful for that mapping between the GRIB “system” keyword (used also in the CDS requests) and the names used in the documentation > **[Description of the C3S seasonal multi-system - Copernicus Knowledge Base -...](https://confluence.ecmwf.int/display/CKB/Description+of+the+C3S+seasonal+multi-system#:~:text=Versioning%20of%20forecasting%20systems%20contributing%20to%20C3S)** ---
**Author:** ![Lluis\_Fita\_Borrell](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/l/d07c76/32.png) [@Lluis\_Fita\_Borrell](https://forum.ecmwf.int/u/Lluis_Fita_Borrell)\ **Post date:** [28 May 2025 17:00 UTC](https://forum.ecmwf.int/t/seasonal-forecast-data-soillayer-values-for-each-model/13242/5 "2025-05-28T17:00:52Z")
Hi @Eduardo_Penabad, Thank you, this was the information I was looking for, I would need to program that! Do you think that there could be a way that Copernicus could ‘fix’ the issue in the short/mid term?