Confusing output in FATES-SP history files

[wwieder]

There are a number of confusing carbon cycle variables that are output for FATES-SP cases including mortality fluxes, vegetation C pools, and even heterotrophic respiration fluxes.

Can we remove these from the FATES-sp output?

[adrifoster]

I agree, I think we should try to pare down the SP-mode output to only include variables that are relevant in SP mode.

@rgknox @glemieux we had discussed refactoring the variable output... would this require a huge refactoring as well?

[ekluzek]

The easiest way to start this would be to create a user-mod directory for FATES-SP (which wouldn't be bad to do anyway). It could then exclude history fields that aren't useful, and/or include only the ones that make sense. Later you might want to turn the defaults on and off according to the fates SP control item.

[ckoven]

agreed that this is confusing. I see a few ways to do this. The simplest way (I think) is to make a character variable, something like true_if_not_sp_mode that is either active or inactive, depending on the configuration, and use that as the argument to use_default in define_history_vars. Then a user could still override if they wanted.

A more complex way would be to wrap the variable definitions in logic like we already do here: https://github.com/NGEET/fates/blob/master/main/FatesHistoryInterfaceMod.F90#L4523. In this case a user couldn't override because the variable simply would't exist.

@ekluzek I'm not sure I understand what you are suggesting, could you describe in greter detail what you mean?

[glemieux]

I like the idea of the former @ckoven. It seems that would be a more flexible way to implement future active/inactive defaults for other modes (if desired).

[ekluzek]

@ckoven what you suggest is the more robust longer term solution. What I suggest to start with though is that you setup a user-mod directory under cime_config/usermod_dirs, for fates_sp. It would then have a user_nl_clm file that would first turn FATES_SP on, but then also have hist_fincl_excl1 for the list of things that should be excluded.

You then add "--user-mods-dirs fates_sp" to your create_newcase when you are running. The user-mod could also be used for testing.

One disadvantage is that it's specific for CTSM. But, it gives you a chance to figure out the complete list of fields that do and don't make sense for fates-sp. And it's easy to add a new field if needed. Since, FATES-SP is a major mode for running FATES it makes sense that it have at least a user-mod directory to turn it on. Later we want to make turning it on more similar to how you turn on big leaf SP mode.

[ckoven]

got it, thanks @ekluzek. I guess the usermods approach would be compatible with the first approach that I described as well, so either or both could be done in any order. For the second approach that I described, it wouldn't be compatible with the usermods approach because (I think) if a hist_fincl_excl1 points to a variable that hasn't been defined, then it would crash, right? So if there is anything where we really don't think it can or should be defined in a given mode (as in the case I linked to) and want to not allow it even as a non-default option, then we should probably just do that and avoid any future conflicts.

[ekluzek]

Hi @ckoven, the hist_fincl_excl will work provided the history field is at least defined. It doesn't matter if it's default on or off it'll still work. So they do totally work together. You are right that if you have an if statement around a hist_addfld call, so it isn't even defined it would error out.

[ckoven]

I just did a first runthrough of variables that, based on my (subjective) perspective, are either not defined or aren't really very meaningful in SP mode, and followed the (first) approach that I described above to make them non-default. It's actually a pretty long list of variables that we don't want default in SP mode. So I think maybe we do want to try to keep this in the fortran, just to keep all the info in one place. I suspect that the list of default variables also needs some general going over anyway to pare down the more esoteric ones. But there are also most likely variables outside the FATES scope (soil carbon, etc) that we also would want to make non-default in FATES-SP mode, and we should definitely use @ekluzek's approach to do that as well.

commit is here: https://github.com/ckoven/fates/commit/cc3101a

If people agree both that (a) this way of handling things makes the most sense, and (b) this list of variables looks right, then I can add this either as its own PR or onto another PR that I will be submitting soon that has a few other minor changes and bugfixes to history variables.

[wwieder]

Hi Everyone,

It seems like some of this is also wrapped up in #859. I have an additional question that's related to the upcoming CTSM tutorial (May 25-26). Currently a sample of the FATESsp output that students will generate and be plotting is available here /glade/scratch/wwieder/archive/I2000_CTSM_FATESsp/lnd/hist/.

Are we OK to provide history files with these extra variables, or is this something we'd like to correct before the tutorial?

[ekluzek]

@wwieder I did create a user-mod directory that turns off a bunch of fields. Here's the hist_fexcl1 namelist setting for it

hist_fexcl1 = 'FATES_TRIMMING', 'FATES_COLD_STATUS', 'FATES_DROUGHT_STATUS', 'FATES_GDD', 'FATES_NCHILLDAYS',
              'FATES_NCOLDDAYS', 'FATES_DAYSINCE_COLDLEAFOFF', 'FATES_DAYSINCE_COLDLEAFON', 'FATES_DAYSINCE_DROUGHTLEAFOFF',
              'FATES_DAYSINCE_DROUGHTLEAFON', 'FATES_MEANLIQVOL_DROUGHTPHEN', 'FATES_CANOPY_SPREAD', 'FATES_VEGC_PF',
              'FATES_STOREC_PF', 'FATES_RECRUITMENT_PF', 'FATES_MORTALITY_PF', 'FATES_PATCHAREA_AP', 'FATES_LAI_AP',
              'FATES_CANOPYAREA_AP', 'FATES_NESTEROV_INDEX', 'FATES_IGNITIONS', 'FATES_FDI', 'FATES_ROS', 'FATES_EFFECT_WSPEED',
              'FATES_FUELCONSUMED', 'FATES_FIRE_INTENSITY', 'FATES_FIRE_INTENSITY_BURNFRAC', 'FATES_BURNFRAC', 'FATES_FUEL_MEF',
              'FATES_FUEL_BULKD', 'FATES_FUEL_EFF_MOIST', 'FATES_FUEL_SAV', 'FATES_FUEL_AMOUNT', 'FATES_FRAGMENTATION_SCALER_SL',
              'FATES_FUEL_MOISTURE_FC', 'FATES_FUEL_AMOUNT_FC', 'FATES_BURNFRAC_AP', 'FATES_FIRE_INTENSITY_BURNFRAC_AP',
              'FATES_FUEL_AMOUNT_AP', 'FATES_FUEL_BURNT_BURNFRAC_FC', 'FATES_LITTER_IN', 'FATES_LITTER_OUT', 'FATES_SEED_BANK',
              'FATES_SEEDS_IN', 'FATES_LITTER_IN_EL', 'FATES_LITTER_OUT_EL', 'FATES_SEED_BANK_EL', 'FATES_SEEDS_IN_LOCAL_EL',
              'FATES_SEEDS_IN_EXTERN_EL', 'FATES_SEED_GERM_EL', 'FATES_SEED_DECAY_EL', 'FATES_STOREC', 'FATES_VEGC',
              'FATES_SAPWOODC', 'FATES_FROOTC', 'FATES_REPROC', 'FATES_CEFFLUX', 'FATES_STRUCTC', 'FATES_NONSTRUCTC', 
              'FATES_VEGC_ABOVEGROUND', 'FATES_CANOPY_VEGC', 'FATES_USTORY_VEGC', 'FATES_PRIMARY_PATCHFUSION_ERR',
              'FATES_DISTURBANCE_RATE_P2P', 'FATES_DISTURBANCE_RATE_P2S', 'FATES_DISTURBANCE_RATE_S2S',
              'FATES_DISTURBANCE_RATE_FIRE', 'FATES_DISTURBANCE_RATE_LOGGING', 'FATES_DISTURBANCE_RATE_TREEFALL',
              'FATES_DISTURBANCE_RATE_POTENTIAL', 'FATES_HARVEST_CARBON_FLUX', 'FATES_GPP_CANOPY', 'FATES_AUTORESP_CANOPY',
              'FATES_GPP_UNDERSTORY', 'FATES_AUTORESP_UNDERSTORY', 'FATES_CROWNAREA_CL', 'FATES_DEMOTION_CARBONFLUX',
              'FATES_PROMOTION_CARBONFLUX', 'FATES_MORTALITY_CFLUX_CANOPY', 'FATES_MORTALITY_CFLUX_UNDERSTORY', 
              'FATES_DDBH_CANOPY_SZ', 'FATES_DDBH_USTORY_SZ', 'FATES_BASALAREA_SZ',
              'FATES_VEGC_ABOVEGROUND_SZ', 'FATES_LAI_CANOPY_SZ', 'FATES_MORTALITY_CANOPY_SZ', 'FATES_NPLANT_USTORY_SZ',
              'FATES_LAI_USTORY_SZ', 'FATES_NPLANT_SZ', 'FATES_NPLANT_AC', 'FATES_MORTALITY_BACKGROUND_SZ',
              'FATES_MORTALITY_HYDRAULIC_SZ', 'FATES_MORTALITY_CSTARV_SZ', 'FATES_MORTALITY_IMPACT_SZ',
              'FATES_MORTALITY_FIRE_SZ', 'FATES_MORTALITY_TERMINATION_SZ', 'FATES_MORTALITY_LOGGING_SZ',
              'FATES_MORTALITY_FREEZING_SZ', 'FATES_MORTALITY_SENESCENCE_SZ', 'FATES_MORTALITY_AGESCEN_SZ',
              'FATES_MORTALITY_AGESCEN_AC', 'FATES_MORTALITY_USTORY_SZ', 'FATES_FROOTMAINTAR', 'FATES_CROOTMAINTAR',
              'FATES_LSTEMMAINTAR', 'FATES_NEP', 'FATES_HET_RESP', 'FATES_FIRE_CLOSS', 'FATES_FIRE_FLUX_EL',
              'FATES_LITTER_AG_FINE_EL', 'FATES_LITTER_BG_FINE_EL', 'FATES_LITTER_BG_CWD_EL', 'FATES_LITTER_AG_CWD_EL',
              'FATES_LITTER_CWD_ELDC', 'FATES_LEAF_ALLOC', 'FATES_SEED_ALLOC', 'FATES_STEM_ALLOC', 'FATES_FROOT_ALLOC',
              'FATES_CROOT_ALLOC', 'FATES_STORE_ALLOC'

[wwieder]

Thanks @ekluzek this seems like a simple option that's quick to implement. Can we get this user_mod directory to main so that when students create their case these history files are excluded?

[ekluzek]

Yes, it's part of my work in FATES-SP setting soil_decomp_method == None. So it'll come to main-dev as part of that.

[wwieder]

great, here are some other FATES-side variables we can consider removing in FATES-sp history output. Maybe @ckoven or @adrifoster can confirm?

FATES_AUTORESP, FATES_GROWTH_RESP FATES_LEAFC, FATES_LEAFC_PF, FATES_LEAFMAINTAR, FATES_MAINT_RESP, FATES_NPP, FATES_NPP_PF, FATES_c_to_litr_cel_c, FATES_c_to_litr_lab_c, FATES_c_to_litr_lig_c,

[ckoven]

@wwieder I think that FATES_LEAFC and FATES_LEAFC_PF are meaningful in SP mode. I.e. not prognostic, but still meaningful, as in for sanity-checking purposes. The other ones you mention could be added to the do-not-include list.

[chengyun19]

我同意，我认为我们应该尝试减少 SP 模式输出以仅包含与 SP 模式相关的变量。

@rgknox @glemieux我们已经讨论过重构变量输出……这是否也需要大量重构？

Hello, I am a novice at running FATES. I find that the default SP model is false, I want to simulate GPP and NPP form 1970 to 2010. Do I need to turn on SP? And when should we turn on SP? I am not sure, can you help me? And in the I2000CLM50FATES compset, the CO2 is constant. Does this mean that I need to input the historical 1970-2010 CO2 data to get the 1970-2010 GPP and NPP? Any suggestions will be appreciated! Thanks in advance.