FATES_NESTEROV_INDEX affected by something other than climate

[samsrabin]

Describe the issue

FATES_NESTEROV_INDEX (aka site%fireWeather%fire_weather_index) should be purely driven by climate. However, a seemingly innocuous code change results in diffs.

Tested with this change:

diff --git a/fire/SFMainMod.F90 b/fire/SFMainMod.F90
index 7e6de332..0070806d 100644
--- a/fire/SFMainMod.F90
+++ b/fire/SFMainMod.F90
@@ -231,7 +231,7 @@ contains
       cloud_to_ground_strikes = 1.0_r8
     else
       ! USING LIGHTNING STRIKE DATA
-      currentSite%FDI  = 1.0_r8 - exp(-SF_val_fdi_alpha*currentSite%fireWeather%fire_weather_index)
+      currentSite%FDI  = 1.0_r8
       cloud_to_ground_strikes = cg_strikes
     end if

 ./run_sys_tests -t SMS_Lm6.f45_f45_mg37.I2000Clm50FatesCruRsGs.derecho_intel.clm-Fates --compare fates-sci.1.87.0_api.41.0.0-ctsm5.3.070 --skip-generate

Results in /glade/derecho/scratch/samrabin/tests_0915-084137de/SMS_Lm6.f45_f45_mg37.I2000Clm50FatesCruRsGs.derecho_intel.clm-Fates.C.0915-084333de/.

Relevant log output

FATES_NESTEROV_INDEX   (lon,lat,time)  t_index =      1     1
         28     3312  (    71,    28,     1) (    33,     2,     1) (    60,    18,     1) (    60,    18,     1)
                1083   1.428564205067366E+05   0.000000000000000E+00 1.1E+00  9.145448505151131E+03 1.2E-07  9.145448505151131E+03
                1083   1.428564205067366E+05   0.000000000000000E+00          9.146533030303199E+03          9.146533030303199E+03
                3312  (    71,    28,     1) (    33,     2,     1)
          avg abs field values:    7.257860608605850E+03    rms diff: 3.3E-02   avg rel diff(npos):  1.2E-07
                                   7.257861703017570E+03                        avg decimal digits(ndif):  8.8 worst:  3.9
 RMS FATES_NESTEROV_INDEX             3.3014E-02            NORMALIZED  4.5487E-06

FATES tag

sci.1.87.0_api.41.0.0

Host land model tag

ctsm5.3.070

Machine

derecho

Other supported machine name

No response

Additional context

No response

[samsrabin]

This is probably due to effects on patch-level tveg24 in UpdateFireWeather():

fates/fire/SFMainMod.F90

Lines 118 to 127 in c1dfc21

	temp_C = currentPatch%tveg24%GetMean() - tfrz
	precip = bc_in%precip24_pa(iofp)*sec_per_day
	rh = bc_in%relhumid24_pa(iofp)
	wind = bc_in%wind24_pa(iofp)
	! convert to m/min
	currentSite%wind = wind*sec_per_min
	! update fire weather index
	call currentSite%fireWeather%UpdateIndex(temp_C, precip, rh, wind)

[ckoven]

This is probably due to effects on patch-level tveg24 in UpdateFireWeather():

fates/fire/SFMainMod.F90

Lines 118 to 127 in c1dfc21

temp_C = currentPatch%tveg24%GetMean() - tfrz
precip = bc_in%precip24_pa(iofp)*sec_per_day
rh = bc_in%relhumid24_pa(iofp)
wind = bc_in%wind24_pa(iofp)

! convert to m/min
currentSite%wind = wind*sec_per_min

! update fire weather index
call currentSite%fireWeather%UpdateIndex(temp_C, precip, rh, wind)

or RH, since anything that affects ET will affect RH?

[samsrabin]

@ckoven:

or RH, since anything that affects ET will affect RH?

I don't think it should, since RH in UpdateFireWeather() comes from bc_in. Am I wrong?

[samsrabin]

@ckoven I just did a test and it looks like RH does somehow vary in bc_in. Do you have any idea how this happens? I can't figure it out.

[ckoven]

@ckoven I just did a test and it looks like RH does somehow vary in bc_in. Do you have any idea how this happens? I can't figure it out.

It should, because the surface temperature and specific humidity that FATES sees as bc_in's are calculated by CLM or ELM, i.e. they are determined by the canopy turbulence model with the DATM-forced values as an upper boundary condition, but also dependent on the albedo, evaporative resistance, etc that FATES is providing. So any change to FATES should in general affect everything, really.

[samsrabin]

I guess I'm confused because I really can't see where that actually happens in CLM. Here is where CLM's rh24_patch variable gets updated (taken from gridcell-level forcing). That's the variable that gets saved as bc_in%relhumid24_pa here. I can't see anywhere else either of those variables are changed. I'm sure I'm just being dense, but could you point me in the right direction?

[ckoven]

OK, sorry, I hadn't realized it was passing a smoothed value of the DATM forcing data, I thought it was the surface values that were passed. I agree then that it is weird that the value changes in response to your change.

[samsrabin]

Ah okay, thanks for confirming. Do you think I should file an issue about this?

[ckoven]

Do you think I should file an issue about this?

maybe just reopen this one?