Volumetric soil water

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.

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:

1. top 1cm
2. top 5cm
3. from surface to the bottom of root zone (Type of second fixed surface 167)

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.

Further discussion and investigation is needed:

• if it is possible to archive it in MARS with Type of first fixed surface = 106 similarly as mentioned in the 1st comment
• if to ask WMO for new level type soil layer (it is complex problem as the varying soil level depths for each grid-point should have to be encoded as well)

so what did we decide here?

do we do soil levels for all partners but MF and use depth levels for MF?

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?

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

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

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

SWI is not required either of course. It could have been computed from Wwilt and Wfc.