Unexpected large jumps in harvest

[kjetilaas]

Describe the issue

While analyzing the Trendy runs from CLM-FATES I found some suspicious large jumps in the harvest fields. These are seen across experiments, not just when transient land-use is turned on (S3). Below is a screen shot of some selected points that exhibit this in S0 (reference case with constant climate, CO2 and harvest rates).

I noticed that FATES_DISTURBANCE_RATE_LOGGING shows a large spike at the same times (up to 5-6 m2/m2/yr in the monthly data, which match a ~50% drop in LAI and cVeg), but FATES_MORTALITY_LOGGING_SZ does not snow similar spikes in any of the size classes (here for 3 sites in Norway that shows this behavior during the same decade in S3):

I cannot see anything in the LU forcing file that should give this spike at these times.

@ckoven, do you see similar behavior in your ELM-FATES runs? And do you have any ideas where this might come from?

Relevant log output

FATES tag

sci.1.85.1_api.40.0.0_noresm_v3

Host land model tag

ctsm5.3.045_noresm_v10

Machine

other HLM supported machine

Other supported machine name

betzy

Additional context

No response

[ckoven]

Hi @kjetilaas I will look into this in my simulations. One thing that I should say I've been slightly worried about, and which might be responsible here, is the behavior of the logging logic around secondary young vs secondary mature forest. If the forcing data logging rates exceed what is available in either category for a given gridcell, then it gets capped, meaning there will be less logging than the forcing data says there should be. Under such a case there should probably be additional logging of other secondary patches (e.g., additional logging on secondary young patches if there isn't enough secondary mature patch area to meet the logging demands), but FATES doesn't currently do that. Again, I don't know that this is what is going on, but it seems like that might plausibly generate the pattern you are showing, if the forcing data wants to log a lot of secondary mature patches, but there isn't any, so that once the oldest patch crosses past the age threshold then it suddenly increases the logging rate?

[kjetilaas]

Thanks, @ckoven! That makes sense. Is it then possible that a large harvest rate for mature forest could spill over to young forests? Since crossing this threshold seems to remove a very large fraction of the total biomass in the grid cell. (I can try to figure this out myself also, but just checking if you would know this from the top of your head).

[ckoven]

Hi @kjetilaas, no it currently won't spill over from young to old (or vice versa), but I think we should possibly allow it to, so as to maintain a constant total harvest rate.

[kjetilaas]

Update on this bug:
I have traced this down to what seems to be inconsistent ages here, where somehow it is possible to get secondary_young_fraction=1 and secondary_age .lt. secondary_age_threshold. I havne't understood how this happens, but from printing out the values at the end of LoggingMortality_frac I get values like:

secondary_young_fraction = 1.00000000000000
secondary_age = 97.2661819815219
hlm_harvest_rates(:) = 4.191960729288534E-004 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 000000000000000E+000
harvest_rate = 1.00000000000000

This results in denominator being zero and harvest rate being set to 1, even though the HLM harvest rates are small.

I have confirmed this by adding and extra check that secondary_young_fraction<0.99 in L496, so that it reads:
if (secondary_age .lt. secondary_age_threshold .or. secondary_young_fraction .gt. 0.99_r8) then

With this hack, don't get the sudden, large harvest spikes. (Not a permanent solution, of course, but a confirmation that this is indeed the issue). Not sure exactly how to go forward from here...

@JessicaNeedham, @rosiealice, @ckoven

[JessicaNeedham]

Is it possible this is caused by a mismatch between patch age and patch age since anthropogenic disturbance? The get_secondary_young_frac is using patch%age to get the secondary young fraction

fates/main/EDTypesMod.F90

Line 851 in 3b58472

if ( currentPatch%age .ge. secondary_age_threshold ) then

But then get_harvest_rate_area is using age_since_anthro_disturbance to determine if any patches are over the age threshold. Set here:

fates/biogeochem/EDPatchDynamicsMod.F90

Line 271 in 3b58472

currentPatch%age_since_anthro_disturbance, &

- since LoggingMortality_frac calls get_harvest_rate_area. If patch age is under the young threshold but age_since_anthro_disturbance is over it then secondary_young_frac would be 1 but secondary age would be over the age threshold triggering your bug. Could this happen if there as been a natural disturbance which has reset patch age in the time since there was an anthropogenic disturbance?

[sshu88]

Hi @JessicaNeedham . Agreed. In calculations related to wood harvest we use age_since_anthro_disturbance.

[JessicaNeedham]

My quick test changing age to age_since_anthro_disturbance in the get_secondary_young_frac function seems to have fixed this problem but would be great if you could confirm that it is fixed for you too @kjetilaas

[kjetilaas]

Will do!

[ckoven]

Thanks @JessicaNeedham for figuring this out! I still think we may need to better handle the case when there is insufficient young or old secondary area to harvest what is requested, but perhaps that is a separate issue from this.

[JessicaNeedham]

@ckoven yes it would be good to also update that logic. But I agree it might be best to get this fix in first once we've confirmed it definitely fixes the bug.