FATES high level calling structure in CTSM is more complicated than it needs to be -- and exercises code it doesn't need to

[ekluzek]

I ran into this in the context of #2844, where I found out that FATES cases were pretty far into the guts of the CNDriver code and were running CNDriverNoLeaching, with a ton of CN specific code that it really doesn't need to.

I think the main thing that FATES needs to do is the following tidbit (and a little bit of code for X_products_inst before this).

    if(use_fates_bgc) then
          call clm_fates%wrap_WoodProducts(bounds, num_bgc_soilc, filter_bgc_soilc, c_products_inst, n_products_inst)
    end if

The problems with this are that it makes the code more confusing than it needs to, it's running code it doesn't need to which wastes resources, it makes it unclear about what code is actually needed to run FATES, and make refactoring the high level calling structures harder to do.

One way to assess the complexity is to do the following search for uses of use_fates in if statements in the code:

git grep -w use_fates | grep -w if | grep -v utils | wc

which shows over a hundred instances. But, since there's code that's being exercised that doesn't need to be that means there needs to be even more. Or we need some refactoring to make the high level logic easier to follow, and remove the need to have use_fates deeply nested far down in the calling tree.