DATA MANAGEMENT AND ANALYSIS WITH WRF AND SFIRE

Jonathan D. Beezley?, Mavin Martin†, Paul Rosen†, Jan Mandel?, Adam K. Kochanski‡

?Department of Mathematical and Statistical Sciences, University of CO Denver†Scientific Computing and Imaging Institute, University of Utah

‡Department of Meteorology, University of Utah

ABSTRACT

We introduce several useful utilities in developmentfor the creation and analysis of real wildland firesimulations using WRF and SFIRE. These utili-ties exist as standalone programs and scripts aswell as extensions to other well known software.Python web scrapers automate the process of down-loading and preprocessing atmospheric and surfacedata from common sources. Other scripts simplifythe domain setup by creating parameter files au-tomatically. Integration with Google Earth allowsusers to explore the simulation in a 3D environmentalong with real surface imagery. Postprocessingscripts provide the user with a number of outputdata formats compatible with many commonly usedvisualization suites allowing for the creation ofhigh quality 3D renderings. As a whole, these im-provements build toward a unified web applicationthat brings a sophisticated wildland fire modelingenvironment to scientists and users alike.

Index Terms— Data preprocessing, Data anal-ysis, Geophysics computing, Client-server systems

1. INTRODUCTION

The weather research and forecasting model (WRF)is a full-featured mesoscale weather model usedas a research tool and operational forecasting [1].SFIRE is an add-on wildland fire forecasting modelcoupled with WRF [2]. An earlier version is avail-

Supported by NSF grant AGS-0835579 and NIST Fire Re-search Grants Program grant 60NANB7D6144.

able in WRF release as WRF-Fire.1 Because WRFis widely used in the research community, there area large number of standard tools available for creat-ing and visualizing its simulation outputs. However,SFIRE acts on domains that are significantly higherresolution than the typical WRF simulation. In ad-dition, SFIRE uses surface variables on a refinedsubgrid that is different from the standard atmo-spheric surface variables. These subgrid variablesand the higher resolution modeling typically re-quires special processing for input and visualizationthat is not supported by most commonly used tools.For this reason, we have begun to develop newsoftware that mimic and extend standard utilitiesfor data processing and visualization specificallytailored for use with SFIRE.

2. MODEL INITIALIZATION AND DATAPREPROCESSING

As computers become more powerful, there is in-creasing interest in simulating smaller scale phe-nomena using WRF than is typically associatedwith mesoscale weather forecasting. In particular,a typical SFIRE simulation occurs at mesh resolu-tions on the order of 10 m or less. Even the highestresolution surface data provided with WPS is sev-eral hundred times coarser. For these fine scaledomains, the ability to import custom datasets intoWPS is essential for the initialization of a realis-tic simulation [3]. Resources such as the USGS’s

1http://www.openwfm.org/wiki/WRF-Fire_development_notes

arX

iv:1

208.

1061

v1 [

phys

ics.

ao-p

h] 5

Aug

201

2

seamless data server that provide open access tohigh quality surface data are generating a large in-terest in initializing WRF simulations using customdatasets. WPS provides a mechanism for thesedatasets through a simple binary file format that isdescribed in the WRF technical documentation [4];however, there is no standard API or GIS softwarecapable of writing to it. Users who lack sufficienttechnical knowledge are currently unable to processthis data into WRF.

Prior work related to WRF-Fire has lead tosmall utilities that are able to convert standard GISGeoTIFF files into Geogrid’s binary file format.The GeoTIFF specification is commonly used andcan be provided as output from a wide range of GISapplications. TopoGrabber2 is a Python applicationbased on this work that is capable of download-ing and converting topological data automatically.More recently, modifications to Geogrid have beenwritten allowing it to read GeoTIFF files directly,and extensions to WPS standard programs havemade it possible to ingest GeoTIFF data directlyfrom the USGS into a WRF simulation [5]. Theimplemented changes to Geogrid allows a user toimport a USGS GeoTIFF dataset directly into theWRF workflow without the (often) difficult anderror prone procedure of converting the data. TheGeoTIFF interface is compiled in as an optionalcomponent and is useful for both experienced GISusers with complicated workflows and those whojust want to replace a single data source. The im-plementation allows overriding erroneous metadatawithout modification to the source images, and effi-cient access to the data.

With tools in place to automatically retrieve andintegrate known data sources into a simulation, itis now possible to automate nearly all of the stepsnecessary to initialize a simulation for WRF andSFIRE. A command-line client has been written us-ing Python to generate all required parameter andinput files for a simulation given user defined do-main and fire ignition specifications. This script iscurrently being integrated with a web applicationbased on Google Maps, providing users with a fullygraphical environment for designing a simulation on

2http://laps.noaa.gov/topograbber

real surface imagery. This client application is cou-pled with a server located on a high performancecompute cluster that runs the simulation on demandand returns results back to the client as they are pro-cessed.

3. MODEL EVALUATION AND DATAPOSTPROCESSING

By default, WRF generates NetCDF binary filescontaining the raw simulation output. These filescontain a large number of variables that are usefulin analyzing the simulation output; however, theyare often too large to be transferred to the user’scomputer for visualization. Several utilities havebeen written that allow users to visualize the sim-ulation without downloading the full output. For aquick overview of the fire propagation, it is possibleto generate a KMZ file containing a raster imageof any surface variable or a georeferenced polygonoutlining the burning region at a given timestep.This KMZ file can be opened in a number of GISapplications including Google Earth to be overlaidon a rendering of the earth’s surface. Google Earthallows the user to play back the images in the KMZfiles as an animation with a timestamp indicatingthe simulation time. The web application in devel-opment uses this capability to display the results ofthe running simulation on top of Google Maps.

There are a number of options for rendering a3D visualization of the simulation. VAPOR is anapplication developed at NCAR designed for visu-alization of standard WRF atmospheric simulations.The postprocessing utility wrf2vdf takes a stan-dard WRF NetCDF output file and generates a morecompact vdf file containing only the fields the userwishes to investigate. VAPOR features a very fastand easy to use GUI for generation of high qual-ity images; however, it does not support the refinedgrids used by the fire variables. When using VA-POR with SFIRE, users are limited to low resolutionversions of fire variables, which can result in blockyimages.

Other popular 3D visualization applications in-clude Paraview, MayaVI, and VisTrails. These ap-plications all use the Visualization Toolkit (VTK)

as a backend and do not have any built in capabil-ity for reading WRF output files. SFIRE containsa Python script wrf2vtk that can generate VTKcompatible files from WRF outputs at full resolu-tion. This script is much like VAPOR’s wrf2vdfin that it converts the data to a more compact repre-sentation and compresses the files for transfer to alocal computer.

4. TOWARD A FIRE FORECASTING WEBPORTAL

Automated scripting of the model setup procedurehas lead to the development of a web portal provid-ing users with a simple interface for running SFIREsimulations using real data. The user registers withthe site with a username and password. Upon log-ging in, he or she is presented with a Google Mapsinterface with instructions to click on a point on themap to create a new ignition. When clicked, a dia-log box appears allowing the user to customize theparameters of the simulation. The user is notifiedby email on completion of the simulation when theuser can return to the web portal to view the outputof this and all prior simulations. Currently, the out-put of the simulation displays as an animation theheat flux into the atmosphere from the fire. In thefuture, we plan to add the ability to visualize othersurface variables such as fuel types, winds, and firedanger ratings.

The web frontend is built on top of a GoogleMaps interface using its javascript interface. Thecore web application including user and contentmanagement is served by Django. The backendcomponent is executed at a remote site on a com-pute cluster accessible via ssh from the web server.The web application passes a string in the form ofsimple keyword=value pairs specifying parametersof the fire simulation. These parameters includethe ignition location and time chosen by the user,domain size and resolution, and simulation run timeamong others. The web server executes an appli-cation script on the compute server providing thesimulation parameters and a session ID. The com-pute server initializes and executes the simulationwhile a post processing daemon watches for new

output files. Whenever a new output file is detected,a visualization script is executed generating a KMZfile, which is then uploaded to the web server to bedisplayed to the user.

5. CONCLUSION AND FUTURE WORK

The utilities presented here are designed to enhancethe usability of SFIRE for the average user by elimi-nating the need for complex data conversion or an indepth understanding of the underlying code. Theyare leading to a unified application where a user candesign a simulation through a series of graphical di-alogs, spawn the simulation on a remote computecluster, and visualize the output of the running sim-ulation locally. The development of such an appli-cation would provide an invaluable tool for researchand education.

6. REFERENCES

[1] J. Michalakes, J. Dudhia, D. Gill, T. Henderson,J. Klemp, W. Skamarock, and W. Wang, “TheWeather Reseach and Forecast model: Softwarearchitecture and performance,” 2004, Proceed-ings of the 11th ECMWF Workshop on the Useof High Performance Computing In Meteorol-ogy, 25-29 October 2004, Reading U.K. Ed.George Mozdzynski.

[2] Jan Mandel, Jonathan D. Beezley, and Adam K.Kochanski, “Coupled atmosphere-wildland firemodeling with WRF 3.3 and SFIRE 2011,”Geoscientific Model Development, vol. 4, pp.591–610, 2011.

[3] Georgi Jordanov, Jonathan D. Beezley, NinaDobrinkova, Adam K. Kochanski, and JanMandel, “Simulation of the 2009 Harmanlifire (Bulgaria),” 8th International Conferenceon Large-Scale Scientific Computations, So-zopol, Bulgaria, June 6-10, 2011, 2011, Lecturenotes in Computer Science, Springer, to appear.Prepring available at arXiv:1001.1588.

[4] Wei Wang, Cindy Bruyere, Michael Duda,Jimy Dudhia, Dave Gill, Hui-Chuan Lin,

Fig. 1. SFIRE web portal results page. Along with a standard Google Maps interface, the results portalcontains animation controls so the user can view the development of the fire front. Prior simulations arestored on the user’s account page and can be shared with other users.

John Michalakes, Syed Rizvi, Xin Zhang,Jonathan D. Beezley, Janice L. Coen, andJan Mandel, “ARW version 3 modelingsystem user’s guide,” Mesoscale & Mis-croscale Meteorology Division, NationalCenter for Atmospheric Research, July2010, http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/ARWUsersGuideV3.pdf.

[5] Jonathan D. Beezley, A. K. Kochanski, V. Y.Kondratenko, and J. Mandel, “Integratinghigh-resolution static data into WRF for realfire simulations,” Paper 6.3, Ninth Sym-posium on Fire and Forest Meteorology,Palm Springs, October 2011, 2011, http:

//ams.confex.com/ams/9FIRE/webprogram/Paper192276.html,retrieved December 2011.