Potential bug in logging model

[XiulinGao]

fates/biogeochem/EDMortalityFunctionsMod.F90

Lines 332 to 342 in b5d3a13

	call LoggingMortality_frac(currentSite, bc_in, ipft, currentCohort%dbh, currentCohort%canopy_layer, &
	currentCohort%lmort_direct, &
	currentCohort%lmort_collateral, &
	currentCohort%lmort_infra, &
	currentCohort%l_degrad, &
	bc_in%hlm_harvest_rates, &
	bc_in%hlm_harvest_catnames, &
	bc_in%hlm_harvest_units, &
	land_use_label, &
	age_since_anthro_disturbance, &
	current_fates_landuse_state_vector, harvestable_forest_c, harvest_tag)

This call of logging mortality function here uses the calculated cohort level logging resulted mortality and degradation rate as the argument input. However, in the original logging mortality function, logging mortality and degradation rate are defined as output variables. This call here then will change the value. I don't think I understand what Mortality Derivative fun does here, and how that is related to the actual logging mortality applied to cohort to reflect logging effects, and how logging mortality is output as history variable. I indeed see some weird behavior of the logging model on my local branch that when runtime logging direct mortality is non-zero, but the output is zero and there is no logging effect at all. However, this is based on my local branch where I did a targeted logging: only apply logging to certain DBH size with different cap rate for each group and zero logging mortality when a defined patch level total basal area is approached with only degradation rate is preserved.

[XiulinGao]

I think I figured it out why I'm getting a zero mortality rate. And this recall of logging mortality function does not affect the calculated logging mortality. It literally just recalculates the logging mortality for each cohort. But I still cannot understand why we have to recall the logging mortality function here if the purpose is just to use the derived mortality to calculate dndt_logging.

[glemieux]

@ckoven to follow up on this with @XiulinGao.

[JessicaNeedham]

Just noting that I am also seeing a zero logging mortality rate, even when logging is definitely on. Looks like a bug in history reporting of logging mortality, since there are the expected declines in AGB and increases in logging disturbed area.

[JessicaNeedham]

Part of the problem seems to be that cur_harvest_tag is not being initialised. With print statements I get different values with DEBUG on or off.

fates/biogeochem/EDLoggingMortalityMod.F90

Line 241 in d121971

integer :: cur_harvest_tag ! the harvest tag of the cohort today

[XiulinGao]

@JessicaNeedham you are probably experiencing issue #1289 if you are using an older version of FATES.

[JessicaNeedham]

@XiulinGao - I'm on API 39 so pretty up to date. I think this is still an issue although I'm still trying to figure it out. cur_harvest_tag is not being initialised but with debug=FALSE it is defaulting to 0 which just happens to be the value of fates_no_harvest_debt. Here:

fates/main/FatesConstantsMod.F90

Line 159 in d121971

integer, parameter, public :: fates_no_harvest_debt = 0

But sometimes it defaults to a different value and then if we are using the logging parameters it never gets set which means we don't meet the conditions here:

fates/biogeochem/EDLoggingMortalityMod.F90

Line 350 in d121971

if (cur_harvest_tag == fates_no_harvest_debt .or. cur_harvest_tag == fates_bypass_harvest_debt) then

I think although I'm not totally sure yet, that it needs to be initialised to a number not equal to 0,1,2 and then it needs to be set to fates_bypass_harvest_debt around here:

fates/biogeochem/EDLoggingMortalityMod.F90

Line 290 in d121971

harvest_rate = 1._r8

Maybe @sshu88 or @ckoven have more insight?

[sshu88]

Hi @JessicaNeedham . Did you put do_harvest = .true.? I remembered hlm_use_lu_harvest == ifalse flag was planned to be deprecated since the other side of if statement can do the same 100% harvest logics so I actually did not put statement there. Otherwise putting an assignment of harvest_tag = fates_bypass_harvest_debt and cur_harvest_tag = fates_bypass_harvest_debt shall work.

[JessicaNeedham]

Thanks @sshu88, I just set fates_harvest_mode='event_code' since I am trying to simulate a one off logging event, not a time series of harvesting. Updating cur_harvest_tag means lmort_direct is being set correctly by LoggingMortality_frac for event based logging, but it still doesn't seem to be transferred to history correctly.