[Nomad FR]: Problems with short-term projections, i.e., a few hours

[Den-Boychuk]

Contact Details

GitHub @Den-Boychuk

What is needed?

Issue and background

• Short-term projections are available in Nomad, but are problematic because of how FireSTARR compensates for FBP overprediction
• The usual field practise for overprediction is to deterministically zero out ROS outside peak burn hours and/or when indices are below specified values
• In contrast, FireSTARR compensates by “randomly” zeroing ROS during individual hours throughout the day
  • The approach came from McAlpine’s conceptual “spread event” model and Podur and Wotton’s statistical “spread event” model, which regressed probability of satellite hotspot detection against indices and FBP intensity
  • FireSTARR zeros out ROS if a uniform random number is below a threshold, which is a function of indices
    • ROS is unlikely to be zeroed out when indices are high-extreme
    • ROS is usually but not always zeroed out overnight
• Podur and Wotton’s statistical model has a 1-day time resolution, while FireSTARR has a 1-h time resolution
  • A justification of intra-day randomization is that wind speed and gustiness are more variable in the world than implied by FWI87’s daily wind speed reading
• FireSTARR’s fire growth over 24 h therefore depends on 24 random draws resampled over many simulations, so the resulting burn probability map is “smooth”
  • In contrast, a 2-h projection will have only 2 random draws
  • The ROS will be either zero or FBP during each hour, no matter how many simulations, so the probability map can’t be “smooth”: (FBP, FBP), (FBP, 0), (0, FBP), (0, 0)

Recommendation

• Consider whether a non-smooth burn probability map is a problem, and if so, whether to prevent, discourage, or warn about short-term projections
• Note that a fire reported at 2200h will have a non-smooth burn probability map for Day 1, i.e., 2200h to midnight

How will this improve the project or tool?

• Short-term projections have “non-smooth” burn probability maps
• Removing the feature avoids the issue
• Keeping the feature may be okay if there is a warning

[emdiaz0031]

@Den-Boychuk are you suggesting changes to Firestar? If so, it should be ask to appropriate project.

@Den-Boychuk how do you envision these changes in the workflow of the application? Would a hard minimum of 24 hours satisfy your concerns?

[Den-Boychuk]

@emdiaz0031 I'm not suggesting changes to FireSTARR, that is, changes to the hourly time step for stochastically turning off the ROS.

@emdiaz0031 I'm not qualified to comment on operational workflow. I think this issue requires discussion among FBANs, @jordan-evens, and me. Statistically speaking, the more hours in the simulation, the better the estimate and the smoother the burn probability map. There is no clear threshold between bad and good. I would like us to see the effect of some test cases.

I see from the current UI that the user can pick a duration of 1 hour. That may be realistic operational question, but the burn probability map would be unusual. I don't know a hard or suggested minimum, but I would guess it would be in the neighbourhood of 4-6 hours, not 24. Remember that a simulation can be started at 2355, and it will run 4ish min, to 2359ish.

A possible problem is that FireSTARR may not run a fire for an integer number of hours. It may run from the start time up to the end of a certain hour, or only to 2359ish. I'd need to confer with @jordan-evens or study the code.

[Den-Boychuk]

@emdiaz0031 oh, you may mean internal workflow of the application, rather than the users' workflow. If so, I imagine that a hard minimum could be enforced by the duration slider. A soft, cautionary minimum could be something like a warning message about the burn probability map being "non-smooth" or such. Again, this needs discussion after we look at some test cases.

[emdiaz0031]

The team has discussed to change the slider resolution to 1 day default is 3 days. Adding tooltip once you appear on the danger zone.