New soil depth dimensions

[martinjuckes]

There are two variables in the data request which, I think, need new vertical coordinates. They are cSoilAbove1m (the carbon content in the soil above 1m depth) and cSoilBelow1m (the carbon content in soil below 1m depth).

The request currently includes, as in CMIP5, sdepth for all soil levels and sdepth1 for the upper 0.1m.

I propose to add sdepth1m for the upper 1m .. which would be a simple modification of sdepth1. I'm not sure how to specify the dimension for below 1m: it should have bounds from 1 to the bottom of the model. We could put in a large negative number? What do you think?

I intend to update the request today, but will not include this change.

[taylor13]

see https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/293 for further information about this.

[taylor13]

Let's hold off on doing anything until Martin modifies the data request. I think the CMOR tables will then automatically update.

[martinjuckes]

I'm planning to add two new dimension entries which will be adapted from sdepth1, one for the top 1m layer and a 2nd for the layer below 1m (Karl and I tried to talk Chris Jones out of using this, but so far he is standing firm). The tags that will change from sdepth1 are:

Top 1m layer: label: sdepth10 boundsValues: 0. 1. description: coordinate value for topmost 1 meter layer of soil tables: Emon uid: dim:sdepth10 valid_max: 2. value: 0.5 (the last 2 are 10 times the values used for sdepth1)

Layer below 1m: label: sdepthBelow boundsValues: 1. 100. description: coordinate value for layer of soil below 1m tables: Emon uid: dim:sdepthBelow valid_max: valid_mon: 0.5 value: 5.

Is it OK to have valid_min set and valid_max blank? Do these settings look OK?

[taylor13]

As I recall, valid_max and valid_min should be between the boundsValues, because the coordinate value should be between the bounds.

[martinjuckes]

That doesn't fit with the existing usage for sdepth1, which has bounds=0. 0.1, valid_max=0.2 (as for CMIP5). There is only one other coordinate with bounds and valid_min/max set, olayer100m, which is in line with what you were expecting: bounds=0. 100., valid_max=100.0, 'valid_min=0.0'. Can someone check how these parameters interact? I'm a little unclear about the distinction between the value/bounds_values pair on the one hand and requested/requested_bounds on the other.

[taylor13]

@martinjuckes I don't think we should accede to Chris' preference to store soil carbon below 1 m instead of total soil carbon.

For the record I've copied the email exchanges with Chris Jones. Chris did restate his preference, but recognized the reasonableness of our argument. There are apparently 3 pools of carbon of interest: total soil carbon, soil carbon in the uppermost 1 m and soil carbon below 1 m, someone will be inconvenienced by storing only two of these (because they will need to either subtract or add the other components to get what they need). There are advantages in terms of standard names and dealing with the different depths accounted for in different models to collecting total and the uppermost 1 m (an omitting carbon below 1 m as a variable). Chris' suggestion that what we do in the case of 2 quantities implying a third could also be done for n-1 quantities implying an nth. We are not suggesting our current approach be extending to a case for n>3.

One point not discussed below is what a modeling group should do if the bounds of one of their soil layers doesn't coincide with 1 m. Then they will have to apportion one of their layers between the reservoirs above and below 1 m. If they don't do that in a conservative way, users won't be able to accurately calculate the total subsurface soil carbon and carbon budgets won't balance. This potential problem I think trumps any preference one might have as to which two of the three carbon reservoirs are reported.

Here's the rest of the discussion:

Hello Chris,

The C4MIP request asks for cSoil (total carbon mass in soil pool, kg m-2), cSoilAbove1m (carbon mass in top 1m of soil pool, kg m-2) and cSoilBelow1m (carbon mass in soil pool below 1m, kg m-2).

There appears to be redundancy here because cSoil = cSoilAbove1m + cSoilBelow1m.

Can we remove the request for cSoilBelow1m?

regards, Martin

Hi Martin,

No, I'd prefer not to. Our rationale in C4MIP was to have tier-1 variables which were simple and contain the whole carbon cycle. And then to have tier-2 variables which were sub-components of the tier-1 ones. If you look at most of the boxes and arrows in our C4MIP GMD paper you can see how the top-level variables are sub-split for tier-2. So you could argue the same for only reporting all but one of the sub-components of other things... The same is true for all the various soil-moisture reports - you could report all but the lowest level and recreate that from the total. But I think it's much simpler and easier to have a complete set.

Thanks, Chris

Hi Chris,

I'm going to push back a bit on this. Please consider:

1) to minimize data volume, we normally refrain from asking for 3 quantities when 2 imply the third in an obvious way. We don't ask for net shortwave flux at the surface, but rather the components (downwelling and upwelling) from which the net can be computed. We ask for (total) precipitation, snowfall flux, and convective precipitation, from which both liquid precipitation and precipitation from clouds other than convective clouds can both be calculated. *** We ask for (total) soil_moisture_content, soil_frozen_water_content, and soil moisture content of the uppermost 10 cm from which both total soil liquid water content and soil moisture content below 10 cm can be calculated.

2) Definition of the layer below 1 meter is problematic because specifying the lower bound may be model dependent and in any case is ill-defined.

For these reasons I strongly encourage you to live with Martin's suggestion to save total carbon as tier-1 and as tier-2 just the carbon in the upper 10 cm of the soil? If you can't, could you please provide additional justification (other than the small inconvenience of having to perform a subtraction).

thanks and best regards, Karl

Thanks Karl - these sound like reasonable arguments... in return I'd say two things: 1 - I'd always favour saving human time over saving computer time. If we save <<1% of data volume but create a task for many scientists around the world to have to repeat then this is counterproductive. I don't mean we should be wasteful of space but I would certainly rather see machines as there to serve us rather than vice-versa... 2 - the more processing has to be repeated by individuals the more scope for errors. OK, so for this one it's fairly simple to subtract two fields, but nonetheless simply having the variable you want readily to hand (and named as such) does seem easier

To some extent you could pursue this approach much more widely - e.g. we request a breakdown of NPP into components on leaf/wood/root/other - should we list all but one of these and tell people to re-cerate the last one themselves? ditto almost all our tier-2 variables? Pretty much anything on land-fractions/tiles could do this too by only supplying all-but-one of the sub components. But surely the added complexity and scope for error outweighs the tiny cost of a complete set of data?

C

Hi Chris,

I agree that as a rule we should avoid calculations of common quantities that depend on more than two variables.

I also agree that machine time and storage is generally less valuable that people time.

cheers, Karl

[martinjuckes]

OK, I'll take out cSoilBelow1m, and add the sdepth10 dimension for cSoilAbove1m.

[taylor13]

@martinjuckes : while you're at it, wouldn't it make sense to modify the 10cm surface soil layer so that the valid_max lies between the upper and lower bound, i.e.:

Top 10dm layer: label: sdepth1 boundsValues: 0. 0.1 description: coordinate value for topmost 10 cm layer of soil uid: dim:sdepth1 valid_min: 0.0 valid_max: 0.1 value: 0.05

and then similarly define for the 1 m surface layer:

label: sdepth10 boundsValues: 0. 1. description: coordinate value for topmost 1 meter layer of soil tables: Emon uid: dim:sdepth10 valid_min: 0. valid_max: 1. value: 0.5

[martinjuckes]

OK, I'll take out cSoilBelow1m, and add the sdepth10 dimension for cSoilAbove1m.

[taylor13]

Martin has fixed the problem, I think, so this can be closed.