Mapping of parameters that are common with CLM/E3SM

[rosiealice]

@ran-feng, @jkshuman and I were just discussing how to make a parameter file for her miocene simulations that has a grass and an evergreen needleleaf tree. One useful thing here, we noted, would be a flag in the parameter file that could say whether a parameter was equivalent to one in the main model vs whether a parameter is unique to FATES. Then, one could know which parameters could be copied from the default file and which need to have new definitions.

Given there are probably quite a few people who will want to do this type of parameter file generation, it seems like this would be a useful addition.

On the other hand, it would put us in a position where we would need to track whether parameters had been deprecated by the host model.

Maybe another solution is just to have a table on the wiki or elsewhere which can give this information broadly to the user community who aren't as familiar with all of the history of these parameter fields.

What does everyone think? (tagging @aswann and @kovenock to see if this would be a thing you guys might enjoy)

[jenniferholm]

Hi @rosiealice - I agree that there should be some type of labeling as to which parameters are unique to FATES and which ones are host land model. I have needed to know these distinctions between the parameters from time to time (almost to the point where I am starting to learn most of them by heart.....crazy ;) )

It seems like the easiest is to just make a descriptive table in the wiki, and have users refer to this table. As we have seen the parameter file can change a lot, and updating this "offline" wiki table would probably be the most straightforward and lessen the chances for parameter file mistakes and errors. My two cents.

[bpbond]

Could FATES parameters be identifiable by name structure? E.g. all have the form f_xxx or fates.xxx?

[rgknox]

Along the lines of what @bpbond is suggesting, I think we could do a combination of what has been suggested. We do currently prefix all fates parameters with a "fates_" namespace. So we could use the same parameter names after the fates_ prefix. We could also add an attribute to the parameters, like: "host_equivalent", which says "none" or gives the parameter name if its not unique to fates.

[ckoven]

Here's a first pass. I ncdumped fates and CLM parameter files, grepped for "double" to pull out the variable names, deleted the FATES_ prefix from the fates ones (@bpbond we do do what you are suggesting already, but some of them have a meaning in both models) and deleted the dimension info, then sorted and diffed them in emacs.

Here are the shared params:

c3psn
cwd_fcel
cwd_flig
displar
dleaf
evergreen
fr_fcel
fr_flab
fr_flig
froot_leaf
frootcn
grperc
leaf_long
leafcn
lf_fcel
lf_flab
lf_flig
rholnir
rholvis
rhosnir
rhosvis
roota_par
rootb_par
rootprof_beta
season_decid
slatop
smpsc
smpso
stress_decid
taulnir
taulvis
tausnir
tausvis
woody
z0mr

Here are the FATES params that don't have a match in the CLM file:

BB_slope
CWD_frac
FBD
SAV
allom_agb1
allom_agb2
allom_agb3
allom_agb4
allom_agb_frac
allom_amode
allom_blca_expnt_diff
allom_cmode
allom_d2bl1
allom_d2bl2
allom_d2bl3
allom_d2ca_coefficient_max
allom_d2ca_coefficient_min
allom_d2h1
allom_d2h2
allom_d2h3
allom_dbh_maxheight
allom_fmode
allom_hmode
allom_l2fr
allom_latosa_int
allom_latosa_slp
allom_lmode
allom_sai_scaler
allom_smode
alpha_FMC
alpha_SH
bark_scaler
base_mr_20
bbopt_c3
bbopt_c4
bmort
branch_turnover
canopy_closure_thresh
clone_alloc
cohort_fusion_tol
comp_excln
crown_depth_frac
crown_kill
cushion
dbh_repro_threshold
durat_slope
fdi_a
fdi_alpha
fdi_b
fire_wind_max
freezetol
fuel_energy
germination_timescale
hydr_rs2
hydr_srl
hydr_thetas_node
init_litter
initd
jmaxha
jmaxhd
jmaxse
leaf_stor_priority
logging_coll_under_frac
logging_collateral_frac
logging_dbhmin
logging_direct_frac
logging_event_code
logging_mechanical_frac
low_moisture_Coeff
low_moisture_Slope
max_decomp
max_durat
mid_moisture
mid_moisture_Coeff
mid_moisture_Slope
min_moisture
miner_damp
miner_total
mort_disturb_frac
nignitions
part_dens
patch_fusion_tol
pft_used
phen_a
phen_b
phen_c
phen_chiltemp
phen_coldtemp
phen_doff_time
phen_drought_threshold
phen_mindayson
phen_ncolddayslim
prescribed_mortality_canopy
prescribed_mortality_understory
prescribed_npp_canopy
prescribed_npp_understory
prescribed_recruitment
root_long
seed_alloc
seed_decay_turnover
seed_rain
size_diagnostic_scale
stress_mort
tpuha
tpuhd
tpuse
trim_inc
trim_limit
understorey_death
vcmax25top
vcmaxha
vcmaxhd
vcmaxse
wood_density

A couple of them differ only in name (e.g. BB slope), and some are in the CLM file but hard-coded (e.g. vcmaxse, etc...)

[jenniferholm]

That is the default right now, all parameters are denoted by "fates_xxx". It would mean going in and changing some to say, "hlm_fates_xxx" and those unique to FATES as just "fates_xxx". I guess it would not be that difficult.
Then when new parameters come online, just keep this name structure. But are there some that are overlap between both HLM and FATES? Maybe fates_vcmax25top? I can't remember...

[rosiealice]

I quite like Ryan's 'host equivalent' metadata suggestion. We are already using the naming convention to convey lots of different groupings. I think adding others would be confusing.

…

On Dec 22, 2017 1:18 PM, "Jennifer Holm" ***@***.***> wrote: That is the default right now, all parameters are denoted by "fates_xxx". It would mean going in and changing some to say, "hlm_fates_xxx" and those unique to FATES as just "fates_xxx". I guess it would not be that difficult. Then when new parameters come online, just keep this name structure. But are there some that are overlap between both HLM and FATES? Maybe fates_vcmax25top? I can't remember... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#311 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ3wDpty7yL3lRTOfVC3pYUvqZcxDks5tDA6qgaJpZM4RI_4V> .

[glemieux]

Closing per NGEET/fates-users-guide#11