range limit LAI and canopy height

[JhanSrbinovsky]

In the UM, LAI and canopy height are read from a prognostic spatial field. In the early days especially it was questionable whether this map was 100% correct. To prevent 0 LAI and/or canopy height and subsequently tripping up other code, vegetated cells were given small but finite minimum LAI/canopy height.

It lives here in AM3: (and also a JAC analog)

src/coupled/AM3/control/cable/shared/LAI_canopy_height_cbl.F90

It is not used in offline, but in main lives here:

src/science/canopy/cbl_LAI_canopy_height.F90

Ideally, subsequent to testing, it might be removed from both.

Probably we should at least remove it to coupled/. Maybe a coupled/shared although this could impact legacy ESM1.5, CM2. In both ESM1.5, CM2 the code is inline, or in cable_um_init_subrs anyway. In JAC we had to pull it out to be able to call it on the first rad call.

This is "a" remaining difference between CABLE/ in the ESM1.6 and CABLE:main.

comments?

[har917]

@JhanSrbinovsky This issue ties in with current thinking around AM3 #239.

I do think that we need a step to ensure physically plausible combinations of LAI and HGT and that likely needs to go into both offline and coupled (probably as part of roughness). I suspect that the current routine is not quite where we will want to land. For example

• the code is currently written in UM-JULES variables not cable TYPEs
• there's hard-wired indices and limits in here.
• we also (likely) need to ensure a minimum amount of leaf area density (so LAI/HGT > threshold)

[JhanSrbinovsky]

• the code is currently written in UM-JULES variables not cable TYPEs
  yep. so maybe we can just UNPACK the UM side and then modify %hc. %lai in CABLE.

• there's hard-wired indices and limits in here.
  this is easy enough, but hopefully we can create a bunch of targeted namelist files and be able to set them thru here

• we also (likely) need to ensure a minimum amount of leaf area density (so LAI/HGT > threshold)
  Sounds like this should be the trigger