Patch fusion error: patch not associated

[glemieux]

While running a long-term case for #875, I ran into a defined fates error in the fuse_patches routine. Testing this with sci.1.57.4_api.24.0.0 replicated the error:

55: FATES fuse_patches(): currentPatch is not associated?
55: ENDRUN:
55: ERROR in EDPatchDynamicsMod.F90 at line 2398
55: ERROR: Unknown error submitted to shr_abort_abort.
55:Image              PC                Routine            Line        Source
55:cesm.exe           00000000013869D6  Unknown               Unknown  Unknown
55:cesm.exe           0000000000F07DE0  shr_abort_mod_mp_         114  shr_abort_mod.F90
55:cesm.exe           00000000008E0580  fatesglobals_mp_f          94  FatesGlobals.F90
55:cesm.exe           000000000089A03E  edpatchdynamicsmo        2398  EDPatchDynamicsMod.F90
55:cesm.exe           0000000000887B87  edmainmod_mp_ed_e         276  EDMainMod.F90
55:cesm.exe           00000000005F3883  clmfatesinterface        1025  clmfates_interfaceMod.F90
55:cesm.exe           00000000005CC59D  clm_driver_mp_clm        1136  clm_driver.F90
55:cesm.exe           0000000000577A72  lnd_comp_nuopc_mp         886  lnd_comp_nuopc.F90

This came up during a simple f10 gridded run with default parameter file and failed out in year 21.

[glemieux]

Testing a similar long-term f10 run on cheyenne with sci.1.56.0_api.23.0.0 appears at first glance to not result in the same issue (it hits the 6 hour wall clock before showing the same error). That said the job hit the wall at year 15.

[glemieux]

During discussion with @rgknox, he noted the reason this is showing up now is that it was recently converted from a write statement to an endrun in the update to reduce and covert write statements, specifically with commit d4e35f0. So this likely has been showing up in the past and I concur with his comment that this is expected behavior.

That said, we discussed a potential future improvement to add some sort of linked list checker functions to account for the patches/cohorts that have been removed to make sure that insertion/deletion was conducted correctly. Ryan noted that there had been discussion for this functionality in the past; I wasn't able to find an existing issue, so I may add that as an issue for a future enhancement.