Roundoff error too large when running with land use and ne30 grid

[kjetilaas]

Describe the issue

When testing CLM-FATES with updated (LUH3) land use files (for NorESM), we trigger what looks like a roundoff error in the patch dynamics code. This happens at the end of the first day after going from potential vegetation spinup to running with transient land use, and the error is just marginally larger than the rounoff limit (1.02e-12 vs 1.0e-12). Doubling the roundoff error limit (i .e. using rsnbl_math_prec = 2.0e-12_fates_r8) is enough to make simulation run.

So far, we have only seen this problem when using ne30 grid (1 degree spectral element). The input files are produced with a modified version of the fates landuse tool:
https://github.com/maritsandstad/tools-fates-landusedata/tree/main
or:
https://github.com/maritsandstad/constantlanduse
(both of these fail with the similar violation of the roundoff error).

Simulations using input files with 4x5 grid the same input files (LUH3) has not so far triggered this error.

@rgknox @ckoven @glemieux @rosiealice @maritsandstad

Relevant log output

616:  Warning. small nocomp patch wasnt able to find another patch to fuse with.
 616:            1           2  5.550149463603123E-003
 377:  Warning. small nocomp patch wasnt able to find another patch to fuse with.
 377:            0           0  1.186485325720737E-003
 728:  Warning. small nocomp patch wasnt able to find another patch to fuse with.
 728:           14           2  5.920596576997346E-003
1044:  Buffer patch still has area and it wasnt put into the linked list
1044:  buffer_patch%area  1.023181539494544E-012
1044:    6723.10513420105        6723.10513420105     
1044:  -1.023181539494544E-012
1044:  ENDRUN:

FATES tag

sci.1.82.3_api.39.0.0_noresm_v2

Host land model tag

ctsm5.3.034_noresm_v6 (https://github.com/NorESMhub/CTSM.git)

Machine

other HLM supported machine

Other supported machine name

betzy (Norwegian infrastrucutre)

Additional context

No response

[ckoven]

Thanks @kjetilaas and sorry -- I had seen this error in the past but hoped it had gone away. One question: you say you triggered this with both the transient land use and the steady-state land use. The way I've been using steady-state land use is to start from bare-ground initial conditions (i.e. skipping the potential vegetation step entirely), is that how you are using it also? If not, is it possible in the NorESM workflow to skip the potential vegetation step and do a cold start from bare ground with the steady-state 1850 land use active?

In any case, it looks like we need to put in some logic to handle this error, perhaps by fusing the remaining patch area with one of the other patches that was just generated.

[kjetilaas]

Thanks @ckoven! So far I have been running the potential veg step first, but I can't say that I have a very good reason for that. And indeed, the model does not stop with this error if I start the constant landuse step from bare ground.