[WISE FR]: Wind Gusting

[RobBryce]

Contact Details

rbryce@heartlandsoftware.ca

What is needed?

Cordy Tymstra's Ph.D. work included adjustments to the FBP standard to incorporate wind gusts, which are typically reported by our weather prediction models.

How will this improve the project or tool?

Possibly improve accuracy of simjulation outputs.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[spydmobile]

Is this work ratified by Mike Wotton or any one else involved with administration of the FWI/FBP system?

[spydmobile]

Another way to ask that would be to say, if we implement this work, will we be the only ones using it, and therefore have different foundations from everyone else? if so should it be an optional component?

[RobBryce]

Mike Flannigan was Cordy's supervisor. I don't know who was on his supervisory committee. I consider this along the lines of John Braun's work to define percentiles of rate of growth for specific fuel types. That has been incorporated, though I don't know who has used it. For now, we could just gather wind gusts and hang onto that data for the fall's analysis work. It won't cost much to gather and store that data. Also, as Cordy described it, it shouldn't take much to incorporate either.

[spydmobile]

After this week I am 100% into looking into this idea, or otherwise to try and implement the crazy idea Brett and I cooked up.

[BadgerOnABike]

Had a conversation with @thompsdk and gusting is not currently a part of the FBP 2.0 structure, but I don't think that precludes us from having a way of introducing intermittently high winds that only influence the FBP ISI.

How long does a gust last? I don't know, but I know it's roughly a part of the average wind so we may need to do some fun math to adjust for that.

[spydmobile]

Whereas Cordy does not have a good solution to offer [Beyond the idea of preprocessing weather and recalculating the windspeed as newWindSpeed = (windspeed + gust)/2] I would like to put forth the following idea which has been kicked about by Myself & Rob (originally) with more discussion and ideas with Brett:

ADD ORDINAL TIMESTEP GUST PER SCENARIO FEATURE

1) Expose the gust variable to the weather engine (it is not currently) 2) Add a switch (Enable Gust Logic for Scenario) and expose it to the API 3) Add a Gust Ordinal Variable (Gust Frequency For Scenario) and Expose it to the modelling engine (via weather engine) and Expose it to the API 4) When doing each time step check if it hit an ordinal, when hitting the ordinal do the timestep calculations using the GUST speed instead of the WIND speed. This would result in every Nth (use Ordinal Value here) timestep of each weather hour being Gust and the rest using Wind. This would then in turn cause the timestep to burn with a higher ISI and subsequently a higher ROS.

Think of the ordinal as: Every N timesteps use gust instead of wind

Ordinals (whole numbers): 0 - Would be 0% Gust 1 - Would be 100% gust 2 - Would be 50% Gust 3 - Would be ~33% Gust 4 - Would be 25% Gust 5 - Would be 20% Gust 6 - Would be ~16% Gust 7 - Would be ~7% Gust 8 - would be ~1.3% Gust 9 - would be ~1.1% Gust 10 - Would be 1% Gust

ASSUMPTION (Weakness) since we have no control over number or length of timesteps, we are at the mercy of the speed of the fire, as a slow moving fire will have less TS/WeatherHour and in some cases a timestep may be more than 1 hour, or just under in which case no gust would be applied.

[spydmobile]

From Cordy this morning.....

Hi Franco,

I see NT still has active fires...amazing!

Rob Bryce mentioned that gusts are contributing to wildfire growth in NT...but it is difficult to incorporate gusts in modeling.

I converted the 10-min average wind speed to a probable maximum 1-min average wind speed and recalculated the FFMC and ISI using the adjusted wind speed. See attached paper. Ideally, you should be using data specific to your conditions (and area) i.e., how strong are the gusts and what is their duration. Weather stations can collect this data but it typically is not archived.

It always surprised me that the Advanced Fire Behaviour Course and Wildfire Behaviour Specialist Course did not address gusts and how to incorporate gusts in fire behaviour forecasts. FBANs are on their own to make whatever wind adjustments they think are needed to align forecast outputs with observations.

Are you attending the Wildland Fire Canada Conference in Edmonton?

Cordy WF21045.pdf

[BadgerOnABike]

@jordan-evens Do you have any thoughts on this. Thinking about the hourly calcs you did. I'll also bug Ginny on this as she did a lot of turbulence work in her MSc Thesis.

[RobBryce]

@spydmobile - another idea would be to randomly apply gusting in a timestep to a set of vertices. So that (e.g.) 60% of the vertices on a given timestep would receive gusting, the others would not. This would remove a bias that isn't controllable by way of time step duration.

Another option would to force the weather stream to generate events to toggle between gusting and not gusting, on intervals/durations it sees fit. This would require no modification to the propagation engine, and would properly deal with separation of concerns - gusting is handled by the weather stream and nothing else. This could be a variaton/extension to the sub-hourly temporal interpolation that still exists. The rest of the work would actually fall into place without modifications, including adjustments for WS through wind grids too. Unknown how it would adjust the FWI codes during gusting, and then not, unless we tweak the sub-hourly FWI calculations to consider when it's gusting and not.

[thompsdk]

Just to weigh in there, Cordy's excellent paper there leverages from 1966 USFS work (reprinted in 2004 and cited as Crosby, J. S., and C. C. Chandler. 2004) that's based on measurements from a single site in Missouri: https://www.frames.gov/catalog/41216. The overall concept seems totally solid, but if you are going to throw a new interpretation of gusting into a fire spread model, I agree with @BadgerOnABike that some thorough discussions with proper meteorologists (and I'm far from one myself, but Ginny is) are required, they have a really good mathematical concept of turbulence that's been developed since 1966 that would be a good check on Cordy's scheme. Any scheme used here should roughly correspond to a gusting multiplier that you would get when you put gusts into a fire physics model like FIRETEC/QUIC-fire (plug for our Oct 31 workshop in Edmonton on it :). @RobBryce I like the concept of handling gusting purely within the weather stream, but indeed, applying the gust to the entire fire is a problem, so it would have to be some random subset of the fire front. No trivial problem!

[BadgerOnABike]

Whereas Cordy does not have a good solution to offer [Beyond the idea of preprocessing weather and recalculating the windspeed as newWindSpeed = (windspeed + gust)/2] I would like to put forth the following idea which has been kicked about by Myself & Rob (originally) with more discussion and ideas with Brett:

ADD ORDINAL TIMESTEP GUST PER SCENARIO FEATURE

1. Expose the gust variable to the weather engine (it is not currently)
2. Add a switch (Enable Gust Logic for Scenario) and expose it to the API
3. Add a Gust Ordinal Variable (Gust Frequency For Scenario) and Expose it to the modelling engine (via weather engine) and Expose it to the API
4. When doing each time step check if it hit an ordinal, when hitting the ordinal do the timestep calculations using the GUST speed instead of the WIND speed. This would result in every Nth (use Ordinal Value here) timestep of each weather hour being Gust and the rest using Wind. This would then in turn cause the timestep to burn with a higher ISI and subsequently a higher ROS.

Think of the ordinal as: Every N timesteps use gust instead of wind

Ordinals (whole numbers): 0 - Would be 0% Gust 1 - Would be 100% gust 2 - Would be 50% Gust 3 - Would be ~33% Gust 4 - Would be 25% Gust 5 - Would be 20% Gust 6 - Would be ~16% Gust 7 - Would be ~7% Gust 8 - would be ~1.3% Gust 9 - would be ~1.1% Gust 10 - Would be 1% Gust

ASSUMPTION (Weakness) since we have no control over number or length of timesteps, we are at the mercy of the speed of the fire, as a slow moving fire will have less TS/WeatherHour and in some cases a timestep may be more than 1 hour, or just under in which case no gust would be applied.

How hard would it be to just try this to begin with?

At least then we have a lever to pull to push some "better wind" until we can quantify better wind.

[spydmobile]

I am in favour of stubbing in one of these ideas as an experimental feature, maybe it never hits production, and for the long term conversations with folks smarter than Us for a long term solution.

[RobBryce]

The weather model introduces events to the fire growth model already. It has to on every hour for new weather (and this was generalized for future considerations for sub-hourly weather - supplied or calculated from diurnal curves). So this approach doesn't have to be at the mercy (so to say) of what the calculation engine determines as a time step duration.

I thought I understood your ordinals but your latter examples (7,8,9,10) don't make sense to me. I'd just ask for a percentage.

If you want to introduce events, then we have to look at duration between gusts and duration of gusts, which together would define your percentage and your ordinal.

Not all weather models provide gusting, so these options would only be valid where the data is available. I doubt you'd want this has a hard fail, just a warning of unavailable data.

[spydmobile]

I thought I understood your ordinals but your latter examples (7,8,9,10) don't make sense to me. I'd just ask for a percentage.

7 - Would be ~1.4% Gust every 7th timestep would be roughly 1.4% of the time 8 - would be ~1.3% Gust every 8th timestep (1 of 8 = 1/8 = 0.125) would be roughly 1.3% of the time 9 - would be ~1.1% Gust 10 - Would be 1% Gust

My math sucks LOL but the idea did not.

I originally provided ordinals because using a percentage to decide to use WIND or GUST for the timestep is computationally more expensive (Actual math calculation and floating points is involved) than simply checking the indexed ordinal of the current timestep counter. In my mind all the extra math would add up to a slower calculation of timestep outputs, so I designed the whole Idea to work on an ordinal, which is simply incremented++ which is way faster that determining the current timestep input by a percentage. Or so I thought....

[thompsdk]

I am in favour of stubbing in one of these ideas as an experimental feature, maybe it never hits production, and for the long term conversations with folks smarter than Us for a long term solution.

That's a great strategy, Franco. I can confirm that there won't be a specific gusting feature in some of the FWI revisions/updates we are rolling out early next year (not saying it won't feature into the FBP), but keeping an experimental feature here for future development seems like a great idea.

[RobBryce]

In discussions with Franco, we'll propose taking an approach where we can evaluate changes and functionality and walk before we run. 1.) default gusting is no gusting, which will also act as a baseline 2.) initial implementation and continued option will be Cordy's approach to simply average gusting with mean wind speed. 3.) next approach will be a deterministic gusting which requires 2 parameters: a.) %-age of an hour that gusting will occur (e.g. 25% means 15 minutes per hour will have gusting speed), and b.) frequency of gusting in the hour, so if you say 5, then there will be gusting every 60/5=12 minutes, and with 25% that means in every 12 minute period you'll get 3 minutes of gusting, and the period at which this occurs will be repeatable and deterministic 4.) next approach (for now) will be Franco's approach to gusting which will be deterministic not based on frequency but based on behaviour of the model to date. It will look at the current time step duration and remaining period of the hour, and then scale the amount of the time period between mean ws and gusting, to achieve the %-age per hour gusting that's desired

These 4 modes can be then be compared against past seasonal data for effectiveness, and decide what to do from there.

[RobBryce]

The initial plan (for now) is as follows: 1.) extend the wx stream import and export routines to load and save gusting information, which means more header information 2.) extend the weather object to store gusting information, also the weather object proto definition 3.) extend stat's file formats to report gusting information (e.g. stat's view output, scenario report output) 4.) extend the protobuf definition to allow for specification of mode for gusting at the scenario level (not wx stream level - so it's consistent even with multiple wx streams and spatial wx modelling) 5.) originally I wanted to put this logic into the wx stream object, I've reconsidered. streams should only feed weather data, nothing more, so instead the logic to adjust the time step, when to adjust the time step, and how to handle ws and gusting will be in the simulation/scenario object. This way there's no propagation model logic in the weather object a.) options 3, 4 will introduce logic that adjust internal time step calculations, which could have been done in the weather stream object, but will now be in the scenario object

This is exploratory work so the pending estimate will be based on this approach, and if we uncover unforseen difficulties, or new ideas, that will be discussed and adjusted here as development proceeds.

[RobBryce]

This work also means possible additions to weather patches and code dealing with wind grids.

[RobBryce]

Some time ago, we introduced a mode where multiple fires in a simulation would model independently until they are close to each other. It would seem that the 4th approach here may be mutually exclusive to letting fires model independently. This may need some discussion.

[spydmobile]

@RobBryce the work-plan should not be altered after it is approved otherwise it has to go back to the exec for approval all over again, so your above suggestion should be a new issue and should not confuse the approved work here. (in a rare case where it does not really alter things, or change the quote or bill, then this might be ok, but not this time.)

[spydmobile]

for my algorithm, When 2 fires get close, the fastest fire should should dictate the gust history, if that gust history does not meet the minimum, then makeup the difference so that this hour gets its full gusting, then move on.

as to how to distribute the gusting, please prioritize the gust over the non-gust and distribute that gusting scaled to the speed of the fire eg fast fire more frequent smaller gusts distributed across the timeframe.

[nealmcloughlin]

@spydmobile Some interesting nuisances to consider here (potentially for a future ticket). Several years ago we encountered examples where modelling a fire independently created a different output compared to modelling it as part of a multi-fire scenario. We resolved the issue with the mode @RobBryce mentioned to model multiple fires in the same scenario independently until they touch. I'm curious as to how the fastest fire will be identified. I'm waking up old brain cells here. If memory service me correct, I remember talking about logic to look for which fire started first. If both fires started at the same time, then look for which fire is larger. Rates of spread are instantaneous and spatially explicit calculations. There is no single metric for comparing the overall speed of one fire against another.

[RobBryce]

@nealmcloughlin - @spydmobile 's comment was after a few hours of hashing over what to do as 2 fires approach. Since the fires are (optionally) running completely independent of each other, it's conceivable that during the hour that they meet in, that one fire will receive more gusting than the other. Once they are synchronized, it's not a problem. Before they are synchronized, in theory they should have the same amount of gusting per hour but at different times. During that one hour of time when they meet, no guarantees of consistency.

[RobBryce]

@nealmcloughlin - what you were likely thinking of is which fire claims the overlap area between 2 fires when they meet - the larger fire always wins.

[RobBryce]

@nealmcloughlin - we also spent some time discussing the event driven approach where time steps shorter than we calculate must still resample the landscape to make sure it doesn't mathematically simplify to simply averaging the gusting with the wind speed. However, to statistically keep this from happening less frequently, we'll end up creating a bias towards the start of the hour to let gusting use its allotment per hour faster than slower, so the time steps and thus step sizes are going to help "resample" new data, and thus minimize averaging around the perimeter. This is going to be challenging to implement, then verify.

[nealmcloughlin]

@RobBryce Thanks Rob. That answers my question. Gusting is used to identify the fastest fire, not the simulated rates of spread.

[spydmobile]

Hiya, @nealmcloughlin I dont think so, I could be wrong but I think that the duration of the timestep, which is an indirect derivative of the speed of the fire, is used to assess which fire is faster, but @RobBryce may have to correct me there.

[RobBryce]

The duration of a timestep is defined by the grid resolution and the fastest vertex, then clipped by other events that may occur (new weather, new ignition, etc.) WIth 2 independent fires, the fastest vertex is per fire. When fires are synchronized, it's the fastest vertex of all the synchronized fires. The issue is when the fires have to become synchronized. At this point, we'll use the amount of gusting in the hour of the fastest moving fire, as a basis to make sure we meet gusting objectives for that hour. The slower moving fire will not receive the target gusting for that hour as the fires synchronize.

[spydmobile]

@RobBryce Right, how many times did you say that to me :) fastest vertex wins LOL

[nealmcloughlin]

Got it. Thanks guys.

[RobBryce]

Follow-up with @nealmcloughlin :

• The current gusting implementation does not consider burning conditions, because the wind gusting implementation only affects wind applied to ROS calculations, it is not an input into WS thresholding, or an input into any FWI calc's. This goes back to Rob's conversation with Marty Alexander who said not to modify FWI values to consider wind gusting, just modify the wind speed. Burning conditions could be the threshold on WS, ISI, or HFFMC.
• If gusting is to impact FWI values and/or burning conditions, its consideration needs to be pulled into weather streams and patches, and we need to consider how it works with spatial weather modelling.
• The gusting implementation is sub-hourly, which goes back to the conversations years ago about sub-hourly FFMC calculations, etc. and getting equations to reconverge at the end of each hour.