ESCOMP
FATES history dimension control
Description of changes
Namelist settings have been added that add controls over how dense FATES history output is. FATES has output that is updated at the model timestep (~30 min), and output that is updated at the dynamics (daily) timestep. Likewise, FATES has many diagnostics that use the 3rd dimensions to describe things like patch age, demographics, etc. The user can now control which of these types of output are calculated. Note a key aspect here. These settings not only filter which sets of variables are written, but it filters which sets of variables are allocated and processed in memory.
A method to cross reference and check if any output variables specifically requested in the NL are not set to be allocated has been added, this will provide a graceful and verbose fail so the user can adjust things if necessary.
Here is a description of the namelist control from clm_varctl.F90:
! FATES history density level
! fates can produce history at either the daily timescale (dynamics)
! and the model step timescale. It can also generate output on the extra dimension
! Performing this output can be expensive, so we allow different history density
! levels.
! The first index is output at the model timescale
! The second index is output at the dynamics (daily) timescale
! 0 - no output
! 1 - include only column level means
! 2 - include only output with only 1 additional dimension
! 3 - include all multiplexed dimensions
integer, dimension(2), public :: fates_hist_dense_level = (/1,1/)
Specific notes
Synchronized with: https://github.com/NGEET/fates/pull/1119
Testing Plan:
- For this pull request, we will keep all tests at level "2,2" which essentially preserves all behavior by continuing to allocate and prepare all fates history variables.
- Following this pull request, we will change the AllVars tests to specifically use "2,2", expand the AllVarsto to be called in more scenarios (such as with other module combos like biogeography, hydro, nutrients, recruitment, damage and landuse), the bulk of all tests will be reduced to level 1,1 and one test will be reduced to level 0,0
Contributors other than yourself, if any: fates dev team
CTSM Issues Fixed (include github issue #):
Are answers expected to change (and if so in what way)?
Any User Interface Changes (namelist or namelist defaults changes)?
Testing performed, if any: (List what testing you did to show your changes worked as expected) (This can be manual testing or running of the different test suites) (Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide) (aux_clm on cheyenne for intel/gnu and izumi for intel/gnu/nag/pgi is the standard for tags on master)
NOTE: Be sure to check your coding style against the standard (https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review the list of common problems to watch out for (https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).
I ran three tests, using Levels "0,0" "1,1" and "2,2". Each test used the f45 grid, fixed biogeography and nocomp, and benefited from 15 years of spinup prior to the timing assessment, which was over the last 5 years of simulation. The "0,0" and "1,1" tests were a wash and showed no real differences. The "2,2" test was about 10% slower than the other two.
00: 4325.242 seconds 2.370 seconds/day 11: 4295.048 seconds 2.353 seconds/day 22: 4605.272 seconds 2.523 seconds/day
I'm going to write this down as a win because users who don't need the fully multiplexed variables can save run-time. I would expect that there will be more savings in runs that use full demography since their would be larger cohort loops to traverse in filling the multiplexed output variables.
@ekluzek was wondering if we can rename this because to him "density" seems like single vs. double precision
