Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active crown fire (Scott & Reinhardt 2001) #857

Draft
wants to merge 104 commits into
base: main
Choose a base branch
from

Conversation

slevis-lmwg
Copy link
Contributor

Description:

This PR follows in the footsteps of
#573
#572
jkshuman#5
https://github.com/jkshuman/fates/tree/active_crown_Scott_2001
in getting the FATES fire module closer to having an active crown fire parameterization.

Collaborators:

@jkshuman @lmkueppers @pollybuotte @ckoven @glemieux

Expectation of Answer Changes:

At least when fates_fire_active_crown_fire = 1 and active crown fires do occur.

Checklist:

  • My change requires a change to the documentation.
  • I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
  • I have read the CONTRIBUTING document.
  • FATES PASS/FAIL regression tests were run
  • If answers were expected to change, evaluation was performed and provided

Test Results:

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag:

FATES baseline hash-tag:

Test Output:

Jacquelyn Shuman and others added 30 commits September 4, 2019 16:06
Add EQ to evaluate potential for crown fire
Add EQ for passive crown fire igntion
Set fraction of crown burnt based on this conditional
Add crown fire threshold, crown fire flag, and crown fire PFT param
Following @jkshuman's introduction of the Bessie and Johnson (1995)
formulation for determining the presence of passive crown fire
(NGEET#572),
I now add the same paper's formulation for determining the presence of
active crown fire.

The corresponding issue is NGEET#573
Co-Authored-By: Samuel Levis <[email protected]>
…active_crown_fire

Resolved conflicts in
 	fire/SFMainMod.F90
…active_crown_fire

Resolved Conflicts:
 	main/EDTypesMod.F90
max_height = 0._r8
biom_matrix(:) = 0._r8

! if (currentPatch%active_crown_fire == 1) then
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkshuman I see your comment here. I'm not putting the if-statement here because it will prevent passive_crown_FI from becoming greater than 0 when we run without active crown fire.

I am adding the if-statement later, after the comment
! check threshold intensity and rate of spread
That's the only place where I think this if-statement is required.

@@ -62,7 +62,7 @@ module EDParamsMod
real(r8),protected, public :: ED_val_canopy_closure_thresh ! site-level canopy closure point where trees take on forest (narrow) versus savannah (wide) crown allometry
integer,protected, public :: stomatal_model !switch for choosing between stomatal conductance models, 1 for Ball-Berry, 2 for Medlyn

logical,protected, public :: active_crown_fire ! flag, 1=active crown fire 0=no active crown fire
logical,protected, public :: active_crown_fire_switch ! flag, 1=active crown fire 0=no active crown fire
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added suffix _switch to prevent compiler error that complained about same name as subroutine active_crown_fire.

@slevis-lmwg
Copy link
Contributor Author

I haven't worked on this PR this week due to other priorities. I expect to get back to it next week.

As far as I can tell these variables need to be currentPatch% variables:
canopy_fuel_load
passive_crown_FI
heat_per_area
ros_torch
lb
!evaluates if there will be an active crown fire based on canopy fuel and rate of spread
!returns final rate of spread and fire intensity in patch with added fuel from active crown fire.
!currentCohort%fraction_crown_burned is the proportion of crown affected by fire
! TODO slevis: Jackie, you had ROS_torch coming in here but not used
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This far, the test
SMS_Lm12_D_Mmpi-serial.1x1_brazil.I2000Clm50FatesCruRsGs.izumi_intel.clm-FatesFireLightningPopDens
returns identical answers when I set
fates_fire_active_crown_fire = 1 in the params file, as when I set
fates_fire_active_crown_fire = 0

@jkshuman before I begin investigating (site too wet? no lightning? maybe it's time to switch to the site that @pollybuotte is running), I wanted to ask you about two variables:

  • You had ROS_torch entering subroutine active_crown_fire but not used.
  • You also had canopy_bulk_denisty calculated but not used.

Had you intended to use these variables? If so, where? If the answer is in S&R (2001), feel free to refer me there.

By the way, I stopped passing ROS_torch and four other variables as subroutine arguments, because my sense was that they wouldn't work as scalars and needed to be currentPatch% variables.

Copy link
Contributor

@jkshuman jkshuman May 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting indeed you are correct those should be Patch variables. I thought that I had a mistake in implementation there, but didn't get around to fixing it. also, yes ROS_torch is not necessary. Might be an informative calculation, but indeed it is not used. Let me remind myself what is going on with canopy_bulk_density.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting canopy_bulk_density can be removed. it is no longer used.

phi_wind_ROS_SA = (ROS_active_min * fuel_bd * eps * q_ig - 3.34 * ir * xi) / (3.34 * ir * xi)
else
phi_wind_ROS_SA = 0._r8
end if
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkshuman running this by you:
I was getting phi_wind_ROS_SA = infinity due to ir = 0, which was due to moist_damp = 0. I added this if statement to confirm that ir > 0 .and. xi > 0.
Question 1: Did I make the right choice for the else?

This change caused canopy_frac_burnt < 0 a few lines down due to ROS_SA = 0. So I added max(0... to the calculation of canopy_frac_burnt.
Question 2: Does that seem reasonable?

I have now completed a 5 yr simulation at the CZ2 site. I will share some figures here on github to initiate discussion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just saw your message about other updates @jkshuman
I will try those out before posting figures. Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkshuman
in the context of your latest modifications, I'm keeping the if statement and the max(0... that I talked about above, because they still seem relevant when moist_damp = 0 and ROS_SA = 0.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting normally I would say yes, sounds good, but there must be something more going on in here. you are in this section because the patchFI >= passive_crown_FI indicating there is a fire. And then we are calculating the pieces to get the reaction intensity "ir" for the active crown fire using a given fuel loading for the FM 10 model. It would seem that I have a mistake in this section prior to calculating "ir". I am looking it over now. I belive it is a conversion error. Let me make an adjustment.

@slevis-lmwg
Copy link
Contributor Author

I still get identical results in the runs with and without active_crown_fire = .true.
I think this means that
ROS_active never becomes greater than or equal to ROS_active_min
or
moist_damp never exceeds 0
(or both)

I will investigate further tomorrow. Meanwhile here are plots from the 5-yr run:
burned_frac_and_drought_status

@slevis-lmwg
Copy link
Contributor Author

slevis-lmwg commented May 6, 2022

I have confirmed my previous statement. More precisely:
moist_damp for the crown doesn't exceed 0 and, as a result, ROS_active doesn't exceed 0 in the 5-yr run.
The latter means no active crown fire in the 5-yr run.
The former means also no passive crown fire in the 5-yr run.

Sample values from year 2 (see plots above) during the fire season:

Surface fuel

moist_damp mw_weight fuel_eff_moist fuel_mef
0.55 0.48 0.25 0.52

Crown fuel

moist_damp mw_weight fuel_eff_moist fuel_mef
0 1.92 0.48 0.25

where mw_weight = fuel_eff_moist / fuel_mef
and moist_damp > 0 for mw_weight < 1

@jkshuman I'm sharing all this in case something stands out as strange. To me things look reasonable for now.

@jkshuman
Copy link
Contributor

jkshuman commented May 6, 2022

@slevisconsulting I pushed a set of conversions for the FM10 fuels to your branch. Can you test again to see if you still get ir = 0 due to moist damp = 0?

ROS_active = 3.34_r8 * ((ir*xi*(1.0_r8+phi_wind)) / (fuel_bd * eps * q_ig))

! critical min rate of spread (m/min) for active crowning
ROS_active_min = (critical_mass_flow_rate / fuel_bd) * 60.0_r8

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkshuman is this using the correct equation? To me it looks like it's supposed to be calculating the critical minimum rate of spread for active crowning, which is Eq 14 in Scott & Reinhardt. But this line corresponds to Eq 12, which is for calculating the rate of spread for initiation.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @jkshuman I see I was getting variable names mixed up and that ROS_active_min is the Scott and Reinhardt R'initiation. You can ignore my previous comment.

@slevis-lmwg
Copy link
Contributor Author

Can you test again to see if you still get ir = 0 due to moist damp = 0?

Good news @jkshuman
I now see canopy_frac_burnt > 0 though always < 1 (in the two yrs of simulation). This means that we do not cross our active crown fire threshold in these two yrs, which seems fine, do you agree?

@jkshuman
Copy link
Contributor

jkshuman commented May 7, 2022

@slevisconsulting that's great news! so now the race to active crown fire begins.
With these where canopy_frac_burnt > 0 but < 1 there is some canopy burnt, and it alters the FI. Check Patch%FI before canopy burning, FI_final which updates Patch%FI after adjusting for potential canopy fuel consumed. A similar update should happen to patch%ROS_front, and that should be checked as well to confirm it actually changes with canopy consumption.

currentPatch%canopy_fuel_load * canopy_ignite_energy * canopy_frac_burnt) * &
currentPatch%ROS_front / 60._r8
! update patch FI to adjust according to potential canopy fuel consumed (passive and active)
currentPatch%FI = FI_final
Copy link
Contributor Author

@slevis-lmwg slevis-lmwg May 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[...] there is some canopy burnt, and it alters the FI. Check Patch%FI before canopy burning, FI_final which updates Patch%FI after adjusting for potential canopy fuel consumed. A similar update should happen to patch%ROS_front, and that should be checked as well to confirm it actually changes with canopy consumption.

@jkshuman thank you for the suggestion. I checked and, before the update of ROS_front and FI, I sometimes find ROS_final < ROS_front and FI_final < FI. Would you agree that we shouldn't update to reduce ROS_front and FI in those cases? If so, how about:

Suggested change
currentPatch%FI = FI_final
if (FI_final > currentPatch%FI) then
currentPatch%FI = FI_final
end if

...and similar for ROS_front a few lines up.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting sounds good.

@slevis-lmwg
Copy link
Contributor Author

@jkshuman anything additional that you recommend I check in my quick 2-yr tests at CZ2? Otherwise I may submit a multi-yr simulation to see if conditions cross the active crown fire threshold at some point, i.e.:
ROS_active >= ROS_active_min

@slevis-lmwg
Copy link
Contributor Author

Two 20-yr simulations ran on izumi, one with fates_fire_active_crown_fire = 1 and the other with fates_fire_active_crown_fire = 0. See history output here:

  • /scratch/cluster/slevis/archive/CZ2_acf_on/lnd/hist
  • /scratch/cluster/slevis/archive/CZ2_acf_off/lnd/hist

Case directories here (always on izumi):

  • /home/slevis/cases_FATES/CZ2_acf_on
  • /home/slevis/cases_FATES/CZ2_acf_off

The first simulation (CZ2_acf_on) satisfies the active crown fire requirement at times, so the outcomes from the two simulations differ. I am happy to perform additional testing or to hand over to @jkshuman and @pollybuotte .

@jkshuman
Copy link
Contributor

Thanks for your work on this @slevisconsulting Will keep you posted if there are other things that come up.

FATES_FUEL_AMOUNT_APFC and FATES_MORTALITY_FIRE_SZPF
Other fields that Polly requested were active already
@rgknox rgknox added the PR status: Not Ready The author is signaling that this PR is a work in progress and not ready for integration. label Nov 14, 2022
@adrifoster adrifoster mentioned this pull request Oct 26, 2023
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR status: Not Ready The author is signaling that this PR is a work in progress and not ready for integration.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants