Arizona. California. Colorado. Canada. Chile. Australia. These are just a few of the places 10 Tanker Air Carrier has fought wildfires over the last...
FWAS: An Early Warning System For Wildland Firefighters
The Yarnell Hill Fire was a lightning-sparked wildfire which killed 19 members of the Granite Mountain Hotshots near Yarnell, Arizona, on June 28, 2013. It went down in the history books as the deadliest wildland fire for U.S. firefighters since the 1933 Griffith Park Fire, and the deadliest wildfire in Arizona’s history.
The burnover which killed the firefighters was caused by an unseen menace: thunderstorm outflow winds.
Jason Forthofer, a Mechanical Engineer who oversees a number of projects at U.S. Forest Service’s Missoula, Montana, Fire Lab, is working on something which could act as an early warning system for wildland firefighters: the Fire Weather Alert System.
“The short description of the Fire Weather Alert System (FWAS) is that it’s a prototype system right now,” explained Forthofer, who works as a Division Supervisor during fire season.
“I started as a firefighter in the summers when I was going to college. I still go out on fires 4-6 weeks a year. The idea for this came to me when I was out on a fire as a firefighter.”
The Legacy of WindNinja
“Because of my work at the Fire Lab as a researcher, and developing the WindNinja wind model, I found myself using my smartphone a lot, going to websites and accessing data while I’m on a fire that’s pretty much inaccessible to other firefighters, because it’s spread out over multiple websites,” Forthofer said.
“It’s technical information on websites that aren’t user-friendly that provides me with more information than I currently have on the fire around me, the current state of the weather and what to expect over the next few hours. Through that experience, I came up with FWAS.”
First and foremost, FWAS was designed to be user-friendly.
“The idea is that, if you go out on a fire, a firefighter can set their location, define a radius around that area, then you tell the FWAS the kind of hazardous weather features that you want it to be looking for. If FWAS sees any of those types of weather, it will send you an alert. After that, they put their phone in their pocket and fight fire.”
And if an alert comes in?
“FWAS watches the data sets and if it sees anything important it will send the firefighter an alert on their phone. They can look at the information contained in the alert, then look into more detail on that alert on their phone.”
But this is only the beginning for this useful app.
“We have a prototype system, but we have enough funding now to develop this into an operational system,” Forthofer asserted.
“Right now, there is a web form that you fill out and the alerts are sent to the phone via text message or email, which is kind of clunky, but it’s a proof of concept to develop funding. Now we are moving forward with the operational system, looking for a programmer to develop parts of the interface.”
Forthofer pointed out an important reason to have something like FWAS.
“There are times with firefighter safety where something like this could have helped. Human factors come into play, where someone was warned, but they went ahead anyway. Yarnell is a good example, where it was thunderstorm outflow winds that got them even though they were warned a couple of hours beforehand that thunderstorms were forming and that there would be a change in wind and an increase in wind. But sometimes you have to make decisions based on incomplete information or information whose accuracy is questioned. FWAS could be the one additional thing that could cause a change in decision."
Generalized forecasting doesn’t help. “Sometimes you’ll get a vague forecast, where the IMET will get up and says there’s a chance of thunderstorms today with gusty outflow winds, but no information about the likelihood of it or timing. You go out on the fire and get no thunderstorm, so it becomes a case of crying wolf. As the day goes by if we see one forming, then that’s the time to get the information out, which makes it more reliable.”
Forthofer has a little personal experience with this problem.
“I was on a fire in Oregon where we had a chance of thunderstorms, same as several previous days, but none formed over the fire. I was on the top of a ridge, but we couldn’t see the sky for days at a time because of thick wildfire smoke when an inversion layer didn’t break for days. All of a sudden lightning strikes! That was on a large fire with a Type 1 team and an IMET, but we got no warning at all. FWAS could alert us and alert the weather people. I’ve heard back from them that they’re excited about this.”
The Nuts and Bolts of the System
The way the FWAS configuration page is set up right now, a user can enter their location with a latitude/longitude, or use the current location of their phone, or they can click on the ‘Current Fires’ button for a list of major wildfires.
Right below that the user can set the radius, with a sliding scale that goes out as far as 50 miles.
The user then assigns a name to the alert and sets the time zone for their area.
Below that, the next item allows the user to tell when the alert expires, which can be up to 168 hours in the future.
Moving down the page, the user sets the types of weather FWAS is supposed to alert the user about, including relative humidity, wind speed, wind gusts, temperature, precipitation, and thunderstorms. The app can also alert the user to National Weather Service Watches, Warnings, and Advisories.
“Precipitation is an important alert,” said Forthofer. “I’ve been on many fires where apparatus that is spread out all over the area gets stuck in the mud. I’ve also been on fires where flash floods have occurred.”
Thunderstorms are another important one.
“I’ve been on fires where dry lightning has been a problem and outflow winds, which is what killed the guys on the Yarnell Hill Fire.”
At the bottom of the form the user can select email and/or text notification. After that, the user clicks on the “Go!” button and that sets the alert.
“The data that FWAS looks at are the point measurements of the RAWS [Remote Automatic Weather Stations] and the AWOS [Automated Weather Observing System] stations at the airports. We also use the NEXRAD [Next Generation Weather Radar] data to detect rain and the presence of a thunderstorm.”
Instead of using the usual weather forecasts seen on TV, FWAS needs more precise, current data.
“We use the HRRR [High-Resolution Rapid Refresh] forecast model, run by the National Weather Service, as well. We use it because it’s geared to a really short time scale, so it’s a good model to use for the next few hours. One of the original reasons for its development was to detect wind shear near airports. Every hour they grab the latest weather measurements and rerun the model hourly out to 18-24 hours. The advantage to this is that it uses several types of initialization data sets, including the latest radar data which can help capture those thunderstorms that develop quickly. It can really make use of this radar data also because it is rerun so much more frequently than other models (hourly compared to every four hours). Last, it has the highest spatial resolution of any of the models that are run.”
As with anything that’s new, reliability issues are a key concern.
“With FWAS, we want alerts to be fairly reliable. We won’t give a user an alert like ‘there’s going to be a thunderstorm in your area within the next three days,’ we look at the forecast only out about four hours. You can get an alert that a thunderstorm is supposed to be in your area in two hours, for instance."
Data Sets are the Key
Data sets can come from a variety of sources. “There’s the NEXRAD radar, which goes out about 125 nautical miles, then there’s also the TDWR [Terminal Doppler Weather Radar] systems at some of the larger airports, with a range of about 55 nautical miles which has algorithms to look for downbursts, but we don’t link into that, just the NEXRAD data.”
And for the future, there may be additional sources of data that Forthofer includes. “There are a couple of data sets I’d like to add, including some ground-based lightning detection systems that the U.S. Forest Service uses, and a new lightning detection system that the GOES 16 and 17 satellites can run in now. There are some advantages and disadvantages to the systems. The GOES satellites use flashes of light to determine if lightning is happening, and can detect cloud-to-cloud lightning, which allows early detection that a thunderstorm is present. That helps firefighters to know that there’s a thunderstorm there and that they might get outburst winds and downstrikes soon.”
But of equal importance, radial velocity readings could detect those deadly outflows like the one that claimed the firefighters at the Yarnell Hill Fire.
“Other kinds of data I’d like to eventually use include doppler radial velocity on the NEXRAD, which we currently only use reflectivity data that’s reflected off of particles like rain,” said Forthofer.
“Wind flow towards or away from the radar tower could potentially have useful information, like outburst events. There are some issues, because the outbursts are low, right near the ground surface, and a lot of times the NEXRAD doesn’t see that because it’s below the lowest scan level.”
Being based at the Fire Lab has its advantages.
“The FWAS could be extended to other things besides fire weather. Fire danger rating data could be added in there, since it’s generated right down the hall from me,” he chuckled.
A Vision of the Future
“Our vision for the future is a phone app that this would run in with a lot more features. Alerts would be better because the user could get in-app alerts instead of text or email alerts. If you didn’t want to get alerts any more you could silence them, which you can’t do very well with texts and emails. A user could also have more detailed information in the alert, including graphs of temperature or relative humidity [RH]. There could be links in there to additional information.”
The current alert system attempts to give users the most information possible. If they’re on a fire and a RAWS station hits their RH threshold, the alert they get would give them the time the threshold was hit, along with the name and location of the RAWS station. The new operational system would include a button or link so that a user could investigate what was going on with that threshold, with an RH alert on the time/temperature trace, the time/relative humidity plot for the last 12 hours for that RAWS station, and where the threshold was hit. “You could see, for instance, that every day for the last few days the RH dropped below 20% at 2 PM,” Forthofer added.
“There will be other options with the operational system. We could link in with the system that dispatchers use for the initial attack fires, those which were just reported an hour or two ago, and maybe even a map that you can point at and click on.”
Although the prototype has many useful features, the operational version will have more versatility. “The National Weather Service Watches, Warnings, and Advisories alerts you to Red Flag, severe thunderstorms, hail, or flash flood warnings. In the operational version, we’ll have an option where you can choose not to get some of these warnings.”
Lightning is another consideration.
“One threshold that I want to add is lightning, now that we have the lightning detection systems. I used to work with the Flathead Hotshots and a few years after I left some of their crew got hit by lightning.”
Something that rankles Forthofer is how federal agencies are ignoring a tremendous asset: data they collect on a regular basis. “The Forest Service and other agencies spend a ton of money on our RAWS stations, putting them out there, keeping them maintained, paying for the data to go to a satellite and then back, but we don’t do a very good job distributing the data to firefighters on the ground. It’s really not very easy on a phone to figure out what a RAWS station is reading near me right now. Radar reflectivity can be read from a phone pretty easy, but not the radial velocity.”
His solution? “My vision is that you could have the local fire weather forecast, which is also hard to get to on your phone, available. Sometimes if I travel to a fire out of state, it’s hard to figure out what fire weather zone I’m in. It would be nice to have a map showing my current location and the fire zones, so that you could click on the map and get the fire weather forecast for that day. Or I could click a point on the map and find out what the fire danger indices are for that day.”
Supporting Firefighters on the Fireline
“We put a lot of money into acquiring and generating all this data,” Forthofer lamented, “but it seems to me that we’ve forgotten the last link in that whole chain, which is how we get that information to the firefighters on the ground. We can get the data to the dispatcher or the fire behavior analyst at camp, but not to the firefighters conducting an initial attack on a fire. We could also use the systems available now that collect the fire data we need in a programmatic way, like fire location. With all the data that’s entered automatically now when a fire breaks out, that data could be fed into the app to set the alert location. We could break the fires up by state so that the user didn’t have 3,000 fires to scroll down through. Or we could use a map so that a user would click on a map to set the alert location. Topographical maps could be included in the system, too.”
Forthofer is taking a cue from pocket cards on how to make the data more user-friendly.
“Pocket cards are used by firefighters coming into a new, unfamiliar area in an attempt to give them some historical information about the local area, like particular weather factors or dryness factors that could cause fires to burn really quickly. But these factors can vary across the country. Similarly, the FWAS could allow users to post their weather thresholds for others to use for that area. And so, if a Montana firefighters travelled to Florida to fight a fire, he could browse for alerts commonly used for that particular area, posted and labeled by the local forest or unit. That way a firefighter from out of the area could start with those thresholds if they didn’t have better information.”
As with WindNinja, FWAS availability is limited. “FWAS is only available in the U.S., since it has been funded by U.S. agencies. We like to keep our code open source and posted on the internet, but right now outside the U.S., it would be difficult to use it because we would have to access the data sets for those countries, and that’s a lot of work. If the Canadians or the Australians wanted to, they could just take our code and modify it slightly. We could work with them and help them.”
Like WindNinja, FWAS could prove to be a boon to wildland firefighters. Though the prototype is useful, the operational version will be a tremendous help to firefighters who put their lives on the line to fight wildfires in the U.S. And, ultimately, it could prevent the occurrence of another disaster like the Yarnell Hill Fire.