new parameter file release

[rgknox]

To help people (and me) plan, we will be issuing a new default parameter file in the near future. Here is a list of potential changes. Please comment below, and we can iterate, changing this from potential to actual.

• Now that we have freeze mortality, change freeze tolerance threshold from a dummy val to some nominal value for all PFTs (currently its 1000C, which kills all plants)

• Expand PFTs to include work-in-progress extra-tropical PFTs (@jenniferholm #281 )

• Issue #303, change fates_comp_excln = 3

• Set branch_turnover to non-zero values - setting it to 50 years as default

• Add a field to option storage allometry mode "fates_allom_stmode"

• logging_dbhmax_infra (35cm)

• clumping_index = 0.85

• Change "fates_clone_alloc" param name to be "fates_seed_alloc_mature" (#278)

• Check with @lmkueppers and @adamhb to see what new parameters could be needed for recruitment

• Insect parameters? @xuchongang, do you guys have know the set of parameters you want for the insect/pest module?

Tagging @serbinsh and @mdietze, so you know what is coming down the pipe

[huangmy]

@rgknox: shall we worry about bringing "logging_dbhmax_infra" for this change?

[xuchongang]

Ryan,

I will check with Devin to propose a list of insect related parameters. Right now, they are in the FatesInsectMod.

Yours Chonggang

On Mon, Feb 26, 2018 at 12:11 PM, Ryan Knox notifications@github.com wrote:

To help people (and me) plan, we will be issuing a new default parameter file in the near future. Here is a list of potential changes. Please comment below, and we can iterate, changing this from potential to actual.

-

Now that we have freeze mortality, change freeze tolerance threshold from a dummy val to some nominal value for all PFTs (currently its 1000C, which kills all plants)

Expand PFTs to include work-in-progress extra-tropical PFTs ( @jenniferholm https://github.com/jenniferholm #281 https://github.com/NGEET/fates/issues/281 )

Issue #303 https://github.com/NGEET/fates/issues/303, change fates_comp_excln

Set branch_turnover to non-zero values

Add a field to option storage allometry mode "fates_allom_stmode"

Change "clone_alloc" param name to be ... better (#278 https://github.com/NGEET/fates/issues/278), check with @lmkueppers https://github.com/lmkueppers and @adamhb https://github.com/adamhb to see what new parameters could be needed for recruitment

Bark parameters? @jkshuman https://github.com/jkshuman , we could potentially put placeholders in if you have a reasonable sense of the types of parameters you would want

Insect parameters? @xuchongang https://github.com/xuchongang, do you guys have know the set of parameters you want for the insect/pest module?

Tagging @serbinsh https://github.com/serbinsh and @mdietze https://github.com/mdietze, so you know what is coming down the pipe

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/337, or mute the thread https://github.com/notifications/unsubscribe-auth/AH2Yx2QUph-ZdwXIhn3n7OV-MRQGJMS9ks5tYwHggaJpZM4STw_S .

[ckoven]

I will add parameters for the respiration throttling code, as discussed in #308, which I will be submitting a PR on soon. To do this, I will add either 2 new parameters. The first will be a parameter that determines the curvature of the curve linking respiration and carbon storage deficit. The second parameter will be a maximum respiration throttling term, between 0 and 1, so that when 0 the behavior is the same as on current master and when 1 it will behave as in the figures shown in #308.

[rgknox]

@huangmy , I think so, I can at least add its entry to the file, then we can add the code to use it. I will add a bullet. Do you have a recommendation for the default value?

[huangmy]

@rgknox: great. Once it is there I can modify the code to use it. please use 35 (cm) as the default.

[ckoven]

@rgknox for your pft parameter file, as per discussion in #339, I'd like to try adding a simple clumping parameterization, so lets put a PFT-level leaf clumping index on the new variables list.

[serbinsh]

@ckoven, is your request similar to this thread I started awhile back? https://github.com/NGEET/fates/issues/153

You mention leaf clumping but not sure if that means canopy level clumping factor by pft (akin to the omega parameter in the standard LAI equation) or more shoot-level clumping?

[ckoven]

@serbinsh that is what i was advocating -- I'm sure that at some point I saw your earlier thread but had forgotten about it! The question of clumping scale is a good one -- PPA generates its own degree of clumping at the canopy scale so I was thinking we ought to include a clumping at the leaf to branch scale, but was thinking that it would work exactly as you describe in https://github.com/NGEET/fates/issues/153#issuecomment-264542552

[rgknox]

@ckoven , can you provide names and defaults for the respiration throttling and clumping? Also, can throttling be turned off by a particular parameter value, or will we need a switch in the parameter file?

[ckoven]

@rgknox can we add a pft_name variable too? even if its never read in by fates it should make keeping track of things easier...

[ckoven]

@rgknox the parameter names, metadata, and values for the respiration code I've got (sorry I've been tending towards long name recently) are:

float fates_maintresp_reduction_curvature(fates_pft) ;
    fates_maintresp_reduction_curvature:units = "unitless (0-1)" ;
    fates_maintresp_reduction_curvature:long_name = "curvature of MR reduction as f(carbon storage), 1=linear, 0=very curved" ;
float fates_maintresp_reduction_intercept(fates_pft) ;
    fates_maintresp_reduction_intercept:units = "unitless (0-1)" ;
    fates_maintresp_reduction_intercept:long_name = "intercept of MR reduction as f(carbon storage), 0=no throttling, 1=max throttling" ;

fates_maintresp_reduction_curvature = 0.01 ; fates_maintresp_reduction_intercept = 1 ;

The parameter fates_maintresp_reduction_intercept serves as an on/off switch as well, so should give bit-for-bit results to current master if set to zero.

I'll defer to @serbinsh on what the default values for a clumping index ought to be. Its tricky for the reason he brings up about what scale we are intending that to serve (branch but not tree), but lets move discussion on that topic to #153.

[rgknox]

@ckoven , for the new file, should fates_comp_excln = 3? Or new recommendation?

[ckoven]

@rgknox I think thats a good place to start.

[ckoven]

at some point soon we need to recast fates_comp_excln as a function of height rather than DBH too (#302), which will change the quantitative effect of that parameter; maybe we ought to do that in the currentn set of changes too...

[rgknox]

changing name of "fates_clone_alloc" to "fates_seed_alloc_mature"

[rgknox]

@huangmy should logging_dbhmax_infra be a PFT dimensioned parameter?

Proposed long-name: "Tree diameter, above which infrastructure from logging does not impact damage or mortality."

[rgknox]

@jkshuman and I chatted and decided that we will hold on introducing new bark parameters in this round, it is possible that no new parameters will be needed for her foreseeable developments on bark anway.

[huangmy]

@rgknox I don't think it should be PFT dimensioned because this is the threshold above which the loggers would not like to waste their time/energy on clearing the path or building the decks for accessibility or storage. They probably will not be very selective in terms of species. Should be at a patch level. @mpaiao: what do you think?

The proposed long name looks good to me.

[mpaiao]

@huangmy I agree with you, the damage avoidance depends more on size and site than on PFT.

[rgknox]

excellent, thank you both!

[serbinsh]

In relation to the other CIs listed in the CDL file of #347, should we go ahead and give reasonable values for other biomes as well?

What I see is:

 fates_pftname =
  "broadleaf_evergreen_tropical_tree       ",
  "needleleaf_evergreen_temperate_tree     ",
  "needleleaf_evergreen_boreal_tree        ",
  "needleleaf_deciduous_boreal_tree        ",
  "broadleaf_evergreen_temperate_tree      ",
  "broadleaf_deciduous_tropical_tree       ",
  "broadleaf_deciduous_temperate_tree      ",
  "broadleaf_deciduous_boreal_tree         ",
  "broadleaf_evergreen_temperate_shrub     ",
  "broadleaf_deciduous_temperate_shrub     ",
  "broadleaf_deciduous_boreal_shrub        ",
  "arctic_c3_grass                         ",
  "cool_c3_grass                           " ;

and

 fates_clumping_index = 0.85, 0.85, 0.85, 0.85, 0.85, 0.85, 0.85, 0.85, 0.85, 
    0.85, 0.85, 0.85, 0.85 ;

I think we could change:

"needleleaf_evergreen_boreal_tree ", change OmegaE to something more like ~0.65-0.7 (Chen et al. 1996; 2006; others) e.g. white/black spruce, jack pine, fir, etc

"needleleaf_deciduous_boreal_tree ", to 0.80 e.g. tamarack

"broadleaf_deciduous_boreal_tree ", to ~0.75 (seasonally varies between ~0.7-0.8, Chen et al. 1997; Kucharik et al 1997 etc) e.g. Aspen, birch, balsam poplar?

"broadleaf_deciduous_temperate_tree ", to ~0.90 (Gower et al. 1999) e.g. maple, oak, etc

"broadleaf_deciduous_boreal_shrub ", to ~0.90 (Sonnentag et al, Mer Bleue Bog)

"broadleaf_deciduous_temperate_shrub ", to ~0.90 (for now make it similar to boreal shrubs until we can find a better value, if one exists)

"arctic_c3_grass ", "cool_c3_grass " ; for now could set to 0.75 based on Ryu et al 2010....however I suspect we can either measure or find data for arctic grasses....does this incorporate all sedges and grasses? what about forbs? To come?

For all of these I looked at values of OmegaE (elemental clumping) so these should be relevant here.

Thoughts? its a little tricky as many of these values come from stands that arent always "pure" and so the variance in the CIs can be high. However, I think in general we want less clumping (i.e. closer to 1) with more decid. broadleaf and more clumping in needle-leaf / evergreen PFTs, especially higher latitudes/altitudes.

[ckoven]

@serbinsh that sounds great, though I'm not familiar enough with the measurement technique to know how the clumping index relates to scale of clumping. I.e. how much of the low value for the boreal clumping arises from having an open canopy? In principle the PPA ought to handle that in open-canopy ecosystems by separating the radiative transfer through the fraction of the canopy that is going through the crowns of each PFT (or not a PFT).

[serbinsh]

@ckoven good point. It is a bit tricky because we have something like three levels of clumping to think about, within-shoot (GammaE), within-crown (branches, whirls, etc, OmegaE) and canopy-scale clumping (between crown gaps)...or could consider this as just two within-shoot and beyond shoot clumping.

For boreal needle-leaf I think either way a decent starting estimate is 0.7 or 0.75 given that most of the work looking at boreal systems have a range between ~0.6 - 0.8 based on the age, drainage, stand history, etc. It is tricky as the combined crown-scale clumping is both within-shoot and crown. That said, spruce trees do have some very very tight needle whirls and clumped crowns (that are also very elliptical) which allows a lot of light through to the understory.

[jenniferholm]

I might have posted these values somewhere else, but also posting here to make sure the current fates_freezetol values get into the parameter file. These values came from the values used in ED2 and some expert knowledge that Mike Dietze provided (of course, these are certainly open to tweaking based on new literature and data).

fates_freezetol = 2.5, -55, -80, -80, -30, 2.5, -30, -80, -60, -10, -80, -80, -80 ; fates_freezetol:units = "Celsius" ;

Following the PFT order of = fates_pftname = "broadleaf_evergreen_tropical_tree ", "needleleaf_evergreen_temperate_tree ", "needleleaf_evergreen_boreal_tree ", "needleleaf_deciduous_boreal_tree ", "broadleaf_evergreen_temperate_tree ", "broadleaf_deciduous_tropical_tree ", "broadleaf_deciduous_temperate_tree ", "broadleaf_deciduous_boreal_tree ", "broadleaf_evergreen_temperate_shrub ", "broadleaf_deciduous_temperate_shrub ", "broadleaf_deciduous_boreal_shrub ", "arctic_c3_grass ", "cool_c3_grass " ;

[rgknox]

Thanks @jenniferholm , I checked the numbers you posted, and they are in the file. For reference:

Here is the CDL file for reference: https://github.com/rgknox/fates/blob/b5862caf716e0702fd7c073bb4df41e5ce09f167/parameter_files/fates_params_default.cdl

[rgknox]

@serbinsh, lets try to get the better clumping index values you are proposing into the file. Based on your suggestions, here is what I have so far.

broadleaf_evergreen_tropical_tree            0.85
  "needleleaf_evergreen_temperate_tree      
  "needleleaf_evergreen_boreal_tree         0.675
  "needleleaf_deciduous_boreal_tree         0.8
  "broadleaf_evergreen_temperate_tree       
  "broadleaf_deciduous_tropical_tree        
  "broadleaf_deciduous_temperate_tree       0.90
  "broadleaf_deciduous_boreal_tree          0.75
  "broadleaf_evergreen_temperate_shrub
  "broadleaf_deciduous_temperate_shrub      0.90
  "broadleaf_deciduous_boreal_shrub         0.90 
  "arctic_c3_grass                          0.75
  "cool_c3_grass                            0.75

[serbinsh]

@rgknox looks good, the rest can be 0.85 until we can find better numbers or we let the data update these params

[rgknox]

Adding that in @serbinsh .

I've been encountering problems when I specify grasses as having no structural or sap biomass. The problem as I see it, is that these plants then have no SAI, and then it is possible that due to turnover or phenology, they could then have no LAI. With zero TAI, I'm noticing that problems are arising in the canopy profile and radiation parts of the code.

I haven't figured out exactly what the problem and solution is, but I may punt on this and designate the grasses as having a small amount of structure....

[ckoven]

@rgknox more changes to accompany #349:

I put the sai_scaler in the same units as slatop, so to get SAI to be equal to 10% LAI, just set sai_scaler to be 10% of slatop.

double fates_allom_sai_scaler(fates_pft) ;
    fates_allom_sai_scaler:long_name = "allometric ratio of SAI to target bleaf" ;
    fates_allom_sai_scaler:units = "m2/g" ;

fates_allom_sai_scaler = 0.0012, 0.0012 ;

[rgknox]

great, I will get this in

[rgknox]

@ckoven , that is m2/gC right?

[ckoven]

right

[ckoven]

per #355, a last thing to add to this file: a new dimension and variable:

suggested data/metadata for the file:

new dimension:

    fates_history_height_bins = 6 ;

new variable:

    double fates_history_height_bin_edges(fates_history_height_bins) ;
        fates_history_height_bin_edges:long_name = "Lower edges for height bins used in height-resolved history output" ;
        fates_history_height_bin_edges:units = "m" ;

new data for that variable:

 fates_history_height_bin_edges = 0, 0.1, 0.3, 1, 3, 10 ;

thanks!

[serbinsh]

@rgknox I noticed in the above CDL file that the jmax, vcmax, and TPU params aren't clustered together. I know this doesnt matter but for later reading of the params, it might be easier if they were grouped in the same place in the file as they are in the present param file. Same with some of the other similar params, like stem/leaf optical properties, etc.

Also, would you like me/us to provide data-driven defaults for tree/grass leaf reflectance/transmittance in the vis and NIR? We have a lot of spectra across those PFTs and could use that data to derive a mean value for most if not all PFTs.

Or we could work on making that update later after this first expanded release.

[rosiealice]

@serbinsh it would be -great- if you had data on the reflectance and transmittance parameters. Suffice to say, it has been a long time since those have been subject to any scrutiny... I wonder if that would let more light through, also.

[rgknox]

I agree, @serbinsh , we would gladly update with data drive defaults for light transmission parameters.

@serbinsh , regarding comment 1, sounds good. Can you either provide a list of the parameter names you would like clustered? Or feel free to submit a PR to my branch with the changes.

[ckoven]

looking through the parameter file: can we get rid of fates_size_diagnostic_scale? it has never been used and has been made redundant by passing the size bins as their own argument.

[ckoven]

also if we are reordering things, can we reorder around dimensions too? i.e. put all the scalars together, all the CWD and fuel dimensioned parameters together, and all teh PFT parameters together?

[ckoven]

actually, sorry to be OCD about this, but maybe can I take a first shot at clustering the parameters, and @serbinsh, once I issue a PR to @rgknox's branch you take a look and see if that helps you see things clustered in a useful way?

[rgknox]

THis works for me. I think we should get this squared away and looking as good as possible, now, while everyone is aware of the change.

[ckoven]

Looking at this I'd propose we move to a system of sorting the variables first by dimensionality, and then alphabetized within each dimension type. That way they will cluster together based on prefixes naturally, and we'll also be able to find them rationally. Is anyone opposed to that?

[jkshuman]

I am having a hard time visualizing the change, but I may need to go through and add "fire" before some relevant variables so they stay connected...

[ckoven]

there's actually very few fire variables that have a PFT dimension. mostly they have either a CWD dimension, a fuel dimension, or an actual scalar dimension (as opposed to the 1-length "fates_scalar" dimension that all the other scalars have. So they also cluster together naturally, with only a couple exceptions.

[jkshuman]

@ckoven OK, sound good. no need to update then.

[ckoven]

ok that was surprisingly easy. i made a sorted list of variable names by dimension in excel, and then wrote a little python program to sort the netcdf variables based on that list. I'll add the program to the tools section. @jkshuman, @serbinsh or anyone else, if you want to group things further yourself via variable name prefixes, feel free once I issue a PR to @rgknox's branch and he accepts it; we can go back and re-sort if needed.

[ckoven]

all: so I decided to really look through the parameter file and try to clean it up. I noticed that there was a variable, fates_froot_leaf, that was redundant (to fates_allom_l2fr) and not even being read, so I deleted it. I also deleted fates_size_diagnostic_scale which is obsolete.

I wrote a python script to sort the variables by dimension type and then name, so that we can keep things reproducibly sorted going forward, here: https://github.com/ckoven/fates/commit/96e580d

also--and this is where I may have gotten a little carried away--I added prefixes to a bunch of variables so that they would group next to each other. I added 'leaf', 'mort', 'fire', 'seed', and 'phen' as the prefixes. @jkshuman, I didn't add 'fire' to the main block of fire variables, because they already cluster next to each other, only the pft-indexed ones, but you can feel free if you like. if people feel this change is a bit overenthusiastic, I am ok with undoing it, but I find it helps organize things more nicely.

prefix-adding (and extraneous variable deleting) commit is here: https://github.com/ckoven/fates/commit/0ce37e6

[rgknox]

fates_seed_hgt_min and fates_seed_initd. When I see seed, I think of the minmum height at which plants would start bearing seeds... Could we change this to fates_recruit_hgt_min? and fates_recruit_initd?

[rgknox]

also: fates_leafcn was not given a prefix, but fates_root_frootcn was given a prefix. how about:

fates_leaf_c2n_ratio fates_froot_c2n_ratio

Note, in the future when we have variable nutirent dynamics options, we may want to prefix the parameters associated with the different options. These might benefit from a "fixed_stoich" prefix?

[ckoven]

@rgknox all of those sounds like good ideas.

[rgknox]

I will pull @ckoven changes into my branch. Others, to work off that branch:

git remote add rgknox_repo git@github.com:rgknox/fates.git
git fetch rgknox_repo
git checkout -b rgknox-parameter-updates rgknox_repo/rgknox-parameter-updates

Make your changes, commit changes, then:

git push <your_fork> rgknox-parameter-updates

Then use github to make a pull request from your fork to my fork.