Closed rgknox closed 2 years ago
Something like this seems sensible and useful.
in a single "diff style" file
Why not allow for arbitrary number of diff files? They could be processed alphabetically, or in some sensible order, and changes are cumulative...so all files are processed and then the final product is written. This seems like a marginal amount of extra work with potentially lots more flexibility for users.
For example, maybe my work is one diff from the default; Kate wants to add extra changes on top of that for her work, and wants to track my changes, but doesn't want to manually update her files whenever mine change.
@bpbond I think that could be done. Perhaps the argument into the python script would be a delimited list of (file-name x use-case-section) couplets, that are processed in order. A check can be applied to make sure that the co-processed use-case-sections all have the same PFTs defined.
I agree that that diff approach would be useful, so people don't need to track changes themselves in parameters they aren't thinking about. We should make sure the changes between default PFTs are clearly described incase of cases like the one Jackie just had of trying to chase back through parameter changes.
Le mer. 28 nov. 2018 à 22:02, Ryan Knox notifications@github.com a écrit :
@bpbond https://github.com/bpbond I think that could be done. Perhaps the argument into the python script would be a delimited list of (file-name x use-case-section) couplets, that are processed in order. A check can be applied to make sure that the co-processed use-case-sections all have the same PFTs defined.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/444#issuecomment-442603437, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ9V-Yb9qMn1So7ysd_0ekKAM_Xpoks5uzvn3gaJpZM4Y4YIu .
Dr Rosie A. Fisher
Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305, USA
and
Visitor @ C.E.R.F.A.C.S Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique 42 Avenue Gaspard Coriolis 31057, Toulouse, France http://www.cgd.ucar.edu/staff/rfisher/
Is there also the possibility of making new Param files back compatible with old ones. i.e. when new parameters are added to the file, can old Param files still work? That would really help folks who've developed their own Param files.
You could fuse the read in parameter file with the default or something like that such that the read in file overwrites values in the default but the deafult has every parameter necessary.
Perhaps this is a different issue but just a thought.
On Mon, 3 Dec 2018, 18:28 Rosie Fisher, notifications@github.com wrote:
I agree that that diff approach would be useful, so people don't need to track changes themselves in parameters they aren't thinking about. We should make sure the changes between default PFTs are clearly described incase of cases like the one Jackie just had of trying to chase back through parameter changes.
Le mer. 28 nov. 2018 à 22:02, Ryan Knox notifications@github.com a écrit :
@bpbond https://github.com/bpbond I think that could be done. Perhaps the argument into the python script would be a delimited list of (file-name x use-case-section) couplets, that are processed in order. A check can be applied to make sure that the co-processed use-case-sections all have the same PFTs defined.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/444#issuecomment-442603437, or mute the thread < https://github.com/notifications/unsubscribe-auth/AMWsQ9V-Yb9qMn1So7ysd_0ekKAM_Xpoks5uzvn3gaJpZM4Y4YIu
.
--
Dr Rosie A. Fisher
Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305, USA
and
Visitor @ C.E.R.F.A.C.S Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique 42 Avenue Gaspard Coriolis 31057, Toulouse, France http://www.cgd.ucar.edu/staff/rfisher/
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/444#issuecomment-443910276, or mute the thread https://github.com/notifications/unsubscribe-auth/AErK5cqHHZAlSx_9OAoli18HA34h1RPjks5u1bODgaJpZM4Y4YIu .
Was discussing this yesterday with @rgknox and @glemieux, and as a short-term step, I'd like to propose a system whereby we delete all but a single parameter file in our source code, and then use our current set of tools, in conjunction with a few case-specific scripts, to handle these diff patches. E.g. A given localization script might look something like this:
#!/usr/bin/env bash
$FATES_SRC_HOME=$1
ncgen -o param_file_base.nc $FATES_SRC_HOME/parameter_files/fates_params_14pfts.cdl
$FATES_SRC_HOME/tools/FatesPFTIndexSwapper.py --fin param_file_base.nc --fout param_file_mod.nc --pft-indices 2,7,13
$FATES_SRC_HOME/tools/modify_fates_paramfile.py --fin param_file_mod.nc --fout param_file_mod.nc --O --var fates_mort_scalar_hydrfailure --val 0 --allpfts
$FATES_SRC_HOMEtools/modify_fates_paramfile.py --fin param_file_mod.nc --fout param_file_mod.nc --O --var fates_recruit_initd --val 0.2 --allpfts
$FATES_SRC_HOME/tools/modify_fates_paramfile.py --fin param_file_mod.nc --fout param_file_mod.nc --O --var fates_alloc_storage_cushion --val 1.8 --PFT 1
We could add a directory with some of the more general versions of these scripts within our parameter file directory. Also we could build off this towards something more sophisticated to, e.g., keep track of provenance, but it'd be good to get rid of the current system of tracking multiple PFT files pretty soon to avoid issues like #505.
Just noting that if indeed the issue I was running into (wherein the script won't accept a comma-delimited input) is indeed a python-version-issue, then it might be problematic to have running python scripts into the FATES general workflow without consistancy between people's python installations.
With the general caveat that I don't know what I'm doing with python...
All- OK, apologies in advance that this is long and tedious, but I'd really like to clean up our "default" parameter file cabinet. To that end, I'd like to propose that a first step in this effort is to identify the differences in our various files, and then based on those differences possibly translate them into a set of diff files, and then delete all but the one default file.
So, what I've done is to use the variable sorting script on each of our various default files, and then done some pairwise diffs of those against each other. The results of that exercise are below. One question is: do we want to make diff files for each of these, or can some of these be consolidated into the master PFT file? I.e. can we extract the relevant features of the hydro PFT file and the default tropical PFT file, and just put those into the tropical PFT of the master 14-PFT file? What about the coastal grass file -- is that something we want to introduce into the master file or is it better to treat as a special case, handled by a diff file?
So I did a diff on the 2 PFT tropical default file against the 14 PFT file, and then I went through and deleted all the lines in the diff where the tropical file had the same value as the first index (broadleaf tropical evergreen tree) in the 14 PFT file. The remaining differences are here:
< netcdf fates_params_default.cdl.nc.sorted {
---
> netcdf fates_params_14pfts.cdl.nc.sorted {
627c625
< fates_hydr_kmax_rsurf = 20 ;
---
> fates_hydr_kmax_rsurf = 0.001 ;
802,805c852,859
< fates_hydr_pinot_node =
< -1.465984, -1.465984,
< -1.22807, -1.22807,
< -1.22807, -1.22807,
< -1.043478, -1.043478 ;
---
> fates_hydr_pinot_node =
> -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999,
> -999, -999,
> -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999,
> -999, -999,
> -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999,
> -999, -999,
> -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999, -999,
> -999, -999 ;
905c998,999
< fates_phenflush_fraction = 0.5, 0.5 ;
---
> fates_phenflush_fraction = _, _, _, 0.5, _, 0.5, 0.5, 0.5, _, 0.5, 0.5, 0.5,
> 0.5, 0.5 ;
1010,1015c1136,1142
< fates_turnover_carb_retrans
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0 ;
---
> fates_turnover_carb_retrans
> 0.025, 0.025, 0.025, 0.05, 0.025, 0.05, 0.05, 0.05, 0.025, 0.05, 0.05,
> 0.05, 0.05, 0.05,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ;
Looking at the above, I don't see a reason why we can't just choose one set of these for each variable and, where applicable, put it into the 14 PFT file, and then delete the 2-PFT file.
Next, I diff the "hydro default" against the "2 PFT tropical" default. On ething to note here is that the "hydro default" is already out of date relative to changes to the fire parameters:
1c1
< netcdf fates_params_default.cdl.nc.sorted {
---
> netcdf fates_params_hydro_default.cdl.nc.sorted {
478,480d477
< float fates_senleaf_long_fdrought(fates_pft) ;
< fates_senleaf_long_fdrought:units = "unitless[0-1]" ;
< fates_senleaf_long_fdrought:long_name = "multiplication factor for leaf longevity of senescent leaves during drought" ;
525a523,525
> float fates_alpha_FMC(fates_litterclass) ;
> fates_alpha_FMC:units = "NA" ;
> fates_alpha_FMC:long_name = "spitfire parameter related to fuel moisture content, Equation 6 Thonicke et al 2010" ;
556,558d555
< float fates_drying_ratio ;
< fates_drying_ratio:units = "NA" ;
< fates_drying_ratio:long_name = "spitfire parameter, fire drying ratio for fuel moisture, alpha_FMC EQ 6 Thonicke et al 2010" ;
570a568,570
> float fates_fire_wind_max ;
> fates_fire_wind_max:units = "m/min" ;
> fates_fire_wind_max:long_name = "maximum wind speed expected by the fire model" ;
617c617
< fates_cohort_fusion_tol = 0.08 ;
---
> fates_cohort_fusion_tol = 0.05 ;
731c731
< fates_allom_la_per_sa_int = 1000, 1000 ;
---
> fates_allom_la_per_sa_int = 0.8, 0.8 ;
899c899
< fates_phen_evergreen = 1, 1 ;
---
> fates_phen_evergreen = 1, 0 ;
903c903
< fates_phen_stress_decid = 0, 0 ;
---
> fates_phen_stress_decid = 0, 1 ;
928,929c928,929
< fates_prt_nitr_stoich_p1 =
< 0.033, 0.033,
< 0.024, 0.024,
< 0.0047, 0.0047,
< 0.0047, 0.0047,
< 0, 0,
< 0.0047, 0.0047 ;
---
> fates_prt_nitr_stoich_p1 =
> 0.033, 0.033,
> 0.024, 0.024,
> 4.7e-06, 4.7e-06,
> 4.7e-06, 4.7e-06,
> 0, 0,
> 4.7e-06, 4.7e-06 ;
991,992d990
< fates_senleaf_long_fdrought = 1, 1 ;
<
1040a1039,1040
> fates_alpha_FMC = 0.0050769, 0.001, 0.0002754, 7.54e-05, 1.54e-05, 999 ;
>
1061,1062d1060
< fates_drying_ratio = 13000 ;
<
1070a1069,1070
> fates_fire_wind_max = 45.718 ;
>
Here, it seems slighty trickier than the 2PFT tropical forest case, because the sapwood allometry and sapwood C:N ratios are different, in addition to the purely hydraulic issues. The issue that I believe that is meant to solve is #392. But I'd personally feel comfortable putting the hydraulic allometries into the default file and solving the too-high respiration problem with low sapwood N, as is being done in the hydraulic file. So again, I'd propose just incorporating these values into the default and getting rid of the "hydro default" file.
The last comparison is between the coastal grasses parameter file and the tropical forest 2-PFT file. Again, the coastal grass one is pretty out of date already, but the differences are also a lot more extensive:
1c1
< netcdf fates_params_default.cdl.nc.sorted {
---
> netcdf fates_params_coastal_veg.cdl.nc.sorted {
8,9d7
< fates_prt_organs = 6 ;
< fates_leafage_class = 2 ;
127,129d124
< char fates_prt_organ_name(fates_prt_organs, fates_string_length) ;
< fates_prt_organ_name:units = "unitless - string" ;
< fates_prt_organ_name:long_name = "Plant organ name (order must match PRTGenericMod.F90)" ;
159c154
< fates_allom_d2bl1:long_name = "Parameter 1 for d2bl allometry" ;
---
> fates_allom_d2bl1:long_name = "Parameter 1 for d2bl allometry (intercept)" ;
162c157
< fates_allom_d2bl2:long_name = "Parameter 2 for d2bl allometry" ;
---
> fates_allom_d2bl2:long_name = "Parameter 2 for d2bl allometry (slope)" ;
165c160
< fates_allom_d2bl3:long_name = "Parameter 3 for d2bl allometry" ;
---
> fates_allom_d2bl3:long_name = "Parameter 3 for d2bl allometry (optional)" ;
196,201c191,196
< float fates_allom_la_per_sa_int(fates_pft) ;
< fates_allom_la_per_sa_int:units = "m2/cm2" ;
< fates_allom_la_per_sa_int:long_name = "Leaf area per sapwood area, intercept" ;
< float fates_allom_la_per_sa_slp(fates_pft) ;
< fates_allom_la_per_sa_slp:units = "m2/cm2/m" ;
< fates_allom_la_per_sa_slp:long_name = "Leaf area per sapwood area rate of change with height, slope (optional)" ;
---
> float fates_allom_latosa_int(fates_pft) ;
> fates_allom_latosa_int:units = "ratio" ;
> fates_allom_latosa_int:long_name = "Leaf area to sap area ratio, intercept [m2/cm2]" ;
> float fates_allom_latosa_slp(fates_pft) ;
> fates_allom_latosa_slp:units = "unitless" ;
> fates_allom_latosa_slp:long_name = "Leaf area to sap area ratio, slope (optional)" ;
206,207c201,202
< fates_allom_sai_scaler:units = "m2/m2" ;
< fates_allom_sai_scaler:long_name = "allometric ratio of SAI per LAI" ;
---
> fates_allom_sai_scaler:units = "m2/gC" ;
> fates_allom_sai_scaler:long_name = "allometric ratio of SAI to target bleaf" ;
243a239,241
> float fates_froot_cn_ratio(fates_pft) ;
> fates_froot_cn_ratio:units = "gC/gN" ;
> fates_froot_cn_ratio:long_name = "Fine root C:N" ;
284c282
< fates_hydr_rs2:units = "m" ;
---
> fates_hydr_rs2:units = "mm" ;
300a299,301
> float fates_leaf_cn_ratio(fates_pft) ;
> fates_leaf_cn_ratio:units = "gC/gN" ;
> fates_leaf_cn_ratio:long_name = "Leaf C:N" ;
313c314
< float fates_leaf_long(fates_leafage_class, fates_pft) ;
---
> float fates_leaf_long(fates_pft) ;
316,318d316
< float fates_leaf_slamax(fates_pft) ;
< fates_leaf_slamax:units = "m^2/gC" ;
< fates_leaf_slamax:long_name = "Maximum Specific Leaf Area (SLA), even if under a dense canopy" ;
334c332
< float fates_leaf_vcmax25top(fates_leafage_class, fates_pft) ;
---
> float fates_leaf_vcmax25top(fates_pft) ;
370,372d367
< float fates_mort_hf_flc_threshold(fates_pft) ;
< fates_mort_hf_flc_threshold:units = "fraction" ;
< fates_mort_hf_flc_threshold:long_name = "plant fractional loss of conductivity at which drought mortality begins for hydraulic model" ;
397,399d391
< float fates_phenflush_fraction(fates_pft) ;
< fates_phenflush_fraction:units = "fraction" ;
< fates_phenflush_fraction:long_name = "Upon bud-burst, the maximum fraction of storage carbon used for flushing leaves" ;
415,429d406
< float fates_prt_alloc_priority(fates_prt_organs, fates_pft) ;
< fates_prt_alloc_priority:units = "index (0-fates_prt_organs)" ;
< fates_prt_alloc_priority:long_name = "Priority order for allocation" ;
< float fates_prt_nitr_stoich_p1(fates_prt_organs, fates_pft) ;
< fates_prt_nitr_stoich_p1:units = "(gN/gC)" ;
< fates_prt_nitr_stoich_p1:long_name = "nitrogen stoichiometry, parameter 1" ;
< float fates_prt_nitr_stoich_p2(fates_prt_organs, fates_pft) ;
< fates_prt_nitr_stoich_p2:units = "(gN/gC)" ;
< fates_prt_nitr_stoich_p2:long_name = "nitrogen stoichiometry, parameter 2" ;
< float fates_prt_phos_stoich_p1(fates_prt_organs, fates_pft) ;
< fates_prt_phos_stoich_p1:units = "(gP/gC)" ;
< fates_prt_phos_stoich_p1:long_name = "phosphorous stoichiometry, parameter 1" ;
< float fates_prt_phos_stoich_p2(fates_prt_organs, fates_pft) ;
< fates_prt_phos_stoich_p2:units = "(gP/gC)" ;
< fates_prt_phos_stoich_p2:long_name = "phosphorous stoichiometry, parameter 2" ;
468c445
< fates_seed_dbh_repro_threshold:long_name = "the diameter (if any) where the plant will start extra clonal allocation to the seed pool" ;
---
> fates_seed_dbh_repro_threshold:long_name = "the diameter (if any) where the plant will start extra clonal allocation to the seed pool (NOT USED YET)" ;
478,480d454
< float fates_senleaf_long_fdrought(fates_pft) ;
< fates_senleaf_long_fdrought:units = "unitless[0-1]" ;
< fates_senleaf_long_fdrought:long_name = "multiplication factor for leaf longevity of senescent leaves during drought" ;
505,516d478
< float fates_turnover_carb_retrans(fates_prt_organs, fates_pft) ;
< fates_turnover_carb_retrans:units = "-" ;
< fates_turnover_carb_retrans:long_name = "retranslocation fraction of carbon in turnover" ;
< float fates_turnover_nitr_retrans(fates_prt_organs, fates_pft) ;
< fates_turnover_nitr_retrans:units = "-" ;
< fates_turnover_nitr_retrans:long_name = "retranslocation fraction of nitrogen in turnover" ;
< float fates_turnover_phos_retrans(fates_prt_organs, fates_pft) ;
< fates_turnover_phos_retrans:units = "-" ;
< fates_turnover_phos_retrans:long_name = "retranslocation fraction of phosphorous in turnover " ;
< float fates_turnover_retrans_mode(fates_pft) ;
< fates_turnover_retrans_mode:units = "index" ;
< fates_turnover_retrans_mode:long_name = "retranslocation method for leaf/fineroot turnover" ;
597,599c559
< " Indices = [1, 1] \n",
< " Wed Aug 29 12:14:41 PDT 2018: (RGK) Updated latosa to la_per_sa (inverts units, invert defaults also)\n",
< "" ;
---
> " Indices = [1, 1]" ;
602c562
< fates_history_height_bin_edges = 0, 0.1, 0.3, 1, 3, 10 ;
---
> fates_history_height_bin_edges = 0, 0.1, 0.3, 0.5, 1, 2 ;
604,605c564,565
< fates_history_sizeclass_bin_edges = 0, 5, 10, 15, 20, 30, 40, 50, 60, 70,
< 80, 90, 100 ;
---
> fates_history_sizeclass_bin_edges = 0, 0.05, 0.1, 0.15, 0.2, 0.3, 0.4, 0.5,
> 0.6, 0.7, 0.8, 0.9, 1 ;
627c587
< fates_hydr_kmax_rsurf = 20 ;
---
> fates_hydr_kmax_rsurf = 0.001 ;
651c611
< fates_mort_understorey_death = 0.55983 ;
---
> fates_mort_understorey_death = 0.09 ;
673c633
< fates_soil_salinity = 0.4 ;
---
> fates_soil_salinity = 0 ;
676,677c636,637
< "broadleaf_evergreen_tropical_tree ",
< "broadleaf_evergreen_tropical_tree " ;
---
> "Spartina alterniflora (short form) ",
> "Spartina alterniflora (tall form) " ;
679,685c639
< fates_prt_organ_name =
< "leaf ",
< "fine root ",
< "sapwood ",
< "storage ",
< "reproduction ",
< "structure " ;
---
> fates_alloc_storage_cushion = 5.25, 3.75 ;
687c641
< fates_alloc_storage_cushion = 2, 2 ;
---
> fates_allom_agb1 = 0.001928, 0.001928 ;
689c643
< fates_allom_agb1 = 0.06896, 0.06896 ;
---
> fates_allom_agb2 = 1.9492, 1.9492 ;
691c645
< fates_allom_agb2 = 0.572, 0.572 ;
---
> fates_allom_agb3 = 0, 0 ;
693c647
< fates_allom_agb3 = 1.94, 1.94 ;
---
> fates_allom_agb4 = 0, 0 ;
695,697c649
< fates_allom_agb4 = 0.931, 0.931 ;
<
< fates_allom_agb_frac = 0.6, 0.6 ;
---
> fates_allom_agb_frac = 1, 1 ;
705c657
< fates_allom_d2bl1 = 0.07, 0.07 ;
---
> fates_allom_d2bl1 = 0.000964, 0.000964 ;
707c659
< fates_allom_d2bl2 = 1.3, 1.3 ;
---
> fates_allom_d2bl2 = 1.9492, 1.9492 ;
709c661
< fates_allom_d2bl3 = 0.55, 0.55 ;
---
> fates_allom_d2bl3 = 0, 0 ;
711c663
< fates_allom_d2ca_coefficient_max = 0.6568464, 0.6568464 ;
---
> fates_allom_d2ca_coefficient_max = 0.03, 0.03 ;
713c665
< fates_allom_d2ca_coefficient_min = 0.3381119, 0.3381119 ;
---
> fates_allom_d2ca_coefficient_min = 0.01, 0.01 ;
715c667
< fates_allom_d2h1 = 0.64, 0.64 ;
---
> fates_allom_d2h1 = 1, 1 ;
717c669
< fates_allom_d2h2 = 0.37, 0.37 ;
---
> fates_allom_d2h2 = 1, 1 ;
721c673
< fates_allom_dbh_maxheight = 150, 150 ;
---
> fates_allom_dbh_maxheight = 1, 1 ;
725c677
< fates_allom_frbstor_repro = 0, 0 ;
---
> fates_allom_frbstor_repro = 1, 1 ;
727c679
< fates_allom_hmode = 1, 1 ;
---
> fates_allom_hmode = 3, 3 ;
729c681
< fates_allom_l2fr = 1, 1 ;
---
> fates_allom_l2fr = 0.75, 1.25 ;
731c683
< fates_allom_la_per_sa_int = 1000, 1000 ;
---
> fates_allom_latosa_int = 0.001, 0.001 ;
733c685
< fates_allom_la_per_sa_slp = 0, 0 ;
---
> fates_allom_latosa_slp = 0, 0 ;
737c689
< fates_allom_sai_scaler = 0.1, 0.1 ;
---
> fates_allom_sai_scaler = 0.0012, 0.0012 ;
762a715,716
> fates_froot_cn_ratio = 42, 42 ;
>
802,805c756,759
< -1.465984, -1.465984,
< -1.22807, -1.22807,
< -1.22807, -1.22807,
< -1.043478, -1.043478 ;
---
> -999, -999,
> -999, -999,
> -999, -999,
> -999, -999 ;
833c787
< fates_leaf_c3psn = 1, 1 ;
---
> fates_leaf_c3psn = 0, 0 ;
836a791,792
> fates_leaf_cn_ratio = 30, 30 ;
>
845,849c801
< fates_leaf_long =
< 0.75, 0.75,
< 0.75, 0.75 ;
<
< fates_leaf_slamax = 0.0954, 0.0954 ;
---
> fates_leaf_long = 1, 1 ;
851c803
< fates_leaf_slatop = 0.012, 0.012 ;
---
> fates_leaf_slatop = 0.016, 0.016 ;
861,863c813
< fates_leaf_vcmax25top =
< 50, 50,
< 50, 50 ;
---
> fates_leaf_vcmax25top = 70, 40 ;
883c833
< fates_mort_bmort = 0.014, 0.014 ;
---
> fates_mort_bmort = 0.9, 0.9 ;
885,887c835
< fates_mort_freezetol = 2.5, 2.5 ;
<
< fates_mort_hf_flc_threshold = 0.5, 0.5 ;
---
> fates_mort_freezetol = -25, -25 ;
897c845
< fates_pft_used = 1, 1 ;
---
> fates_pft_used = 1, 0 ;
899c847
< fates_phen_evergreen = 1, 1 ;
---
> fates_phen_evergreen = 0, 0 ;
901c849
< fates_phen_season_decid = 0, 0 ;
---
> fates_phen_season_decid = 1, 1 ;
905,906d852
< fates_phenflush_fraction = 0.5, 0.5 ;
<
917,955c863
< fates_prt_alloc_priority =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
<
< fates_prt_nitr_stoich_p1 =
< 0.033, 0.033,
< 0.024, 0.024,
< 0.0047, 0.0047,
< 0.0047, 0.0047,
< 0, 0,
< 0.0047, 0.0047 ;
<
< fates_prt_nitr_stoich_p2 =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
<
< fates_prt_phos_stoich_p1 =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
<
< fates_prt_phos_stoich_p2 =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
---
> fates_recruit_hgt_min = 0.05, 0.05 ;
957,959c865
< fates_recruit_hgt_min = 1.25, 1.25 ;
<
< fates_recruit_initd = 0.2, 0.2 ;
---
> fates_recruit_initd = 1e+07, 0 ;
969c875
< fates_root_long = 1, 1 ;
---
> fates_root_long = 0.5, 1 ;
991,992d896
< fates_senleaf_long_fdrought = 1, 1 ;
<
1009,1035c913
< fates_turnover_carb_retrans =
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0,
< 0, 0 ;
<
< fates_turnover_nitr_retrans =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
<
< fates_turnover_phos_retrans =
< _, _,
< _, _,
< _, _,
< _, _,
< _, _,
< _, _ ;
<
< fates_turnover_retrans_mode = 1, 1 ;
<
< fates_wood_density = 0.7, 0.7 ;
---
> fates_wood_density = 0.01, 0.01 ;
Here, I'd propose that if @xuchongang wants to maintain this going forward, that we work to create a diff file and store this PFT information in that, rather than in the pft file here. Would that work?
Thanks Charlie. That's almost certainly the way forward. It also rather ups the urgency of thinking about the '14 pft' case as the default. Do you think there's an argument for maybe pruning out some of the less physiologically meaningful pfts, until we have a better basis for representing them, to get to a more minimalist baselin
@rosiealice yes, absolutely. I'd advocate using a pretty minimal a PFT set to begin with, upon which we build complexity by cloning and modifying PFTs in an intentional way using the scripting infrastructure. Which PFTs do you propose we preserve in the default file?
Looking at the above, I don't see a reason why we can't just choose one set of these for each variable and, where applicable, put it into the 14 PFT file, and then delete the 2-PFT file.
I agree with that
But I'd personally feel comfortable putting the hydraulic allometries into the default file and solving the too-high respiration problem with low sapwood N, as is being done in the hydraulic file. So again, I'd propose just incorporating these values into the default and getting rid of the "hydro default" file.
agree with that too
Just discussed with @rgknox. Unless we hear loud complaints, we are going to proceed with the plan of merging the information from both the 2 PFT hydro file and the 2-PFT tropical default file into the tropical broadleaf evergreen PFT that is in the 14-PFT file, and will then delete both of those 2-PFT files.
For the coastal veg file, we will leave that as-is for now and follow up on that in a bit.
Another pair of questions on the subject of default PFT files:
(1) The default allometries on the tropical forest PFT are all pretty out of date (Height allometry is Obrien, 1995; AGB allometry is Saldariaga). For the ensemble simulations that I've been running, I've set all the ensemble members to use the Chave AGB allometry and the Martinez-Cano height allometry via this script here: https://github.com/ckoven/runscripts/blob/master/BCI_testbed/preprocess_base_parameter_file.bash. My question is: should we set these allometries as default values? I am not aware of any reasons other than historical continuity to keep the old allometries as our defaults, and so I'd advocate switching to the newer allometries. But interested if others want to keep the old defaults.
(2) Since @rgknox put in the capability for multiple leaf age bins, we've had 2 bins as our default system, but with identical values in both age bins (e.g. see here: https://github.com/NGEET/fates/blob/master/parameter_files/fates_params_14pfts.cdl#L998). This was done partially just for testing purposes to make sure the code was getting exercised during testing. But with the new scripting infrastructure, we should be able to set a 1 leaf age bin as our default, while also setting some tests that exercise a multiple leaf age bins case as a test (see here for how we propose to do this: https://github.com/ESMCI/cime/issues/2935). Are people ok with that solution too? At some point we can move to a real leaf age bin system, but that requires more science to assess the effects, so for now I feel like we should just revert to the simple 1 leaf age bin case until that science is done.
Notes:
Per Rosie's suggestion about pruning out redundant trees (also following an email discussion with her):
consolidated "broadleaf_deciduous_temperate_tree" and "broadleaf_deciduous_boreal_tree" into a single extra-tropical cold deciduous broadleaf tree
consolidated "needleleaf_evergreen_temperate_tree" and "needleleaf_evergreen_boreal_tree" into a single extra-tropical evergreen needleaf tree
New PFT names:
fates_pftname = "broadleaf_evergreen_tropical_tree ", "needleleaf_evergreen_extratrop_tree ", "needleleaf_colddecid_extratrop_tree ", "broadleaf_evergreen_extratrop_tree ", "broadleaf_hydrodecid_tropical_tree ", "broadleaf_colddecid_extratrop_tree ", "broadleaf_evergreen_extratrop_shrub ", "broadleaf_hydrodecid_extratrop_shrub ", "broadleaf_colddecid_extratrop_shrub ", "arctic_c3_grass ", "cool_c3_grass ", "c4_grass " ;
setting carbon retranslocation to 0.025 (2.5%), evenly for all PFTS, applying only to the leaf pool. (fates_turnover_carb_retrans)
setting fates_allom_la_per_sa_int to 0.8 for all PFTs. (Even though grasses probably don't have "sapwood", this is probably the safest default assumption hydraulically for grasses. And again, all PFTs will have an artificially high C:N ratio imposed on sapwood so grasses will not have false sapwood respiration costs.
setting fates_hydr_kmax_rsurf = 20 ;
setting fates_hydr_pinot_node = -1.465984, -1.22807, -1.22807, -1.043478 for all plants
setting nitrogen stoichiometric ratio for sapwood (fates_prt_nitr_stoich_p1) : 1.0e-8
Change some outlier values associated with the tropical broadleaf evergreen to be more inline with the rest of the group:
fates_alloc_storage_cushion = 2 -> 1.2 ; fates_allom_dbh_maxheight = 150 -> 90 ; fates_mort_freezetol = 2.5 -> -30 ;
Per suggestions from Jackie, reduce the recruit size and dbh at maximum height for grasses to make them always smaller than new tree recruits (last 3 pfts are grasses):
fates_recruit_hgt_min = 1.25, 1.25, 1.25, 1.25, 1.25, 1.25, 0.75, 0.75, 0.75, 0.125, 0.125, 0.125 ; fates_allom_dbh_maxheight = 90, 90, 90, 90, 90, 90, 3, 3, 2, 0.3744, 0.3744, 0.3744 ;
current working branch diff with master:
https://github.com/NGEET/fates/compare/master...rgknox:consolidated-pft-file
@rgknox awesome! but also, that diff in your last comment isn't useful because it gets garbled by the variable sorting. maybe we should run the variable sorting script first, with no other changes, and issue a PR for just that -- that way we'll have an interpretable diff to look at?
yeah, that makes sense. That diff ... too much going on there.
On a side note: I'm noticing is that the tropical (broadleaf) evergreen PFT has a competitive disadvantage with the extra-tropical (needleleaf) evergreens in several important categories: vcmax, leaf nitrogen-content (which determines maint respiration) and leaf lifespan; but has no advantages in any categories.
I created a special branch, base off of master, where I created a new fates_params_default.cdl file. This file is based on the existing 14 pft file, and uses the index swapper to remove pfts 3 and 8, and uses the sorting algorithm. Comparing the fates_params_default.cdl in PR #514 with this new file should just highlight changes to parameters themselves.
https://github.com/rgknox/fates/compare/12-pft-sorted-default...rgknox:consolidated-pft-file
Should note that these grass DBH max values were calculated for the O’Brien allometry. If there is different allometry they may change.
Jackie
On Thu, Mar 28, 2019 at 2:52 PM Ryan Knox notifications@github.com wrote:
I created a special branch, base off of master, where I created a new fates_params_default.cdl file. This file is based on the existing 14 pft file, and uses the index swapper to remove pfts 3 and 8, and uses the sorting algorithm. Comparing the fates_params_default.cdl in PR #514 https://github.com/NGEET/fates/pull/514 with this new file should just highlight changes to parameters themselves.
rgknox/fates@12-pft-sorted-default...rgknox:consolidated-pft-file https://github.com/rgknox/fates/compare/12-pft-sorted-default...rgknox:consolidated-pft-file
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/444#issuecomment-477726407, or mute the thread https://github.com/notifications/unsubscribe-auth/AVFDhn3pdAAyLoC6W2L1V4CX2qIMK5Xyks5vbQ9dgaJpZM4Y4YIu .
-- Jacquelyn Shuman Terrestrial Sciences Section NCAR
Agreed, lets not mess with the grass allometries, since the chave ones are just for trees anyway.
There is also danger that if we change the tree allometries, their initial heights could drop below the current maximum grass heights. EDIT: Strike that, I forgot we initialize plants by height not dbh.
we have come a long way in handling parameter files. We have the batchpatch utility and the xmldiff framework. As well as the modparam and pftindex swapper scripts. Closing.
With new features being added to FATES, we are starting to maintain more than 1 "default" parameter file. Here is the group we have now and soon to be added:
1) the "default default", which contains 2 clones of a single tropical PFT. 2) the 14 PFT default, which contains 14 different non-optimized PFTs that roughly cover a global set of PFTs 3) a hydro default, which modifies some of the parameters in the "default default" to accomodate hydraulics 4) a coastal vegetation default
Soon, I would like to abandon the "default-default" and use the 14 PFT file as the file we use for continuous testing.
I'm proposing that going forward, instead of maintaining multiple "default" files, we maintain only 1, and track the different options that people like to maintain in a single "diff style" file.
This diff file (short for "difference"), will be a text file, perhaps XML/Jason/unformatted. It will be broken into sections that are intended to provide alternatives to the default parameter file for different use cases. Each section will define which PFTs of the 14 PFT set should be used. And then it will list the parameters and the values that should be modified.
We could create a python script that would take an argument specifying which use-case to process, and would convert the base file, via the diff file, into either a CDL or netcdf file.
I think this would also make life easier for all users. They could maintain there own diff files, and would not have to go through the work of constantly updating their own parameter files whenever a new non-relevant parameter is added to the default.