GRIB-API definition
Name | Volumetric soil moisture | Abbreviation | vsw | Unit | m3 m-3 | paramId: | 260199 |
UERRA details
Definition | Volumetric soil moisture of a soil layer. |
Validity | instantaneous |
Comment | Sea points should be set as missing values (encoded as bitmap). Soil layers must always start from 1 (0 soil level is the surface by default which is not encoded). To interpret soil moisture and to compare different models the Soil Wetness Index (SWI) is used: |
WMO GRIB2 definition
Parameter | ||
---|---|---|
Discipline | 2 | land surface products |
Parameter category | 0 | vegetation/biomass |
Parameter number | 25 | volumetric soil moisture |
Level | ||
---|---|---|
Type of first fixed surface | 151 | soil level** |
Scale factor of first fixed surface | 0 | |
Scaled value of first fixed surface | 0/1/2/3/.../X-1 | n-1 for the nth soil layer |
Type of second fixed surface | 151 | soil level* |
Scale factor of second fixed surface | 0 | |
Scaled value of second fixed surface | 1/2/3/.../X | n for the nth soil layer |
**newly approved level type (WMO release in May 2016)
10 Comments
Richard Mladek
How is soil moisture handled in TIGGE:
http://tigge.ecmwf.int/tigge/d/show_object/table=parameters/name=soil_moisture/levtype=sfc/
Example of soil layers in MARS:
http://apps.ecmwf.int/mars-catalogue/?class=rd&expver=ge8f&stream=oper&type=an&levtype=layer
The attached sm.layers.grib2 contains soil moisture in 6 layers between soil levels 0/1/3/7/15/25 cm.
Update: This comment can be considered as obsolete as the layers are fixed in IFS and this is not generally the case for UERRA products.
Richard Mladek
As the soil levels differ generally over UERRA integration domains there is a need for a new WMO soil layer type. The UERRA partners would have to provide then also the soil level depths for each grid-point.
For Meteo-France the soil layers could be defined as usually between appropriate levels below surface:
Regarding GRIB-API there exists at the moment definition for Volumetric soil moisture with Number 25 under Discipline 2, Category 0 (vegetation/biomass) (paramId 260199). Following the latest changes in WMO it would be appropriate to ask them to make that parameter deprecated and create its equivalent under Discipline 2, Category 3 (soil products). It would be consistent e.g. with Soil temperature which is defined in the same group of soil products.
Richard Mladek
Further discussion and investigation is needed:
Richard Mladek
Related links:
Sebastien Villaume
so what did we decide here?
do we do soil levels for all partners but MF and use depth levels for MF?
Sebastien Villaume
copy of my comments sent to Per, Eric, Manuel and Richard:
We have two ways of modelling the soil if I understood correctly when I discussed with Eric last year.
first case:
levels (or layers) have fixed depths (or thickness) for all grid box.
These can be represented using "depth below land surface" type of level (106) and associated levels. The levels are in this case the depth in meters where the levels lie (or in the case of layers, the depth in meters of the bottom of the layers)
If I understand correctly Richard's comment on the UERRA confluence pages, this is the case for meteoFrance only (or it is the opposite? because I thought meteoFrance was using variable depths and other partners have fixed depths)
second case:
levels (or layers) have grid box dependent depths (or thickness), i.e. each grid box has its own local set of depths
These can not be represented using "depth below land surface" type of level (106) because the levels or layers are different for each grid box. This is why we created (and ask WMO) a new level type to define generic depth levels. In this configuration, the type of level is 151 (Generalized depth level) and the levels are 1,2,3,..,n. Then we provide a side parameter called "soil depth" in a separate GRIB message for each level 1,2,3,..,n
We could use both way of encoding depending on the model: if it is fixed depths, use case 1, if it is variable depths use case2. This means inconsistency across models/data providers. My limited experience with S2S here at ECMWF tells me that inconsistencies in data representation is a nightmare for us to maintain, has an impact on archiving/serving the data and is a nightmare for users because they need to remember what is the convention for each data provider.
But!! nothing prevents us to encode fixed depth models on generalized depth levels!
It means we use type of level 151 everywhere, levels=1,2,3,..n everywhere, and always provide soil depths even if it is a constant field for the fixed depths models. You will get an arrays of 3's for the 3cm depth level, an array of 15's for the 15cm depth level, etc. It is a bit useless, slightly space consuming but you get a huge win on the consistency side!
What do you think?
francois besson
Hello,
We have to provide volumetric soil water (the liquid +solid water content in m3/m3) and soil water index (SWI)
The soil water index might not be described as a volumetric soil water. This could lead to misunderstanding : getting SWI while whishing to retrieve volumetric soil water
Is it possible to use a local description for the SWI ?
François
Richard Mladek
Hi Francois,
A good point actually. Those fields capacity and wilting point are not on uerra list at all so I removed them from our soil moisture parameter description as well. Basically it was copied from tigge description of the same parameter. I believe there was a good scientific intention to be able to compare that SWI index that time. Unfortunately even in tigge archive, those 2 parameters were provided only by MO and for very limited period.. Regarding uerra the situation is even simpler as the soil schemes and soil levels are completely different in models' outputs so not comparable any way at all. Please forget about wilting point and field capacity fields. Thank you.
Richard
francois besson
Hi Richard,
OK about Wwilt and Wfc.
How to encode differently SWI and Volumetric Soil Water as we have to provide both of them.
SWI is not present in the WMO guide isn'it ?
François
Richard Mladek
SWI is not required either of course. It could have been computed from Wwilt and Wfc.