Consistency of ice points between soil and vegetation

[ccarouge]

We want to enforce consistency in ice points between soil and vegetation in CABLE. Ideally, input data should be consistent but it can't be relied on.

We want to do the following

ice soil => ice veg

All ice soil points (isoilm=9) should have ice vegetation (iveg=17), i.e.:

IF (soil%isoilm == 9) THEN
   veg%iveg=17
END IF

New ice vegetation tiles should have their parameters (veg%) changed to use the parameters for ice. This should ideally be done close to when veg% parameters are set.

ice veg => ice soil

All ice vegetation (iveg=17) should have ice soil (isoilm=9).

New ice soil tiles should have their soil parameters changed to use the parameters for ice. For frozen soil, the only ones we want are soil%rhosoil=910 and soil%css=2100. These 2 parameters need to be added to some CABLE constants (they are the density of frozen water and specific heat of frozen water), they will not be read from namelists or inputs. They are physics constants anyway.

Again this should be done close to when soil% parameters are set.

Don't use hard-wired values

In the explanation above I used hard-wired values (iveg=17 and isoilm=9), we want to replace these by some constants instead of the direct hard-wired index. Some of this already exists in the code: https://github.com/CABLE-LSM/CABLE/blob/a6e0dccd19ee16158d64891979033f92d98197c5/src/params/grid_constants_cbl.F90#L47-L48 Just need to add the frozen vegetation index to it and use that. Eventually, we will want these in namelist files but let's not do that as part of this issue.

Warning

Add a nice explicit warning message that the tiles have been changed for consistency. Explaining what changes CABLE does.

[ccarouge]

@rkutteh Above is an explanation of what we need to do to advance on the GW merge. Let me know if it does not make sense.

[JhanSrbinovsky]

cable_surface_types reads in the surface type index in AM3 at least. From memory it is partially done in JAC as well.

In the UM we effectively hard-wire soil%isoilm = 2 EXCEPT where veg%iveg = ICE. then we use soil%isoilm = 9 so that we can pick up our ICE params for soil type = ice. All the UM soil params come in spatially anyway.

I think the difference that we need to avoid is in the "maps" not agreeing. We have found only a few cells where they didn't match up. HOWEVER, this pertains to UM coupled applications only. My only concern might be that if you did this below the application/driver level it might make it difficult to debug and identify problems to start with (by forcing it one way or the other)

[rkutteh]

@har917 @JhanSrbinovsky @ccarouge The code for ensuring that in the case of a non-ice soil patch sitting below an ice veg patch, the soil patch is changed to ice, and in the case of a non-ice veg patch sitting above an an ice soil patch, the veg patch is changed to ice, is almost finished and ready for testing.

However, following a discussion with Claire today it became clear that implementing this consistency check between the veg patch and the soil patch underneath is going to lead to situations where soil patches of more than one type will occur in a single grid cell. Claire raised the issue of whether having patches with more than one soil type in any grid cell is going to cause issues (e.g., averaging problems), ...and Claire can probably add to my question.

[JhanSrbinovsky]

You must mean in ACCESS right? ACCESS has multiple PFT types per grid cell (in principle), but only one soil type per grid cell, and we couldn't change that as there is no field that defines soil type per grid cell in ACCESS. So I'm not quite sure how a problem could arise.

However, it sounds like your fix is a per timestep fix? i.e. It is not so straight forward to permanently change the PFT (veg) type in ACCESS.

[rkutteh]

@JhanSrbinovsky I am mainly talking about introducing a fix along the lines of the code in SUBROUTINE check_parameter_values in offline, where individual soil patches are referenced in some of the tests. It seemed to me from the tests in this code that offline CABLE can accommodate different soil patches in a grid cell.

[har917]

@JhanSrbinovsky - this relates to CABLE issue 124

@rkutteh is proposing a 'sanity check' component in the process when evaluating soil% from soilin% (either via grid info or ACCESS ancillaries) and veg% from vegin%. This would occur at/shortly after initialisation in both offline and coupled models. At the moment you can engineer circumstances where you have plants growing into ice or an ice surface sitting on top of non-ice soil.

From a CABLE-in-ACCESS perspective - because this would act only on CABLE's tiled parameters and variables - I think this would be okay (provided it was done with care). It may actually be a non-issue since I suspect that there are no grid cells with both ice and veg tiles. My slight concern is in the ordering - this would need the soil type and vegetation (tile) type maps to be read in, then sanity check applied, then the soil and veg parameters filled from soilin% and vegin%. This is a different structure to how initialisation is done currently, certainly in ACCESS.

There could also be issues with the intersection with the rivers scheme - since the river routing ancillary will be set up to be consistent with the JULES soil map (which won't be adjusted by the proposed consistency check) - but that's likely to be minor.

[ccarouge]

@har917 @JhanSrbinovsky I know you have your heads deep within ACCESS but this has nothing to do with the coupled model. The change sits totally on the I/O side which can behave totally differently in offline and coupled without problems. This sanity check and enforcing correspondence of ice type would be implemented in offline only. The implementation in the coupled version can be discussed at another time.

The question here is whether CABLE is supposed to have patches for different vegetation types in a grid cell with all patches in a grid cell having their own soil column but all columns have the same soil type.

Do you know if this assumption is still correct?

This assumption will be broken when applying this code change as within a grid cell a patch might then have an ice soil type and not the others.

Is there any point in the code that you know of where this assumption is needed to get the correct output? I'm mainly thinking about when we average patches to grid output.

@har917 we are actually proposing to implement this check at the end of reading all the inputs and calculating the derived parameters. This is because sometimes the veg and soil types are given in other files (met file or restart) and replace the default (gridinfo or namelist). So we want to make sure the final type, the one actually used in the simulation, is changed.

[har917]

with all patches in a grid cell having their own soil column but all columns have the same soil type.

As far as I know basic CABLE and CASA operate solely on a column-wise basis - once a column's parameters/forcing have been set then the dynamics do not depend on the grid cell values. This may not be the case with the GW aquifer - is there cross column communication? - or a lateral flow model in the future (where there will need to be).

A key area where this maybe of concern in current CABLE is with conservation of energy during a land-use change event - however, hopefully, the luc.f90 and luc3.f90 code was written using the local soil parameters not the grid value.

A potential problem could be with the outputting of the soil parameters - this may be complicated if different tiles (patches) take differing values and the output%grid = 'mask'.

we are actually proposing to implement this check at the end of reading all the inputs and calculating the derived parameters.

In principal this is fine/correct - however you will have to overwrite all the parameter values in soil% and veg% for the tiles whose soil type you have change - it's not just %iveg and %isoil that change - or, alternately, set the model up to STOP if any inconsistency is found and alert the user to change their inputs.

[JhanSrbinovsky]

This might be redundant now - just catching up after being on leave.....

As far as I know basic CABLE and CASA operate solely on a column-wise basis - once a column's parameters/forcing have been set then the dynamics do not depend on the grid cell values. This may not be the case with the GW aquifer - is there cross column communication? - or a lateral flow model in the future (where there will need to be).

Just before Mark Dekker disappeared we were discussing this. We dont have a spatial orientation of tiles within a cell (i.e. the crops are at the Northern end of cell X) so we were only t talking about aquifers that extend (or potentially have reach) across cells. My understanding was that there was NO inherent mechanism for this. My suggestion was to piggy back on, or mimic what was happening in the river system online.

Remember all soil% values online come from grid cell quantities. Except

1. rhosoil for which there is no corollary in JULES and we assume rhosoil = rhosoil(CLAY) everywhere.
2. ICE - where the spatial PFT map says it is ICE (Greenland, Antarctica) we use soil parameters assuming OUR soil type = ICE values.