Open ckoven opened 1 year ago
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.
things to do still:
One way this might work is to change the use_fates_logging from a boolean flag to an integer flag with the following values:
- [x] 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
). https://github.com/NGEET/fates/pull/1112 will address this in the toolchain.
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.
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
.
- [ ] 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:
- no logging
- current-behavior logging (coming from big-leaf land-use data file, with area-vs-carbon based on the metadata in that file
- use data from FATES LUH2 file, area-based
- 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
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
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: https://github.com/glemieux/E3SM/issues/30#issuecomment-1918003090
making a list of things that will be needed to get nocomp and land use change working together in FATES
bc_in(s)%pft_areafrac(:)
at all). Handling crop logic is needed for all configurations, not just the nocomp configurations.bc_in(s)%pft_areafrac(:)
(see next entry in issue)