make land use change and nocomp work together

[ckoven]

making a list of things that will be needed to get nocomp and land use change working together in FATES

• read new parameters in file
• allocate enough patches
• initialize patch nocomp PFT identity
  • separately handle logic for crops and non-crop managed lands (since crop info not in bc_in(s)%pft_areafrac(:) at all). Handling crop logic is needed for all configurations, not just the nocomp configurations.
  • needs a site-level LU : PFT mapping array
    • reconcile logic with big-leaf assumptions; possibly go back to CLM land use tool files directly instead of the logic that is in bc_in(s)%pft_areafrac(:) (see next entry in issue)
  • allow for testing in SP-mode configuration with land use change (or initialization anyway) active
• transition patch nocomp PFT identity during land use change disturbance
  • requires ability to fuse together all just-transitioned patches and re-split them into new PFT-labels
  • different logic required for different types of transitions:
    • (Prim/Sec/Crop) -> (Pasture/Range)
    • (Pasture/Range/Crop) -> (Prim/Sec)
    • (Prim/Sec/Pasture/Range) -> (Crop)

[ckoven]

Notes to self on how to handle this (copied from email I just wrote):

We need the various files at https://gdex.ucar.edu/dataset/188b_oleson/file.html such as CLM5_current_luhpasture_deg025.nc, CLM5_current_luhforest_deg025.nc, CLM5_current_luhother_deg025.nc, CLM5_current_surf_deg025.nc, etc.

Basically the prescribed landcover version in the absence of land use change currently uses the PFT map from the surface dataset file, which I believe is a regridded version of current_surf file, and which I believe is essentially a weighted average of the forest/pasture/other PFT maps, as weighted by the year-2005 land use from LUH2.

So for FATES non-crop PFTs, what we would want to do for a nocomp configuration with land use change is read in a regridded version of the forest/pasture/other PFT maps directly, which would put into the same file that we are currently putting the luh2 data into. And then for each gridcell, we would assign a PFT x land-use matrix that defines the nocomp PFT weighting for each land use type in that gridcell. So primary and secondary lands would both be the forest/nonforest-weighted average of the forest and other maps, rangelands would just be other, and pasture would be pasture.

Once we have that matrix, then FATES would initialize the nocomp PFTs based on the weighting matrix and the land use types for a given year, and then would update the nocomp patch areas to reflect the changing land use weightings over time as driven by the transition matrix.

[ckoven]

things to do still:

• add parameters and logic to handle harvest pools and fire during both logging and land use transitions
• reduce number of PFTs on each land use type if greater than number of patches allocated to that type
• reorganize patch insertion logic so that it has nested lists ordered by: first land use, then nocomp PFT, then age. Note: this is now handled in f0797f2
• add logic to handle case where no data exists on PFT/LU dataset

[ckoven]

• add logic to allow logging info to come from land use data stream rather than surface file.

One way this might work is to change the use_fates_logging from a boolean flag to an integer flag with the following values:

0. no logging
1. current-behavior logging (coming from big-leaf land-use data file, with area-vs-carbon based on the metadata in that file
2. use data from FATES LUH2 file, area-based
3. use data from FATES LUH2 file, carbon-based

[ckoven]

• turn back on all disturbance types
• deal with switches for potential veg mode

[ckoven]

• check that initialization works at several timepoints.
• remake landuse forcing data back to 1700

[ckoven]

• debug transition rates which appear to be zero

[ckoven]

• figure out why some gridcells have some of the land use / pft or bare ground data as NaNs but not all of them, which is likely responsible for the handful of gridcells that are all bare ground.
  

[glemieux]

• debug transition rates which appear to be zero

This ended up being due to YEAR variable on the dataset being years since 1850 valued instead of absolute valued (i.e. 1000 instead of 1850). NGEET#1112 will address this in the toolchain.

[ckoven]

• change land use logic from always ignoring land use types below the area threshold to tracking whether or not area is below the threshold and then applying all the prior un-applied landuse on first day that it exceeds the threshold

[ckoven]

• come up with a solution to the starting-extinct problem for nocomp PFTs when transitioning from potential vegetation to land use (see first bullet point at end of initial post in Issues and workflow around initialization of FATES for global historical runs with land use change NGEET/fates#1080 for reference)

[ckoven]

• got a weird error on reading restart that I don't understand, it seems like somehow there are more patches than should be allowed?

  0: See MPICH_MPIIO_DVS_MAXNODES in the intro_mpi man page.
 23: forrtl: severe (408): fort: (2): Subscript #1 of the array ALBD_PARB has value 20 which is greater than the upper bound of 19
 23: 
 23: Image              PC                Routine            Line        Source             
 23: e3sm.exe           0000000003B59D44  fatesrestartinter        3679  FatesRestartInterfaceMod.F90
 23: e3sm.exe           0000000000B76082  elmfatesinterface        1761  elmfates_interfaceMod.F90
 23: e3sm.exe           0000000000E9E189  restfilemod_mp_re         633  restFileMod.F90
 23: e3sm.exe           00000000009DAE84  elm_initializemod         821  elm_initializeMod.F90
 23: e3sm.exe           000000000093329A  lnd_comp_mct_mp_l         286  lnd_comp_mct.F90
 23: e3sm.exe           0000000000483711  component_mod_mp_         257  component_mod.F90
 23: e3sm.exe           0000000000430B88  cime_comp_mod_mp_        1453  cime_comp_mod.F90
 23: e3sm.exe           000000000047A6B7  MAIN__                    122  cime_driver.F90
 23: e3sm.exe           000000000041D23D  Unknown               Unknown  Unknown
 23: libc-2.31.so       00001526A19DE24D  __libc_start_main     Unknown  Unknown
 23: e3sm.exe           000000000041D16A  Unknown               Unknown  Unknown
srun: error: nid004954: task 23: Exited with exit code 152
srun: Terminating StepId=18001736.0

note that this was not the first read/write of restarts, it was the second one (after 2 successful 3-month iterations)

EDIT ran into this again in a different run:

 88: forrtl: severe (408): fort: (2): Subscript #1 of the array ALBD_PARB has value 24 which is greater than the upper bound of 23
 88: 
 88: Image              PC                Routine            Line        Source             
 88: e3sm.exe           0000000003B5E1DA  fatesrestartinter        3695  FatesRestartInterfaceMod.F90
 88: e3sm.exe           0000000000B76082  elmfatesinterface        1761  elmfates_interfaceMod.F90
 88: e3sm.exe           0000000000E9E189  restfilemod_mp_re         633  restFileMod.F90
 88: e3sm.exe           00000000009DAE84  elm_initializemod         821  elm_initializeMod.F90
 88: e3sm.exe           000000000093329A  lnd_comp_mct_mp_l         286  lnd_comp_mct.F90
 88: e3sm.exe           0000000000483711  component_mod_mp_         257  component_mod.F90
 88: e3sm.exe           0000000000430B88  cime_comp_mod_mp_        1453  cime_comp_mod.F90
 88: e3sm.exe           000000000047A6B7  MAIN__                    122  cime_driver.F90
 88: e3sm.exe           000000000041D23D  Unknown               Unknown  Unknown
 88: libc-2.31.so       000014BC23D9C24D  __libc_start_main     Unknown  Unknown
 88: e3sm.exe           000000000041D16A  Unknown               Unknown  Unknown
srun: error: nid005255: task 88: Exited with exit code 152
srun: Terminating StepId=18063866.0

second edit: I believe that commit 401bdd8 might fix this, but I don't fully understand the nature of the problem and so want to confirm that that is the best solution.

[ckoven]

• make a new parameter file variable similar to fates_maxpatches_by_landuse(fates_landuseclass) called fates_max_nocomp_pfts_by_landuse(fates_landuseclass). ensure in set_site_properties that it is <= fates_maxpatches_by_landuse, and use it in set_site_properties logic instead of fates_maxpatches_by_landuse.

[ckoven]

• understand why initial harvest rate logic does not lead to the expected amount of secondary forest area, and then turn transitions to secondary forest back on

[glemieux]

• add logic to allow logging info to come from land use data stream rather than surface file.

One way this might work is to change the use_fates_logging from a boolean flag to an integer flag with the following values:

0. no logging
1. current-behavior logging (coming from big-leaf land-use data file, with area-vs-carbon based on the metadata in that file
2. use data from FATES LUH2 file, area-based
3. use data from FATES LUH2 file, carbon-based

Branch started here off of Landuse V1 e3sm PR: https://github.com/glemieux/E3SM/tree/lnd/fates-luh2-harvest

[ckoven]

HI @glemieux in addition to use_fates_potentialveg, it looks like flandusepftdat is also not in E3SM/components/elm/bld/namelist_files/namelist_definition.xml in 76342e3

[glemieux]

sorry, I created a new branch that merges the harvest + v2 landuse together to be the new 'official' code called lnd/fates-landuse_v2-pft-harvest.

For background see: glemieux/E3SM#30 (comment)