Update to the PFT parameters

[JhanSrbinovsky]

I am including this issue in this repo as there will need to be at least some update to the
PFT parameters file here. Also it pertains to CABLE in general, especially AM3

In development of namelist capability (in AM3) to define PFT parametrs at runtime -

• nightmare (1) - MPI broadcasting (again). Once this was sorted which will have to
  be adressed elsewhere
• I ran the model with namelist parameters instead of hard-wired values

Results differed

• I ran the model with the first three namelist parameters instead of hard-wired values
  (canst, length, width)

Results differed

I couldn't work out why, it should have been working. Comparing the namelist parameters
to hard-wired values showed a difference. Conceivably, I got the namelist values from another
source - i.e. not the AM3 code, where I had already converted the namelist to a more readily
modifiable format. Indeed comparrison suggests that this was the case. I am in the process of
verifying the original implementation is working as it should AND all of this is likely resolved.

However, this leaves a potentially bigger problem of which PFT params file should be used.
The AM3 is likely wrong, out of date, not tested anyway. Adopting that used in ESM1.6 seems best
BUT there are differences between that version and offline. I have record of these differences
in full if anyone wants them. Immediately below are differences remaining after I have eliminated
those I know are better in thwe ESM1.6 case. e.g. Aust PFTs

The crfd / froot params there has been work done on these recently but I havent checked yet whether
it was merged into CABLE or directly into ESM1.6.

Significantly different are parameters describing the Medlyn stomatal conductance model, g0 and g1. vcmix and vegcf - BUT this is only for c4 cropland so possibly not a huge impact

@rml599gh @har917 @ccarouge comments?

My default position is to adopt the ESM1.6 version across the board and present the modified namelists for offline and AM3 in separate issues.

COMPARISON: norm_esm16.nml vs norm_offline.nml

FIELDS WITH DIFFERENCES (34):

Field PFT norm_esm16.nml norm_offline.nml

---

g0 1 0.005000 0.000000
g0 2 0.005000 0.000000
g0 3 0.005000 0.000000
g0 4 0.005000 0.000000
g0 5 0.005000 0.000000
g0 6 0.005000 0.000000
g0 7 0.005000 0.000000
g0 8 0.005000 0.000000
g0 9 0.005000 0.000000
g0 10 0.005000 0.000000
g0 11 0.005000 0.000000
g0 12 0.005000 0.000000
g0 13 0.005000 0.000000
g0 14 0.005000 0.000000
g0 15 0.005000 0.000000
g0 16 0.005000 0.000000
g0 17 0.005000 0.000000

g1 1 2.350000 2.346064
g1 2 6.500000 4.114762
g1 3 2.350000 2.346064
g1 4 4.640000 4.447321
g1 5 4.220000 4.694803
g1 6 4.500000 5.248500
g1 7 1.620000 1.616178
g1 8 2.220000 2.222156
g1 9 5.790000 5.789377
g1 10 2.500000 1.616178
g1 11 4.500000 5.248500
g1 12 3.687000 5.248500
g1 13 1.541000 0.000000
g1 14 4.500000 5.248500
g1 16 4.500000 5.248500
g1 17 4.500000 5.248500

vcmax 10 2.000000e-05 8.000000e-05

vegcf 10 7.000000 1.000000

Adopt ESM1.6 values for the parameters below

cfrd(:)
froot*(:)

Fields only in norm_esm16.nml: dleaf It's not immediately clear to me how the offline run is getting this. Nor AM3 - but I am not entirely surprised if this is legitimately an oversight to be fixed

[har917]

@ccarouge @JhanSrbinovsky (My opinion) This is really about i) whether or not to provide default values for parameters in the code base and ii) how the community wants to manage some standard configurations (i.e. sets of namelists)

We shouldn't be applying ESM related changes to parameters to the main codebase until/unless there is community agreement to do so.

---

A couple of other comments that may/may not be relevant and useful:

1. I would not be surprised if the differences in g0 are because of some water conservation requirement in CABLE that forces values to differ from the values in the "Medlyn" reference.
2. The differences in g1 would indicate that there has been some optimisation gone on - certainly there's some interrelation going on with the CABLE-POP_TRENDY branch. It maybe that ESM1.6 has inherited some POP_TRENDY parameters at some point at least for those parts where the science/config was updated.
3. changes to froot likely also need changes to the access13roots code - a candidate for rationalisation as well if we can sort out the configuration management stuff.
4. dleaf is set as the product of leaf width and leaf length in offline/cable_pft_params; similarly in coupled/esm/cable_pft_params_mod for the ESM; and in AM3 it's in coupled/AM3/initialisation/cable_pft_params

[JhanSrbinovsky]

WRT
3. Rachel was working with the access13roots option when these values changed, perhaps she can clarify
4. this sqrt(length * width) was actually from the AM3 code version, I should've said the ESM and offline versions were a mystery to me. I later found the offline definition but I didnt look in the coupled/esm/ directory. I forgot it was even there

I thought we had already landed on declaring values with RMDI or the like where possible and providing configurations. Although, there was a value that came up recently where I commented to Lachlan that things will fall apart without this

[ccarouge]

there was a value that came up recently where I commented to Lachlan that things will fall apart without this

I think it's better for the code to fall apart (or more exactly to have a check for values in the code, which exists, and stop gracefully if check fails) than to impose a magic number value on a parameter that is in an input file. If a parameter is in an input file, then the value in that file should be used and not be internally set. And we should simply learn to use the checks that are already in the code (optional) when setting a new configuration.

[JhanSrbinovsky]

I agree with @ccarouge about this. At one stage, like back in cable1.4b days, there was a push to make CABLE foolproof, out of the box, closing up the remaining holes in CABLE. It's gotten out of control. To the extent that the most efficient way of deciphering which number the model is actually using is to write PRINT statements into the code. I think it would be better to have distinct configurations that operates on one model. In the case of dleaf it doesn't occur that often in the code anyway to simply not use sqrt( etc ). IF it is, or there is another similar parameter perhaps it shouldn't be part of "veg_parameter_type" (or whatever it is called).