The first commit makes the bug fix to check against ifalse since hlm_use_potentialveg is not a boolean.
The second commit is my attempt to start bug fixing issues I was running into in spawn_patches. I'm not sure if they are a good solution, but figured I'd offer them up for review:
When copying into buffer_patch, currentPatch is null having come to the end of the previous do while loop, so I created a copyPatch pointer to grab the address of the last patch in said loop that matches the i_land_use_label to be used in the copy into buffer_patch section. I wasn't sure if we need to be concerned with averaging tveg (and other values) with those values from a different landuse label.
In the fraction_to_keep loop, fusing currentPatch into buffer_patch deallocates the former, so I just added some helper pointers to make sure the currentPatch pointer was in the right place before hitting the currentPatch => currentPatch%younger update (which was hitting null).
Note that this still is failing run with the following error, which I think is due to there being a division by zero due to nocomp_pft_area_vector having a zero in it:
128: Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
128:
128: Backtrace for this error:
128: #0 0x153cb2eaddbf in ???
128: #1 0x19c2e93 in __edpatchdynamicsmod_MOD_spawn_patches
128: at /global/u1/g/glemieux/E3SM-project/e3sm/components/elm/src/external_models/fates/biogeochem/EDPatchDynamicsMod.F90:1390
128: #2 0x1748f2c in __edmainmod_MOD_ed_ecosystem_dynamics
128: at /global/u1/g/glemieux/E3SM-project/e3sm/components/elm/src/external_models/fates/main/EDMainMod.F90:296
128: #3 0x7865c4 in __elmfatesinterfacemod_MOD_dynamics_driv
128: at /global/u1/g/glemieux/E3SM-project/e3sm/components/elm/src/main/elmfates_interfaceMod.F90:1121
128: #4 0x687e3d in __elm_driver_MOD_elm_drv
128: at /global/u1/g/glemieux/E3SM-project/e3sm/components/elm/src/main/elm_driver.F90:1290
128: #5 0x650987 in __lnd_comp_mct_MOD_lnd_run_mct
128: at /global/u1/g/glemieux/E3SM-project/e3sm/components/elm/src/cpl/lnd_comp_mct.F90:514
128: #6 0x4810ab in __component_mod_MOD_component_run
128: at /global/u1/g/glemieux/E3SM-project/e3sm/driver-mct/main/component_mod.F90:734
128: #7 0x464de1 in __cime_comp_mod_MOD_cime_run
128: at /global/u1/g/glemieux/E3SM-project/e3sm/driver-mct/main/cime_comp_mod.F90:2916
128: #8 0x47e7a5 in cime_driver
128: at /global/u1/g/glemieux/E3SM-project/e3sm/driver-mct/main/cime_driver.F90:153
128: #9 0x47e808 in main
128: at /global/u1/g/glemieux/E3SM-project/e3sm/driver-mct/main/cime_driver.F90:23
srun: error: nid006444: task 128: Floating point exception
Collaborators:
Expectation of Answer Changes:
Checklist:
[ ] My change requires a change to the documentation.
[ ] I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
Description:
The first commit makes the bug fix to check against
ifalsesincehlm_use_potentialvegis not a boolean.The second commit is my attempt to start bug fixing issues I was running into in
spawn_patches. I'm not sure if they are a good solution, but figured I'd offer them up for review:buffer_patch,currentPatchisnullhaving come to the end of the previousdo whileloop, so I created acopyPatchpointer to grab the address of the last patch in said loop that matches thei_land_use_labelto be used in the copy intobuffer_patchsection. I wasn't sure if we need to be concerned with averagingtveg(and other values) with those values from a different landuse label.fraction_to_keeploop, fusingcurrentPatchintobuffer_patchdeallocates the former, so I just added some helper pointers to make sure thecurrentPatchpointer was in the right place before hitting thecurrentPatch => currentPatch%youngerupdate (which was hittingnull).Note that this still is failing run with the following error, which I think is due to there being a division by zero due to
nocomp_pft_area_vectorhaving a zero in it:Collaborators:
Expectation of Answer Changes:
Checklist:
Test Results:
CTSM (or) E3SM (specify which) test hash-tag:
CTSM (or) E3SM (specify which) baseline hash-tag:
FATES baseline hash-tag:
Test Output: