site%rxfire_area_f* variables never initialized

[samsrabin]

These site variables:

fates/main/EDTypesMod.F90

Lines 458 to 460 in 27a5b40

	real(r8) :: rxfire_area_fuel ! daily total burnable area [m2] when burn window present and fuel condition met
	real(r8) :: rxfire_area_fi ! daily total burnable area [m2] when burn window present, fuel and fire intensity condition met
	real(r8) :: rxfire_area_final ! daily total burnable area [m2] when all conditions met

are not initialized in EdInitMod. That's not necessarily a problem for rxfire_area_final, since it's set to zero at the beginning of CalculateRxFireAreaBurnt(). However, the other two variables are seemingly a different story. They are calculated in CalculateSurfaceFireIntensity() like so:

fates/fire/SFMainMod.F90

Lines 409 to 412 in 27a5b40

	if (currentSite%fireWeather%rx_flag == itrue .and. rxfire_fuel_check) then
	! record burnable area after fuel load check
	currentSite%rxfire_area_fuel = currentSite%rxfire_area_fuel + currentPatch%area

fates/fire/SFMainMod.F90

Lines 419 to 420 in 27a5b40

	if (is_rxfire) then
	currentSite%rxfire_area_fi = currentSite%rxfire_area_fi + currentPatch%area ! record burnable area after FI check

But they are never set to zero. I would think they'd need to be set to zero at the top of CalculateSurfaceFireIntensity() in order for those accumulations to make sense.

But then looking at results from FATES baselines of ERS_Ld60.f45_f45_mg37.I2000Clm60FatesRs.derecho_intel.clm-FatesColdManagedFire, I see they're all zero. How? Is it just luck? Because during my edge flammability work I'm suddenly getting numbers like this in SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdSatPhen for no apparent reason, where in canonical FATES they're all zero:

 FATES_RXFIRE_BURNABLE_FI = 7.47696422132747e+243 ;

 FATES_RXFIRE_BURNABLE_FINAL = 7.28299721731371e+219 ;

 FATES_RXFIRE_BURNABLE_FUEL = 3.2052447740124e-84 ;

Those diffs gets resolved if I set the site variables to 0 in zero_site().

CC @XiulinGao

[XiulinGao]

@samsrabin I agree that these should be initialized to zero before any accumulation happens. I'm not sure why you see zeros. Did baseline simulations turn off rxfire? Those non-zero values look huge to me, not making sense. As all the three history variables are mean to be in fractional area. Seems to me those non-zero values are randomely generated?

[samsrabin]

@XiulinGao They might all be zeros in the ERS_Ld60.f45_f45_mg37.I2000Clm60FatesRs.derecho_intel.clm-FatesColdManagedFire because it's a cold start test that only goes 60 days, so there's not enough time to accumulate the fuel needed to burn.

The seemingly random very large or small numbers in the other test are because the variables are never initialized, so they're just garbage data created when they're instantiated.

[samsrabin]

@XiulinGao You probably have some runs you do for scientific applications with managed fire on, right? Do you get reasonable outputs for those variables?

[XiulinGao]

@samsrabin that makes sense! Good question. I created these history outputs mainly for diagnosing what factor drives the occurrence of Rx fire in my system, which always tend to be fire intensity check. The numbers I was getting always seem reasonable to me as I'm actually on a different branch (that was much older) where I actually did initialize those to zero...
https://github.com/XiulinGao/fates/blob/11a90bbe23d148033347509f2b5f0219f48e1f48/fire/SFMainMod.F90#L1026-L1027

I cannot recall why this is dropped when merge into main. We should just add this back

[samsrabin]

Sounds good, I'll do that. Thanks!