openwfm - User contributions [en]

How to convert data for Geogrid

2013-10-09T14:14:26Z

Jbeezley: Moving all documentation and code to new repository.

{{users guide}}

See the github repository for [https://github.com/jbeezley/convert_geotiff.git convert_geotiff] for the latest documentation and source code.

[[Category:WRF-Fire]]
[[Category:Howtos|Convert data for Geogrid]]
[[Category:Data]]

Cargese 2013 tutorial session

2013-05-06T08:46:51Z

Jbeezley:

List of requirements:
* Standard build utilities
** make
** m4
** cshell
** perl
** gcc
** etc
* gfortran
* NetCDF
* git

Ubuntu install command
sudo apt-get install tcsh git build-essential m4 gfortran libnetcdf-dev netcdf-bin

[http://mxcl.github.io/homebrew/ Homebrew] install commands
brew install gfortran
brew install netcdf --enable-fortran

[https://www.virtualbox.org/ VirtualBox] [http://www-math.ucdenver.edu/~jbeezley/data/SFIRE_tutorial.ova virtual machine] with dependencies installed (user: sfire password: sfire).

Cargese 2013 tutorial session

2013-05-06T08:45:20Z

Jbeezley:

Cargese 2013 tutorial session

2013-05-03T09:15:31Z

Jbeezley:

Cargese 2013 tutorial session

2013-05-03T08:12:15Z

Jbeezley:

Cargese 2013 tutorial session

2013-05-03T08:11:54Z

Jbeezley:

Cargese 2013 tutorial session

2013-05-03T07:37:22Z

Jbeezley:

Cargese 2013 tutorial session

2013-05-03T07:27:26Z

Jbeezley:

List of requirements:
* Standard build utilities
** make
** m4
** cshell
** perl
** gcc
** etc
* gfortran
* NetCDF
* git

Cargese 2013 tutorial session

2013-05-03T07:20:03Z

Jbeezley: Starting cargese tutorial session setup page

List of requirements:
* Standard build utilities
** make
** m4
** cshell
** perl
** gcc
** etc
* gfortran
* NetCDF

How to create a fire portal compute server

2012-09-14T05:28:25Z

Jbeezley: Compute server setup information

The fire portal compute server is the backend of [http://wildfire.sci.utah.edu], which is responsible for
the computational tasks of generating the fire outputs. This page describes how to install all the necessary
software on a fresh install of Ubuntu Server 12.4. Installing on a different operating system is also possible,
but the user must figure out the correct package names from the package manager. In general, the following
software is necessary to run the compute server:
* Tools to build WRF
** fortran compiler
** make
** m4
** tcsh
** perl
** netcdf development libraries
** Geotiff development libraries
** jasper development libraries
** png development libraries
* Tools for running the compute server
** python version 2.6 or 2.7 with development libraries
** git
** openssh server and client
** GDAL with python support
* Python modules (most can be found in the package manager or easy_install/pip)
** netCDF4
** GitPython
** percache
** mechanize
** BeautifulSoup
** simplekml

=OS and software installation=

For the remainder of this guide, it is assumed that you have installed Ubuntu Server 12.4 with user name wildfire. Once you are logged in to the terminal, it is
recommended that you do a system update and restart.
sudo apt-get update
sudo apt-get dist-upgrade
sudo restart
Now you need to install required software from the apt repository.
sudo apt-get install python-pip gfortran libnetcdf-dev netcdf-bin \
libhdf5-serial-dev python-dev python-matplotlib \
python-matplotlib-data tcsh git build-essential m4 \
libcloog-ppl10 openssh-server libjasper-dev libpng-dev \
libgeotiff-dev gdal-bin python-gdal
Next, install python modules available in pip.
sudo pip install netCDF4 GitPython percache mechanize BeautifulSoup simplekml

Set the ssh server to start by default.
sudo update-rc.d ssh defaults

Add environment variables to the shell rc file.
echo 'export NETCDF=/usr' >> ~/.bashrc
echo 'export LIBTIFF=/usr' >> ~/.bashrc
echo 'export GEOTIFF=/usr' >> ~/.bashrc

Finally, reboot the computer.
sudo reboot

=WRF and server code checkout and configuration=
Checkout software from our git repository.
git clone repo.openwfm.org:/home/git/wrf-fire.git
git clone repo.openwfm.org:/home/git/WRF-GoogleEarth.git

Now, you need to compile WRF and WPS to generate a template run directory that the
compute server will use to execute the simulation.
cd wrf-fire/wrfv2_fire
echo '9
1' | ./configure
./compile em_real
cd ../WPS
echo 6 | ./configure
./compile
cd ..

Now, generate template tarball firesim.tar in ~/wrf-fire.
~/WRF-GoogleEarth/computeserver/makeTemplate.sh

Next, you will need to create a file in the home directory called <tt>.globalConfig.txt</tt>. This
contains basic information about that the computer setup that the server will use to execute the
simulation. A template of this file can be found in <tt>~/WRF-GoogleEarth/computeserver/globalConfig.txt</tt>.
For this setup, you can paste the following into this file:
<pre>[server]
mainDir=/home/wildfire/run
repoDir=/home/wildfire/wrf-fire
wrfConfig=%(repoDir)s/wrfv2_fire/configure.wrf
wpsConfig=%(repoDir)s/WPS/configure.wps
netCDFpath=/usr
wpsData=/home/wildfire/geog
ldPath=
templateDir=/home/wildfire/wrf-fire/firesim.tar

[cache]
cachefile=/home/wildfire/cache/cache.db
livesync=True
filestore=/home/wildfire/cache</pre>

Finally, create directories that the server will use for execution.
mkdir ~/cache
mkdir ~/log
mkdir ~/run

=Testing the installation=
To make sure everything is working correctly, create a test parameter file and run the simulation code.
<pre>mkdir results
mkdir test
cd test
echo 'centerLat=40.07160929510595
centerLon=-105.9405756939366
ign_radius=10
dx=100
dy=100
nx=40
ny=41
ignLat=40.07160929510595
ignLon=-105.9405756939366
ignTime=2011-10-05_00:01:00
runTime=1
spinupTime=.001
map_proj=lambert
uploadpath=localhost:results' > params.txt

python ~/WRF-GoogleEarth/computeserver/fireSim.py testsession params.txt</pre>

This will run a simulation and output kmz files to ~/results. Check logs in ~/log and the run directory in ~/run/testsession in case
any errors occur.

=Connecting to a web server=
At this point, the compute server is fully configured. All that remains is to ensure that there is a way to ssh into the web server without a password using the ~/.ssh/authorized_keys file. The
web server must also be able to log into the compute server passwordlessly as well. See the web server configuration guide for information on how to connect the portal to this compute server.

How to ingest heat flux data

2012-09-11T08:12:13Z

Jbeezley:

When dealing with real data, it is often necessary to reproject and interpolate raw data sources onto a WRF simulation grid. This is possible
using WPS in a manner similar to the method used [[How to run WRF-Fire with real data|here]]. This page illustrates this procedure on
MODIS heat flux data. The source data is converted and interpolated from its native geotiff format into a WRF compatible netCDF file where it can be
merged into a wrfinput file or analyzed using standard netCDF tools.

=Converting data to geotiff=

The method outlined here requires data in a geotiff format; however, not all data comes in this form. Most GIS utilities provide converters to save data
in geotiff format. One free and cross platform utility for accomplishing this is the [http://www.gdal.org/gdal_translate.html gdal_translate] command, which
is part of the Geospatial Data Abstraction Library (GDAL) [http://www.gdal.org/]. Often it is sufficient to run the following command to perform the conversion:
gdal_translate -of GTiff <source dataset> <destination dataset>
GDAL command line scripts are also capable of performing reprojection as well as simple processing of nearly any GIS file format.

=Interpolating data onto a model grid using geogrid=

Using the original <tt>namelist.wps</tt> used to create the domain. It is relatively simple to rerun geogrid with an additional dataset from
your source data. In this example, we will use the namelist linked [https://gist.github.com/3696702 here] and the geotiff data at [[File:O9820-B65-P1 fire mask.tif]].
*Compile WPS as described [[WPS with GeoTIFF support|here]] to enable geotiff support.
*Edit the geogrid table at <tt>geogrid/GEOGRID.TBL</tt> to contain the new variable. See the list of table parameters [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Description_of_GEOGRID.TBL here]. You can remove all of the variables present
with the exception of <tt>LANDUSEF</tt> to save on computation time. A minimal table is as follows:
<pre>===============================
name=LANDUSEF
priority=1
dest_type=categorical
z_dim_name=land_cat
landmask_water = modis_30s:17 # Calculate a landmask from this field
landmask_water = modis_lakes:17,21 # Calculate a landmask from this field
landmask_water = usgs_lakes:16,28 # Calculate a landmask from this field
landmask_water = default:16 # Calculate a landmask from this field
dominant=LU_INDEX
interp_option = modis_30s:nearest_neighbor
interp_option = 30s:nearest_neighbor
interp_option = usgs_lakes:nearest_neighbor
interp_option = modis_lakes:nearest_neighbor
interp_option = 2m:four_pt
interp_option = 5m:four_pt
interp_option = 10m:four_pt
interp_option = default:four_pt
rel_path= modis_30s:modis_landuse_20class_30s/
rel_path= 30s:landuse_30s/
rel_path= usgs_lakes:landuse_30s_with_lakes/
rel_path= modis_lakes:modis_landuse_21class_30s/
rel_path= 2m:landuse_2m/
rel_path= 5m:landuse_5m/
rel_path= 10m:landuse_10m/
rel_path= default:landuse_2m/
===============================
name=FIREMASK
priority=1
subgrid=yes
dominant_only=FIREMASK
dest_type=categorical
z_dim_name=firecat
fill_missing = 0.
interp_option=default:nearest_neighbor
abs_path=default:./firemask
===============================</pre>
*Create a new directory under <tt>WPS</tt> (here we use <tt>firemask</tt>) and copy the geotiff file into this directory.
*Create an index file in the directory you created. The format of the index file is described [[WPS_with_GeoTIFF_support#Using_GeoTIFF_with_WPS|here]] and [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Description_of_index here]. In this example, our index file will contain
the following
<pre>geotiff=O9820-B65-P1_fire_mask.tif
type=categorical
category_min=1
category_max=9
tile_bdr=3</pre>
*Run <tt>geogrid.exe</tt>

At this point, the newly interpolated data is in the file <tt>geo_em.d01.nc</tt> under the variable given in the table (here <tt>FIREMASK</tt> in [[File:FIREMASK Geo em.nc.gz]]). The data can be added to a wrfinput or wrfrst file using ncks [http://nco.sourceforge.net/] using the following command:
ncks -A -v FIREMASK geo_em.d01.nc wrfinput_d01
[[Category:Howtos|Ingest heat flux data]]

File:FIREMASK Geo em.nc.gz

2012-09-11T08:08:57Z

Jbeezley:

File:Geo em.d01.nc.gz

2012-09-11T08:08:31Z

Jbeezley: uploaded a new version of "File:Geo em.d01.nc.gz": Reverted to version as of 07:40, 31 March 2010

File:Geo em.d01.nc.gz

2012-09-11T08:08:22Z

Jbeezley: uploaded a new version of "File:Geo em.d01.nc.gz"

File:O9820-B65-P1 fire mask.tif

2012-09-11T07:39:44Z

Jbeezley: Example MODIS heatflux data

Example MODIS heatflux data

How to ingest heat flux data

2012-08-13T14:41:36Z

Jbeezley: place holder

[[Category:Howtos|Ingest heat flux data]]

How to run WRF-SFIRE with real data

2012-07-29T14:50:41Z

Jbeezley: /* Converting fuel data */

{{users guide}}
Running WRF-Fire with real data is a process very similar to running WRF with real data for weather simulations.
The [http://www.mmm.ucar.edu/wrf/users WRF users page] has many
[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/contents.html documents] and
[http://www.mmm.ucar.edu/wrf/OnLineTutorial/CASES/JAN00/index.html tutorials] outlining this process. The purpose
of this page is to provide a tutorial for using real data with WRF-Fire starting from scratch. We begin with a quick outline of the
steps involved including links to the output of each step. The user can use these linked files to start from any step or to verify
their own results. Due to platform and compiler differences your output might differ slightly from those provided.

''This page refers to data sources for the USA only. For other countries, you will need to make appropriate modifications yourself.''

=Outline=

# [[How_to_get_WRF-Fire|Obtain WRF-Fire source code]].
# [[How_to_compile_WRF-Fire|Compile target em_real]].
# [[#Compiling WPS|Compile WPS]].
# [[#Configuring_the_domain|Configure your domain]].
# [[#Obtaining data for geogrid|Download geogrid datasets]].
# [[#Converting fire data|Convert fire data to geogrid format]].
# [[#Running geogrid|Run the geogrid executable]].
# [[#Obtaining atmospheric data|Download atmospheric data]].
# [[#Running ungrib|Run the ungrib executable]].
# [[#Running metgrid|Run the metgrid executable]].
# [[#Running wrf|Run real.exe and wrf.exe]].

=Compiling WPS=

After you have compiled WRF, you then need to go into the subdirectory <code>WPS</code> and run
<code>./configure</code>. This will present you with a list of configuration options similar to those given by WRF.
You will need to chose one with the same compiler that you used to compile WRF. Generally, it is unnecessary to compile WPS with parallel support.
GRIB2 support is only necessary if your atmospheric data source requires it. Once you have chosen a configuration, you can compile with
<pre>./compile >& compile.log</pre>
Make sure to check for errors in the log file generated.

=Configuring the domain=

The physical domain is configured in the geogrid section of namelist.wps in the WPS directory. In this section, you should define
the geographic projection with <tt>map_proj</tt>, <tt>truelat1</tt>, <tt>truelat2</tt>, and <tt>stand_lon</tt>. Available projections
include <tt>'lambert'</tt>, <tt>'polar'</tt>, <tt>'mercator'</tt>, and <tt>'lat-lon'</tt>. The lower left corner of the domain is located at
<tt>ref_lon</tt> longitude and <tt>ref_lat</tt> latitude. The computational grid is defined by <tt>e_we/e_sn</tt>, the number of (staggered) grid
points in the west-east/south-north direction, and the grid resolution is defined by <tt>dx</tt> and <tt>dy</tt> in meters.
We also specify a path to where we will put the static dataset that geogrid will read from, and we specify the highest resolution (30 arc minutes) that this
data is released in.

<code><pre>&geogrid
e_we = 43,
e_sn = 43,
geog_data_res = '30s',
dx = 60,
dy = 60,
map_proj = 'lambert',
ref_lat = 39.70537,
ref_lon = -107.2907,
truelat1 = 39.338,
truelat2 = 39.338,
stand_lon = -106.807,
geog_data_path = '../../wrfdata/geog'
/</pre></code>

The share section of the WPS namelist defines the fire subgrid refinement in <tt>subgrid_ratio_x</tt> and <tt>subgrid_ratio_y</tt>. This means
that the fire grid will be a 10 time refined grid at a resolution of 6 meters by 6 meters. The <tt>start_date</tt> and <tt>end_data</tt> parameters specify
the time window that the simulation will be run in. Atmospheric data must be available at both temporal boundaries. The <tt>interval_seconds</tt>
parameter tells WPS the number of seconds between each atmospheric dataset. For our example, we
will be using the NARR dataset which is released daily every three hours or 10,800 seconds.

<code><pre>&share
wrf_core = 'ARW',
max_dom = 1,
start_date = '2005-08-28_12:00:00',
end_date = '2005-08-28_15:00:00',
interval_seconds = 10800,
io_form_geogrid = 2,
subgrid_ratio_x = 10,
subgrid_ratio_y = 10,
/</pre></code>
The full namelist used can be found [http://pastebin.com/2u3YXkHS here].

=Obtaining data for geogrid=

First you must download and uncompress the standard [http://www.mmm.ucar.edu/wrf/src/wps_files/geog_v3.1.tar.gz geogrid input data].
This is a 429 MB compressed tarball that uncompresses to around 11 GB. It contains all of the static data that geogrid needs for a standard
weather simulation; however, for a WRF-Fire simulation we need to fill in two additional fields that are too big to release in a single download for the
whole globe. We first need to determine the approximate latitude and longitude bounds for our domain.

We know the coordinates in the lower left corner from the <tt>ref_lon</tt> and <tt>ref_lat</tt> parameters of the namelist. We can estimate the
coordinates of the upper right corner by the approximate ratio 9e-6 degrees per meter. So, the upper right corner of our domain is at approximately
-107.2675 longitude and 39.7286 latitude. For the purposes of downloading data, we will expand this region to the range
-107.35 through -107.2 longitude and 39.6 through 39.75 latitude.

==Downloading fuel category data==

For the United States, Anderson 13 fuel category data is available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Upon opening the national map,
you will see a menu on the right side of the screen. Select the icon circled in blue.
[[File:Landfire_menu.png|center|thumb|The landfire menu.]]
 
This will open a window that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier.
[[File:landfire_selection.png|center|thumb|Domain selection.]]
 
In the next window, click on "modify data request". This window lists all of the available data products for the selected region. You want to check the box
next to "LANDFIRE 13 Anderson Fire Behavior Fuel Models" and change the data format to "GeoTIFF". Then go to the bottom of the page and click "Save Changes".
[[File:landfire_data_products.png|center|thumb|Data product selection.]]
 
Finally, click "Download". The file will be a compressed archive containing, among others, a GeoTIFF file. The name of the file will be different for each request,
but in this example we have <tt>lf02588871.zip</tt> containing the GeoTIFF file <tt>lf02588871.tif</tt>, which can be found here, [[File:lf02588871.tif]].

==Downloading high resolution elevation data==

Another USGS website serves topographical data of sufficient resolution for our 6 meter resolution fire grid. This dataset is called the National Elevation Dataset (NED) and
can be accessed at [http://seamless.usgs.gov/ http://seamless.usgs.gov/]. The interface is similar to that of the Landfire national map. Click on the icon circled in blue.
[[File:Ned_menu.png|center|thumb|The NED menu.]]
 
Again, we key in the coordinates determined before and click the modify data request button. In the data product selection page, we select "National Elevation Dataset (NED) 1/3 Arc Second" and change
to GeoTIFF format. Then download the data
set, which can be found here, [[File:09159064.tif]].
[[File:Ned data product.png|center|thumb|The NED data product selection page]]
 

=Converting fuel data=

This section describes converting data from geotiff to geogrid format. Alternatively, you can use the version of geogrid from our repository and read the geotiff file directly. For details see [[WPS_with_GeoTIFF_support]].

In order for geogrid to be able to read this data, we need to convert it into an intermediate format. We will be using a utility program
released with autoWPS to accomplish this. For information on how to obtain and compile this tool, see [[How_to_convert_data_for_Geogrid]]. We will place the <tt>convert_geotiff.x</tt> binary and the GeoTIFF
data files in the main WPS directory.
To convert the fuel category data, we will create new directories inside the WPS directory called <tt>landfire_data</tt> and <tt>ned_data</tt>. Inside the <tt>landfire_data</tt> directory, we
issue the following command to convert the fuel category data.
<code><pre>../convert_geotiff.x -c 13 -w 1 -u "fuel category" -d "Anderson 13 fire behavior categories" ../lf02588871.tif</pre></code>
The resulting <tt>index</tt> file created as follows.
<code><pre>projection = albers_nad83
truelat1 = 29.500000
truelat2 = 45.500000
stdlon = -96.000000
known_x = 1
known_y = 606
known_lat = 39.747818
known_lon = -107.373398
dx = 3.000000e+01
dy = 3.000000e+01
type = categorical
signed = yes
units = "fuel category"
description = "Anderson 13 fire behavior categories"
wordsize = 1
tile_x = 100
tile_y = 100
tile_z = 1
category_min = 1
category_max = 14
tile_bdr = 3
missing_value = 0.000000
scale_factor = 1.000000
row_order = bottom_top
endian = little</pre></code>
We have chosen to set the word size to 1 byte because it can represent 256 categories, plenty for
this purpose.
Notice that the program has changed the number of categories to 14 and uses the last category
to indicate that the source data was out of the range 1-13. For the fuel category data, this represents
that there is no fuel present, due to a lake, river, road, etc.

We can check that the projection information entered into the index file is correct, by running the
<tt>listgeo</tt> binary that is installed with libGeoTIFF. In this case, <tt>listgeo</tt> tells us
that the source file contains the following projection parameters.
<code><pre>Projection Method: CT_AlbersEqualArea
ProjStdParallel1GeoKey: 29.500000 ( 29d30' 0.00"N)
ProjStdParallel2GeoKey: 45.500000 ( 45d30' 0.00"N)
ProjNatOriginLatGeoKey: 23.000000 ( 23d 0' 0.00"N)
ProjNatOriginLongGeoKey: -96.000000 ( 96d 0' 0.00"W)
ProjFalseEastingGeoKey: 0.000000 m
ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4269/NAD83
Datum: 6269/North American Datum 1983
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left ( -963525.000, 1916445.000) (-107.3734004,39.7478163)
Lower Left ( -963525.000, 1898265.000) (-107.3478974,39.5867431)
Upper Right ( -948885.000, 1916445.000) (-107.2021990,39.7632976)
Lower Right ( -948885.000, 1898265.000) (-107.1770727,39.6021889)
Center ( -956205.000, 1907355.000) (-107.2751374,39.6750401)
</pre></code>
We can see that the conversion detected the projection correctly. The small difference in the
coordinates of the upper left corner reported by <tt>listgeo</tt> and that in the index file is
due to floating point error and is much less than the resolution of the data.

Finally, we go to the <tt>ned_data</tt> directory to convert the <tt>ZSF</tt> variable. In this case,
we issue the following command.
<code><pre>../convert_geotiff.x -u meters -d 'National Elevation Dataset 1/3 arcsecond resolution' ../09159064.tif</pre></code>
This produces the following <tt>index</tt> file.
<code><pre>projection = regular_ll
known_x = 1
known_y = 1621
known_lat = 39.750092
known_lon = -107.350090
dx = 9.259259e-05
dy = 9.259259e-05
type = continuous
signed = yes
units = "meters"
description = "National Elevation Dataset 1/3 arcsecond resolution"
wordsize = 2
tile_x = 100
tile_y = 100
tile_z = 1
tile_bdr = 3
missing_value = 0.000000
scale_factor = 1.000000
row_order = bottom_top
endian = little
</pre></code>
Here we have used the default word size of 2 bytes and a scale factor of 1.0,
which can represent any elevation in the world
with 1 meter accuracy, which is approximately the accuracy of the source data.

Again, we compare the projection parameters in the index file with that reported by <tt>listgeo</tt>
and find that the conversion was correct.
<code><pre> Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GeographicTypeGeoKey (Short,1): GCS_NAD83
GeogCitationGeoKey (Ascii,6): "NAD83"
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
End_Of_Keys.
End_Of_Geotiff.

GCS: 4269/NAD83
Datum: 6269/North American Datum 1983
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)

Corner Coordinates:
Upper Left (-107.3500926,39.7500926)
Lower Left (-107.3500926,39.6000000)
Upper Right (-107.2000000,39.7500926)
Lower Right (-107.2000000,39.6000000)
Center (-107.2750463,39.6750463)
</pre></code>

Finally, the converted data can be found here, [[File:Landfire_data.tgz]], and here, [[File:Ned_data.tgz]].

=Running geogrid=

The geogrid binary will create a netcdf file called <tt>geo_em.d01.nc</tt>. This file will contain all
of the static data necessary to run your simulation. Before we can run the binary, however, we must tell
geogrid what data needs to be in these files, where it can find them, and what kind of preprocessing we wnat done. This information is contained in a run-time configuration file called <tt>GEOGRID.TBL</tt>, which is
located in the <tt>geogrid</tt> subdirectory. The file that is released with WPS contains reasonable defaults
for the variables defined on the atmospheric grid, but we need to add two additional sections for the two fire
grid data sets that we have just created. We will append the following sections to the file
<tt>geogrid/GEOGRID.TBL</tt>.
<code><pre>===============================
name=NFUEL_CAT
priority=1
dest_type=categorical
dominant_only=NFUEL_CAT
z_dim_name=fuel_cat
halt_on_missing=yes
interp_option=default:nearest_neighbor
abs_path=./landfire_data
subgrid=yes
==============================
name=ZSF
priority = 1
dest_type = continuous
df_dx=DZDXF
df_dy=DZDYF
smooth_option = smth-desmth_special; smooth_passes=1
halt_on_missing=yes
interp_option = default:average_gcell(4.0)+four_pt+average_4pt
abs_path=./ned_data
subgrid=yes
==============================
</pre></code>
For <tt>NFUEL_CAT</tt>, we will use simple nearest neighbor interpolation, while for <tt>ZSF</tt>, we will
use bilinear interpolation with smoothing. Other configurations are possible. See the [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Description_of_GEOGRID.TBL WPS users guide] for further information. The full table used can be found [http://pastebin.com/kdymq5ff here].

Once we make these changes to the <tt>GEOGRID.TBL</tt> file, and ensure that all of the directories are in the correct place (including the default geogrid dataset at <tt>../../wrfdata</tt>), we can execute the geogrid binary.
<code><pre>./geogrid.exe</pre></code>
This will create a file called <tt>geo_em.d01.nc</tt> in the current directory, which can be found here,
[[File:geo_em.d01.nc.gz]]. The contents of this file can be viewed using your favorite NetCDF viewer.

<gallery caption="geo_em.d01.nc" widths="225px" heights="225px" perrow="3">
File:nfuel_cat.png|The fuel category data interpolated to the model grid.The
File:zsf.png|The high resolution elevation (1/3") data interpolated to the model grid.
File:hgt_m.png|The low resolution elevation data (30") data interpolated to the atmospheric grid
</gallery>
Here, we have visualized the fire grid variables, <tt>NFUEL_CAT</tt> and <tt>ZSF</tt>, as well as the
variable <tt>HGT_M</tt>, which is the elevation data used by the atmospheric model. We can compare
<tt>ZSF</tt> and <tt>HGT_M</tt> to verify that our data conversion process worked. The colormaps of these
two pictures have been aligned, so that we can make a quick visual check. As we see, the two images do
have a similar structure and magnitude, but they do seem to suffer some misalignment. Given that
the data came from two different sources, in two different projections, the error is relatively minor.
Because WPS converts between projections in single precision, by default, there is likely a significant
issue with floating point error. We may, in the future, consider making some changes so that this conversion is done in double precision.

=Obtaining atmospheric data=

There are a number of datasets available to initialize a WRF real run. The
[http://www.mmm.ucar.edu/wrf/users/download/free_data.html WRF users page] lists
a few. One challenge in running a fire simulation is finding a dataset of
sufficient resolution. One (relatively) high resolution data source is the
North American Regional Reanalysis (NARR). This is still only 32km resolution, so
no small scale weather patterns will appear in our simulation. In general, we
will want to run a series of nested domains in order to catch some small scale weather
features; however, we will proceed with a single domain example.

The NARR datasets are available after 3 months at the following website,
[http://nomads.ncdc.noaa.gov/data/narr/ http://nomads.ncdc.noaa.gov/data/narr/].
We will browse to the [http://nomads.ncdc.noaa.gov/data/narr/200508/20050828/ directory]
containing the data for August 28, 2005. Our simulation runs from the hours 12-15 on this
day, so we will download the grib files for hours
[http://nomads.ncdc.noaa.gov/data/narr/200508/20050828/narr-a_221_20050828_1200_000.grb 12] and
[http://nomads.ncdc.noaa.gov/data/narr/200508/20050828/narr-a_221_20050828_1500_000.grb 15].
You can get these files also from here, [[File:narr-a_221_20050828_12-15.tgz]].

=Running ungrib=

With the grib files downloaded, we need to link them into the WPS directory using the script
<tt>link_grib.csh</tt>. This script takes as arguments all of the grib files that are needed
for the simulation. In this case, we can run the following command in the WPS directory.
<code><pre>./link_grib.csh <path to>/*.grb</pre></code>
Substitute <path to> with the directory in which you have saved the grib files. This command
creates a series of symbolic links with a predetermined naming sequence to all of the grib files
you pass as arguments. You should now have two new soft links named <tt>GRIBFILE.AAA</tt> and
<tt>GRIBFILE.AAB</tt>.

With the proper links in place, we need to tell ungrib what they contain. This is done by copying a variable table into the main WPS directory. Several variable tables are distributed with WPS which
describe common datasets. You can find these in the directory <tt>WPS/ungrib/Variable_Tables</tt>.
In particular, the file which corresponds to the NARR grib files is called <tt>Vtable.NARR</tt>, so
we issue the following command to copy it into the current directory.
<code><pre>cp ungrib/Variable_Tables/Vtable.NARR Vtable</pre></code>
We are now ready to run the ungrib executable.
<code><pre>./ungrib.exe</pre></code>
This will create two files in the current directory named <tt>FILE:2005-08-28_12</tt> and <tt>FILE:2005-08-28_15</tt>. You can download these files here, [[File:ungrib_output.tgz]].

=Running metgrid=

Metgrid will take the files created by ungrib and geogrid and combine them into a set of files. At this point, all we need to do is run it.
<code><pre>./metgrid.exe</pre></code>
This creates two files named <tt>met_em.d01.2005-08-28_12:00:00.nc</tt> and <tt>met_em.d01.2005-08-28_15:00:00.nc</tt>, which you can download here, [[File:metgrid_output.tgz]].

=Running wrf=

We are now finished with all steps involving WPS. All we need to do is copy over the metgrid output
files over to our WRF real run directory at <tt>WRFV3/test/em_real</tt> and configure our WRF namelist.
We will need to be sure that the domain description in <tt>namelist.input</tt> matches that of
the <tt>namelist.wps</tt> we created previously, otherwise WRF will refuse to run. Pay particular attention
to the start/stop times and the grid sizes. The fire ignition parameters are configured
in the same way as for the ideal case. Relevant portion of the namelist we will use are given below.
<code><pre> &time_control
run_days = 0,
run_hours = 0,
run_minutes = 2,
run_seconds = 0,
start_year = 2005,
start_month = 08,
start_day = 28,
start_hour = 12,
start_minute = 00,
start_second = 00,
end_year = 2005,
end_month = 08,
end_day = 28,
end_hour = 15,
end_minute = 00,
end_second = 00,
interval_seconds = 10800
input_from_file = .true.,
history_interval_s = 30,
frames_per_outfile = 1000,
restart = .false.,
restart_interval = 1,
io_form_history = 2
io_form_restart = 2
io_form_input = 2
io_form_boundary = 2
/

&domains
time_step = 0,
time_step_fract_num = 5,
time_step_fract_den = 10,
max_dom = 1,
s_we = 1,
e_we = 43,
s_sn = 1,
e_sn = 43,
s_vert = 1,
e_vert = 41,
num_metgrid_levels = 30
dx = 60,
dy = 60,
grid_id = 1,
parent_id = 0,
i_parent_start = 0,
j_parent_start = 0,
parent_grid_ratio = 1,
parent_time_step_ratio = 1,
feedback = 1,
smooth_option = 0
sr_x = 10,
sr_y = 10,
sfcp_to_sfcp = .true.,
p_top_requested = 10000
/

&bdy_control
spec_bdy_width = 5,
spec_zone = 1,
relax_zone = 4,
specified = .true.,
periodic_x = .false.,
symmetric_xs = .false.,
symmetric_xe = .false.,
open_xs = .false.,
open_xe = .false.,
periodic_y = .false.,
symmetric_ys = .false.,
symmetric_ye = .false.,
open_ys = .false.,
open_ye = .false.,
nested = .false.,
/
</pre></code>
The full namelist used can be found [http://pastebin.com/thu8KDZF here].

Once the namelist is properly configured we run the WRF real preprocessor.
<code><pre>./real.exe</pre></code>
This creates the initial and boundary files for the WRF simulation and fills all missing fields
from the grib data with reasonable defaults. The files that it produces are <tt>wrfbdy_d01</tt>
and <tt>wrfinput_d01</tt>, which can be downloaded here [[File:wrf_real_output.tgz]].

Finally, we run the simulation.
<code><pre>./wrf.exe</pre></code>
The history file for this example can be downloaded here, [[File:wrf_real_history.tgz]].

[[Category:WRF-Fire]]
[[Category:Data]]
[[Category:Howtos|Run WRF-Fire with real data]]

WRF-Fire development notes

2012-04-22T00:46:17Z

Jbeezley: /* Wish list */

:''Main article: [[WRF-Fire]]. To get the software, see [[How to get WRF-Fire]].''

This page tracks activity in the [[WRF-Fire]] and related software development. All members of the community are welcome to [[Open Wildland Fire Modeling E community Wiki#How to get an account|get an account]] and [http://www.openwfm.org/w/index.php5?title=WRF-Fire_development_notes&action=edit edit].

==Wish list==

:''Add your suggestions or plans here. If you want to comment on any of the items, please start a new section of the [[Talk:WRF-Fire development notes|talk page]] and link to it here.''

* Add relative humidity to moisture tester output
* Flank spread rate as a function of base rate and TKE/turbulent fluxes
* Turn off artificial diffusion for good
* Connection of emissions products with [http://ruc.noaa.gov/wrf/WG11/Users_guide.pdf WRF-Chem]. Started, see [[Coupling with WRF-Chem]].
* Implement full [http://www.forestencyclopedia.net/p/p662/c/c2490/quick_citation_view BURNUP] algorithm instead of the simplification.
* Keep standalone model working.
* Add a canopy fire model for passive (colocated with surface fire) canopy fire.
* Parametrize ignition startup. See [[Talk:WRF-Fire development notes#Parametrized_ignition|discussion]].
* Input fuel moisture from the WRF surface model. See [[Talk:WRF-Fire_development_notes#Moisture_model|discussion]].
* Better level set method: High-order ENO and [http://www.math.ucla.edu/~yanovsky/LS.htm WENO], [http://ccm.ucdenver.edu/wiki/Jan_Mandel/Blog/2011_Feb_Mar#February_14:_CCM_Colloquium:_Olivier_Desjardins discontinuous Galerkin].
* Rewrite the level set method so that the level set function is ignition time minus current time and get rid of the separate '''tign''' array.
* Use the [http://www.fire.org/index.php?option=com_content&task=category&sectionid=2&id=31&Itemid=295 Fire SDK] to compute ROS.
* ROS model from [http://dx.doi.org/10.1016/j.combustflame.2009.07.010 Balbi et al 2009].
* Force the fire to a given location from a file read on restart. This will require fire history replay and atmosphere spin-up.
* Modify fuel from a file on restart to reflect suppression efforts.
* Ignition & fire modification from MODIS fire detection.
* Add fractional fuel volume to fuel categories and generate random fuel coverage.
* Add other variables in the [[wikipedia:http://en.wikipedia.org/wiki/National_Fire_Danger_Rating_System|National Fire Danger Rating System]] as diagnostics to WRF output.

==In progress==

:''When you start on an item from the wish list, please move the item here and add a link to the branch where you work on it.''

* Ignition from a given fire perimeter, with atmosphere and fuel consumption spin-up, by specifying ignition times. See [[Talk:WRF-Fire development notes#Fire spin-up|discussion]].
* Generate KML files for visualization in {{wp|Google Earth}}. See [[Talk:WRF-Fire development notes#Google_Earth|discussion]]
* Real test problem with real fire data at both fine and coarse resolution.
* Better quadrature for fuel left: The current scheme is second order accurate when all 4 corners of a fire mesh cell are on fire, and exact when all 4 corners are not on fire. In the case when only some of the 4 corners are on fire, the only requirements are that the transition when nodes ignite is continuous and monotonous. In that case, the scheme may not be very accurate. A better scheme would be accurate in more cases and have natural invariance properties. {{WRF-Fire-branch|jm2/mkim}} {{WRF-Fire-commit|4cf71f8d9e4309281321ad7d38e4f028a005fa8a|last commit}} {{WRF-Fire-branch|vk/test}}
:This affects the amount of heat output from the cell in the timesteps when the fireline crosses the cell.
* Set up fireflux test case: {{WRF-Fire-branch|fireflux}}, [http://ccm.ucdenver.edu/wiki/images/a/a8/Agu2010-kochanski.pdf submitted abstract]
* {{ccm|Data_assimilation_seminar|Data assimilation}}
* Dynamically determine midflame height and interpolate the wind there. See [[Talk:WRF-Fire development notes#Fuel height|discussion]].
* Conversion of atmosphere state to use outputs of unmodified WRF to drive the standalone model. See [[Talk:WRF-Fire development notes#Standalone_driver|discussion]].

==Done==

:''Move the item here when done and add a link to the contributor's last commit before the merge into master. Links to major milestone events can be also added to the timeline.''

===2004===

* Ned Patton and Janice Coen propose WRF-Fire in a [http://www.mmm.ucar.edu/mm5/workshop/ws04/Session9/Patton_Edward.pdf workshop paper] and formulate the fundamental principles of how to combine WRF with the fire spread model from [[CAWFE]].

===2005===

* Standalone fire model from CAWFE rewritten in F90 by Ned Patton received Mar 31 2005

===2006===

* John Michalakes writes specs for support of fire grids in WRF Feb 6 2006

===2007===

* Alternative implementation of fire grid in nested domains in WRF by Jon Beezley Feb 29 2007
* WRF-Fire development started from the WRF+CAWFE tracers code received from Ned Patton, Jon set up the git repository {{WRF-Fire-commit|b7ed4f2e4cd729c659d086efb86ecaca74919ff8|Jun 6 2007}}
* Matlab prototype of level set method working Aug 30, 2007
* Imported a modular rewrite with a new standalone level set code, called SFIRE {{WRF-Fire-commit|7b72b87820be21e0febba943f7325e66839016e5|Sep 5 2007}}
* WRF+spread by level set coupled code working {{WRF-Fire-commit|c073b70ef91f4458092cf0a7ecf9163aed5860ea|Nov 2 2007}}
* Paper with description of WRF-Fire and data assimilation [http://arxiv.org/abs/0712.3965 posted on arXiv Dec 24 2007]
* Ignition controlled from namelist {{WRF-Fire-commit|2439f24ff443ec18c5ff5812af456de30fb24636|Dec 24 2007}}

===2008===
* Change nodes on the fire mesh from corners to centers {{WRF-Fire-commit|af413df0557a49ca56db20ff3436b14c7bccee21|Feb 10 2008}}
* WPS support {{WRF-Fire-commit|94a84b5b0170d8771102ff7fe25040a716268caf|3 Aug 2008}}
* MPI support {{WRF-Fire-commit|0509e9b746cf671922f1db96667d7f52ab947563|Oct 23 2008}}
* Cleanup, delete standalone driver and the CAWFE tracer code {{WRF-Fire-commit|a3f839e50ebcf7e068c8aa0266401220bc09f2ec|Nov 18 2008}}
* Landfire data conversion {{WRF-Fire-commit|932a2d8b3e926bb193b2af07c1ba6410aa0e7e01|Dec 15 2008}}

===2009===
* Distributed memory (halos) {{WRF-Fire-commit|0b5a20e6d0c88a1771a781c57307df252a213a7b|Jan 7 2009}}
* Approved by UCD and NCAR for public release {{WRF-Fire-commit|76fac8823d0a81920de150a1061b95cd7717b0a9|Mar 17 2009}}
* Set up nested ideal case {{WRF-Fire-commit|aed943498d9ed9c2745151d1f4a63561ed7b5b22|May 4 2009}}
* WPS support for fire grid and nesting {{WRF-Fire-commit|4c86cf15408046b28a4c725fea80a9fc15ca1a7e|7 May 2009}}
* Paper with a description of the WRF-Fire and data assimilation [http://dx.doi.org/10.1109/MCS.2009.932224 published in June 2009]
* Add namelist.fire to define fuel categories {{WRF-Fire-commit|c978b4ad2e83788d21c72dd93b8ec7eaea5a8c90|20 Sep 2009}}
* Interpolate in the computation of fuel_left locally to save stack memory {{WRF-Fire-commit|2ac779ca139bd84e5da858a155d1efc2559b238d|Oct 10 2009}}
* [[How to visualize WRF-Fire output in Matlab|3D visualization in Matlab]] {{WRF-Fire-commit|9237c5529ee03a53d14c448a5fabefc13704819a|Nov 3 2009}}
* [[How to visualize WRF-Fire output in VisTrails|Visualization in VisTrails]] and [[Supercomputing 2009 Demo]], Nov 15 2009

===2010===
* Support for WRF restart {{WRF-Fire-commit|fd0219bce87b332b8abb55558c6323f2fc6dc2be|16 Jan 2010}}
* Control in namelist the initial atmosphere perturbation (bubble) in ideal run, off by default. {{WRF-Fire-commit|993cd88d2e2ec6ed84ada027bf5a483ac686c163|27 Feb 2010}} See [[Talk:WRF-Fire development notes#Bubble|discussion]].
* Version {{WRF-Fire-commit|b6fe89aeb71d941e91530aafcf2f5b183a44fc37|19 Feb 2010}} [[Fire code in WRF release#3.2|released with WRF 3.2]] on [http://www.mmm.ucar.edu/wrf/users/wrfv3.2/updates-3.2.html Apr 2 2010]
* Hyperbolic vertical mesh grading in ideal run not only exponential. {{WRF-Fire-commit|580450739d07b57467f2ce50e1d898029fa47fca|Mar 9 2010}}
* Fetch high-resolution geogrid data automatically {{WRF-Fire-commit|3bebc4f46f72de3cbfcebd902879098de1122c23|Apr 27 2010}}
* Walking line ignition (as the fireman walks igniting the fire) {{WRF-Fire-commit|acf57d48e09c66826dd8defc87a6dc800627a2e5|23 May 2010}}
* Basic [[How to visualize WRF-Fire output in VAPOR|visualization in VAPOR]]. {{WRF-Fire-commit|1e710fc81479ea71ed74dd9903da9917fc9dcd93|May 26 2010}}
* Merge git repository with WRF and WPS 3.2 {{WRF-Fire-commit|0c084a8e4efeda74c67f62e79393dcec3b21e2d5|Jun 12 2010}} [http://mailman.ucar.edu/pipermail/wrf-fire/2010-June/000046.html announcement]
* Interpolate the terrain gradient to the fire mesh instead of differencing an interpolated terrain height. {{WRF-Fire-commit|80d70fb74bea0e09ef0f635bd90fbe657582a79d|Jun 14 2010}} See [[Talk:WRF-Fire development notes#Proposed computation of smooth terrain gradient|discussion]].
* Replace includes for fire parameter arrays by a derived type. {{WRF-Fire-commit|38007163901e413a8952abd3d600fc8eba24d103|Jun 14 2010}}. See [[Talk:WRF-Fire development notes#Ugly includes|discussion]].
* Resurrected a standalone driver for the fire code that is independent of WRF for diagnostics. {{WRF-Fire-commit|6464357566b780c12d1d71dc2a144a27ed23217b|20 Jun 2010}} See [[Talk:WRF-Fire development notes#Standalone driver|discussion]].
* Surface initialization in ideal runs allows for defining surface properties like roughness, ground temperature, albedo etc., required by soil models and radiation codes. See [[Talk:WRF-Fire wish list#Surface Initialization|discussion]]. {{WRF-Fire-commit|5eb128225f87b727f30ce11f9cb07b637fb62786|Jul 6 2010}}
* Reading from a file in an ideal run: {{WRF-Fire-commit|d15ece139d3dbd69badfbb5d1c8f1cb857c53132|land use}}, {{WRF-Fire-commit|8d204c4348509cb2efd185cadc4073971ea95ecc|fuel categories}}, {{WRF-Fire-commit|45415cbb515cd4d7dbe0828b11b51b91bf993ae4|topography}} Jul 22 2010
* Vertical wind profiles in Matlab for diagnostics {{WRF-Fire-commit|bee953f99cdcd5260389fa3ab5ef5a7529770e2e|Sun Jul 25 2010}}
* Interpolate wind to a given height (the same for all fuels) from log profile, and set the height as fire_wind_height in the namelist. [http://github.com/jbeezley/wrf-fire/blob/76d3724e5ce9a69ba51ed650667058e9e583ae21/wrfv2_fire/phys/module_fr_sfire_driver.F#L1023 Sep 11 2010], added wind reduction factor with defaults per Behave {{WRF-Fire-commit|dce06344012c38151fef29b2924b9fc2de6a71cb|16 Sep 2010}}
* [[How to diagnose fuel properties in WRF-Fire|Rate of spread diagnostics]] {{WRF-Fire-commit|334bf9417b5397ed3692b8f469a4914ed433e051|16 Sep 2010}}.
* Support for NetCDF 4 output files based on HDF5 {{WRF-Fire-commit|06c276f324873bc4c6f82c27298430435989ab97|16 Oct 2010}}.
* Subscale ignition with zero initial radius. See [[Talk:WRF-Fire development notes#Gradual_ignition|discussion]]. {{WRF-Fire-commit|c28da1ac95eda7cda822df60e8051e7500873b19|Nov 2, 2010}}

===2011===
* [[Vertical wind interpolation|Vertical log interpolation of the wind to different heights for different fuels]]. See [[Talk:WRF-Fire_development_notes#Wind_interpolation_to_different_heights_for_different_fuels|discussion]]. {{WRF-Fire-commit|72219b996f0dbe6af16cd7afdcc39e036c751156|24 Feb 2011}}
* Ignition time interpolation for better quadrature of fuel left {{WRF-Fire-commit|d9cfc6e0988ed90cc96146a23d65a35bb5bad8d8|March 16, 2011}}. See [[WRF-Fire development notes#Better quadrature for fuel left|discussion]].
* Added independent adjustment factors of base spread rate, wind correction, and slope correction to fuel description {{WRF-Fire-commit|43a7425b36dd7fdc4b3784c6827cb7c44605d748|Mar 23, 2011}}
* Perimeter ignition from specified ignition times on the whole domain, allowing for atmosphere and fuel consumption spin-up. {{WRF-Fire-commit|716cf59c2313e3bb483a57db02211d17b8d095f7|Mar 24, 2011}} in ideal run. See [[Talk:WRF-Fire development notes#Fire spin-up|discussion]].
* WRF-Fire [http://mailman.ucar.edu/pipermail/wrf-fire/2011-April/000052.html released with WRF 3.3 Apr 6, 2011]. The release code is based on the {{WRF-Fire-commit|fa26d08d8154124ac51514b11bc671eb312e20f8|Nov 20, 2010}} version with bug fix {{WRF-Fire-commit|b964224219585ab198d58510c8f7a0cf129b1990|Jan 17, 2011}}, with [[Changes in WRF-Fire 3.3 release|further changes made at NCAR]].
* Started using the name [[SFIRE]] instead of [[WRF-Fire]], June 2011.
* Reference paper [http://dx.doi.org/10.5194/gmd-4-591-2011 published] in [http://www.geoscientific-model-development.net GMD] July 7, 2011.
* Timing from [http://www.cesm.ucar.edu/ ESMF] [http://www.mmm.ucar.edu/wrf/users/docs/user_guide/users_guide_chap7.html#_Toc75337319 structures] to support variable time step and ignition in a restart run. {{WRF-Fire-commit|e062dbf62b7591e71a486a7c512efd75e48ed9a1|Jul 24, 2011}} See [[Talk:WRF-Fire development notes#Ignition_Time|discussion]].
* [[Users guide]] moved to the wiki, including existing [[List of howtos|howtos]] as chapters. August 6, 2011
* Spread vector and [http://www.forestencyclopedia.net/p/p486 Byram's fire intensity] to estimate the severity of a potential fire for a fire danger rating map {{WRF-Fire-commit|52c4e1595e08a98059ae33c0592bee3d3c0f2bb4|Aug 26, 2011}}
* Restart from wrfout (cycling=.true.) {{WRF-Fire-commit|2b7c8f19382d5d3269e604bf6ba180a0ed8aec44|Sep 16, 2011}} See [[Talk:WRF-Fire development notes#Restart_from_wrfout|discussion]].
* Spatially variable moisture as a part of WRF input {{WRF-Fire-commit|5a6c4b8c06a0aef126ee60a1541744aaaf62c2e5|Sep 27, 2011}}
* Standalone model running from WRF atmospheric state. {{WRF-Fire-commit|168fbfaa8a62061b51999001dc55162e2ac3a798|Oct 28 2011}} See [[Talk:WRF-Fire development notes#Standalone_driver|discussion]].
===2012===
* Integrated fuel moisture model with input from WRF variables, based on the Canadian fire danger rating system {{WRF-Fire-commit|763044cd62eaaec5b92c14462f6e25bdddf4d643|Mar 10, 2012}}, See [[Talk:WRF-Fire_development_notes#Moisture_model|discussion]].
* Multiple fire time steps in a single atmospheric step, for stability with highly heterogenous fuels {{WRF-Fire-commit|773cacd01f4401f69d5ab4a0877e3a0a5a32abad|Mar 30, 2012}}

==Back burner==

:''Items from the wish list that are around for a long time or may never be done should be moved here.''

* Merge [http://mailman.ucar.edu/pipermail/wrf-fire/2011-April/000053.html additional changes] [[Fire_code_in_WRF_release#WRF_3.3|made independently in the WRF 3.3 release]].
* Convert ignition namelist variables into arrays for multiple ignitions.
* Add running (not colocated with surface fire) canopy fire.
* Support [http://www.dtcenter.org/wrf-nmm/users/ WRF-NMM] in addition to [http://www.mmm.ucar.edu/wrf/users/ WRF-ARW]
* Take the winds from a given distance behind the fireline, and set the distance in the namelist.
* Output of emissions products into WRF for visualization of smoke transport and dispersion.
* Add fuel models & fuel modeling schemes, esp. Scott-Burgan categories. Input the same fuel description files as [[BehavePlus]] and [[FARSITE]].
* Generate input data for [[WFDS]].

==See also==

* [[How to get WRF-Fire]]
* [[List of WRF-Fire pages]]
* [[Users guide]]
* [[Fire code in WRF release]]

==External links==

* {{ccm|Data_assimilation_seminar_to_do_list|Data assimilation seminar to do list}}
* {{ccm|Jan_Mandel/Blog|Jan Mandel's blog}}
* [http://repo.or.cz/git-browser/by-commit.html?r=wrffire.git Commit graph]
* [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF Coding Conventions]
* [http://www.mmm.ucar.edu/wrf/users/tutorial/200807/WRF%20Registry%20and%20Examples.pdf WRF Registry and Examples]
* [http://www.mmm.ucar.edu/wrf/WG2/software_v2/ WRF v2 Software Tools and Documentation]
* [http://www.mmm.ucar.edu/wrf/WG2/software_2.0/registry_schaffer.pdf Description of WRF Registry]

[[Category:WRF-Fire|Development notes]]

Smoke and coupling with WRF-Chem

2012-04-22T00:43:48Z

Jbeezley: Development notes

As of WRF 3.4, WRF-Chem is now included in the SFire repository. Work into coupling SFire with
WRF-Chem is ongoing. See {{WRF-Fire-branch|chem}}. As of {{WRF-Fire-commit|e7b52ab1baef2565ae1743a25bc1ed7f7f2fc109|April 21, 2012}}, a working template
has been implemented to inject a tracer into the atmosphere. This implementation seems to work as expected.
[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

==Compiling with chem support==
Compiling the code with support for WRF-Chem is similar to the [[How to compile WRF-Fire|standard procedure]].
You must set an environment variable <tt>WRF_CHEM</tt> and configure with the argument <tt>chem</tt> as follows.
<pre>
export WRF_CHEM=1
./configure chem
./compile em_fire
</pre>

==Running an idealized example==
An idealized example based on the hill case has been created in <tt>test/em_fire/chem</tt>.
This example doesn't quite work out of the box because WRF-Chem requires USGS landuse
data that the ideal case doesn't initialize. To get this example working, you have to trick
WRF into thinking that the input file contains USGS landuse data. (I'm not sure if this data is even used when just
using passive tracers anyway.) To do this, you can just change the global attribute <tt>MMINLU</tt> in
<tt>wrfinput_d01</tt> to the string "<tt>USGS</tt>". A python script (<tt>make_usgs.py</tt>)
that does this is included in the <tt>test/em_fire/chem</tt> directory, but it requires
[http://code.google.com/p/netcdf4-python/ netcdf4-python] to run. Assuming you have this module, the
following will execute the example.
<pre>
./ideal.exe
./make_usgs.py
./wrf.exe
</pre>
The tracer will appear as an atmospheric variable in the output file with the name <tt>smoke</tt>.

==Development notes==
As of {{WRF-Fire-commit|e7b52ab1baef2565ae1743a25bc1ed7f7f2fc109|April 21, 2012}},
the tracer is simply copied from the heat flux at the surface on the atmospheric mesh (<tt>GRNHFX</tt>).
A call to <tt>fire_emission</tt> has been added to <tt>module_fr_sfire_driver_wrf.F</tt> just after
calculation of heat flux tendencies. This subroutine has been added to the fire atmospheric module
and is preprocessed out of the source when WRF-Chem is not being compiled.

WRF-Chem contains a multitude of arrays representing concentrations of chemical species. The typical
method of injecting data into the simulation involves generating emission input data files from standard
sources. These sources are read into the code using auxiliary input streams and interpolated into
the species arrays in the <tt>emissions</tt> module. For the coupling with SFire, turning off file
input in the namelist seems to initialize the emission arrays to zero. This eliminates the need to generate
useless emission files.

WRF-Chem stores its state in several large arrays called <tt>*_emis</tt>, <tt>chem</tt>, and <tt>tracer</tt>. These arrays are four dimensional indexed like (x,z,y,s), where s is the chemical
species. The <tt>chem</tt>
and <tt>tracer</tt> arrays are located on the standard atmospheric grid, while the <tt>*_emis</tt> arrays
have an alternate vertical grid indexed to <tt>config%kemit</tt>.
An internal table keeps track of where each species is stored in these arrays. The domain structure
contains scalars such as <tt>p_smoke</tt> and <tt>p_e_so4</tt> that give the species index for
each type. The species quantities are specific to different chemistry options (<tt>chem_opt</tt>)
from the registry. We should eventually test that a compatible namelist option has been chosen to
avoid errors. The dynamics section of the namelist has an option for <tt>tracer_opt</tt>. This
controls what tracers are generated for Chem. For example, <tt>trace_opt = 1</tt> creates a single
tracer called <tt>smoke</tt>, see the registry for package definitions.

For the passive tracer scheme (<tt>chem_opt = 14</tt>), it appears to be sufficient just to add
the fire emission directly into the tracer array. If we want to fully utilize WRF-Chem in the future,
we may need to do something more complicated. The [http://ruc.noaa.gov/wrf/WG11/Users_guide.pdf User's guide] mentions that there is code to handle wildfire emissions data from MODIS satellites. This may be
helpful either directly or as a guide in how to inject the chemical species from the SFire model.

According to some comments in Registry.EM, basic tracer support exists in WRF without Chem. It is possible
we may be able to add smoke the WRF even without compile for Chem. I have not explored this yet, though.

Smoke and coupling with WRF-Chem

2012-04-21T23:54:57Z

Jbeezley: /* Running an idealized example */

Smoke and coupling with WRF-Chem

2012-04-21T23:37:53Z

Jbeezley: /* Compiling with chem support */

Smoke and coupling with WRF-Chem

2012-04-21T23:25:12Z

Jbeezley: Describing chem support

File:Smoke small.avi

2012-04-21T23:20:58Z

Jbeezley: Animation of smoke tracer injected into WRF-Chem.

Animation of smoke tracer injected into WRF-Chem.

File:Sfire smoke.png

2012-04-21T23:19:10Z

Jbeezley: Initial implementation of SFire/WRF-Chem coupling injecting a tracer into the atmosphere.

Initial implementation of SFire/WRF-Chem coupling injecting
a tracer into the atmosphere.

How to convert data for Geogrid

2012-03-25T17:46:35Z

Jbeezley: Adding information on proj.4 support

{{users guide}}
Running WRF-Fire using real data requires additional datasets not included in the standard
WPS input data [http://www.mmm.ucar.edu/wrf/src/wps_files/geog_v3.1.tar.gz tarball]. For these,
it is necessary to convert your source data into the
[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Writing_Static_Data geogrid data format].
The geogrid data format consists of a directory of tiled binary files with names indicating the index range contained in each tile.
For instance, a file name of <tt>00101-00200.00051-00100</tt> would consist of columns 101 through 200 and rows 51 through 100.
The files themselves contain only an array integers, with no associated metadata.
The metadata for the dataset is contained in a file called <tt>index</tt>, which contains a series ''keyword=value'' statements
telling geogrid the details of the data tiles, such as width, height, the number of bytes per integer, etc. The index file also contains metadata
for the data set itself, such as the projection information and physical units.

We have made available a series of scripts and utilities ([http://github.com/jbeezley/autoWPS autoWPS]) intended to automate many of the steps
required to create a dataset for a WRF real run. A utility program included in this repository, WPSGeoTiff, is a simple command line utility that
takes a GeoTiff file and writes converts the data into geogrid binary format. The GeoTiff format was chosen because it is a highly ubiquitous format
for geotagged data and it has a cross-platform and open source c library called [http://trac.osgeo.org/geotiff/ libGeoTIFF]. Most, if not all, GIS application
software is capable of converting or exporting a dataset as a GeoTiff file.

=Prerequisites=

The WPSGeoTiff utility requires two external libraries in order to compile. You should pick a location to install the libraries, for instance <tt>PREFIX=${HOME}/opt</tt>.
* Optional: [http://trac.osgeo.org/proj/ Proj.4] This library is required in order to process projected GeoTIFF files. It must be installed before GeoTIFF for the projection support to be added.
<code>./configure --prefix=$PREFIX
make
make install</code>
* [http://www.libtiff.org/ libTIFF] The following commands are sufficient to install libTIFF for most systems.
<code>./configure --prefix=$PREFIX
make
make install</code>
* [http://trac.osgeo.org/geotiff/ libGeoTIFF] A similar set of commands install libGeoTIFF, but we must tell the configure script were we put libTIFF.
<code>./configure --prefix=$PREFIX --with-libtiff=$PREFIX
make
make install</code>
If you are compiling in Proj.4 support it may be necessary to tell GeoTIFF where that library is installed. You can do this by adding the flag <tt>--with-proj=$PREFIX</tt>.
<code>./configure --prefix=$PREFIX --with-libtiff=$PREFIX --with-proj=$PREFIX
make
make install</code>
After doing this, the configuration summary that prints after running configure will have a line saying <tt>PROJ support......: yes</tt>.

=Obtaining the WPSGeoTiff source=

The autoWPS package is available as a git repository hosted at [http://github.com/jbeezley/autoWPS github]. The repository can be cloned with the
[http://git-scm.com/ git] command:
<code>git clone git://github.com/jbeezley/autoWPS.git</code>
A tarball of the latest release can also be obtained
at [http://github.com/jbeezley/autoWPS/tarball/master http://github.com/jbeezley/autoWPS/tarball/master].

=Compiling WPSGeoTiff=

Inside the main directory of the autoWPS release is a subdirectory called WPSGeoTiff. This utility is written in pure c and creates a standalone binary.
In most cases it can be compiled by issuing the following command.
<code>LIBTIFF=$PREFIX GEOTIFF=$PREFIX make</code>
The main binary <tt>convert_geotiff.x</tt>, should now reside in the current directory.

=Running WPSGeoTiff=

Running <tt>convert_geotiff.x</tt> with no arguments will produce a usage description.
<code><pre>Usage: ./convert_geotiff.x [OPTIONS] FileName

Converts geotiff file `FileName' into geogrid binary format
into the current directory.

Options:
-h : Show this help message and exit
-c NUM : Indicates categorical data (NUM = number of categories)
-b NUM : Tile border width (default 3)
-w [1,2,4] : Word size in output in bytes (default 2)
-z : Indicates unsigned data (default FALSE)
-t NUM : Output tile size (default 100)
-s SCALE : Scale factor in output (default 1.)
-m MISSING : Missing value in output (default 0., ignored for categorical data)
-u UNITS : Units of the data (default "NO UNITS")
-d DESC : Description of data set (default "NO DESCRIPTION")
</pre></code>
All of the files will be created in the current directory, so it is best to run the program from an empty directory. A more detailed description of the
arguments to this program follows.
*; <tt>-b</tt>
:The data tiles in the geogrid binary format are allowed to overlap by a fixed number of grid points. The extra border around the tile is called the halo, and this argument sets the width of the halo. For instance with a halo of size three, the file named <tt>00101-00200.00051-00100</tt> would actually contain columns 98-203 and rows 48-103 of the full dataset. This halo is necessary for the interpolation scheme inside of WPS. The default should be acceptable for most situations.
*; <tt>-w</tt>
:The number of bytes to represent each data point as an integer. These integers are scaled by the scaling parameter before being truncated to an integer. scaledA lower value will make the output data smaller, at the cost of accuracy or the dynamic range of the input.
*; <tt> -m</tt>
:Any grid point that is missing data, such as the outer border of the edge tiles, or grid points that the GeoTIFF file indicates as missing will be set to this value. This argument is currently ignored when the categorical flag is set, instead missing data will be set to the maximum category + 1.
*;<tt>-s</tt>
:Because the data is always stored as an integer, a scaling parameter is needed to represent fractional numbers or large values. The data set will be divided by this number prior to being truncated to an integer. If the data set has an accuracy of 2 decimal places, a reasonable scale to use would be 0.01.
*;<tt>-u, -d</tt>
:The units and a small description of the data set should be included as arguments. Multi-word arguments should be quoted as follows. <code><pre>-u meters -d "elevation above sea level"</pre></code>
*; <tt>FileName</tt>
:The final argument must always be present. This is the (absolute or relative) path to the GeoTIFF file to be converted.

If you get an error that says something like "<tt>error while loading shared libraries: libgeotiff.so</tt>...", this means that GeoTIFF was compiled in as a shared library. You just need to tell the system where to find this library. This can be done by adding the path to the GeoTIFF library to the environment variable <tt>LD_LIBRARY_PATH</tt>. For example,
<code>export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${PREFIX}/lib</code>
where $PREFIX is the location where you installed GeoTIFF.

=Limitations=

The current code has several limitations which are listed here.
* Datasets must not contain more than 99,999 grid points in each axis. This is a limitation of the geogrid format itself, due to the naming convention of the tiles. However, it is possible (but inefficient) to split a single dataset into multiple directories for this purpose. A better solution would be to resample the data to a lower spatial resolution prior to converting.
* This program cannot convert between geographic projections, so the input data must be in a projection supported by WPS. All of the projections [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Description_of_index supported by WPS] should work for this conversion program; however, only UTM, Albers equal area, and lat-lon have been tested. In addition, data sources may not conform to [http://www.spatialreference.org/ EPSG standards] in their projection tags; the output should always be checked before use.

[[Category:WRF-Fire]]
[[Category:Howtos|Convert data for Geogrid]]
[[Category:Data]]

How to convert data for Geogrid

2012-03-25T00:27:46Z

Jbeezley: Adding a note about LD_LIBRARY_PATH

{{users guide}}
Running WRF-Fire using real data requires additional datasets not included in the standard
WPS input data [http://www.mmm.ucar.edu/wrf/src/wps_files/geog_v3.1.tar.gz tarball]. For these,
it is necessary to convert your source data into the
[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Writing_Static_Data geogrid data format].
The geogrid data format consists of a directory of tiled binary files with names indicating the index range contained in each tile.
For instance, a file name of <tt>00101-00200.00051-00100</tt> would consist of columns 101 through 200 and rows 51 through 100.
The files themselves contain only an array integers, with no associated metadata.
The metadata for the dataset is contained in a file called <tt>index</tt>, which contains a series ''keyword=value'' statements
telling geogrid the details of the data tiles, such as width, height, the number of bytes per integer, etc. The index file also contains metadata
for the data set itself, such as the projection information and physical units.

We have made available a series of scripts and utilities ([http://github.com/jbeezley/autoWPS autoWPS]) intended to automate many of the steps
required to create a dataset for a WRF real run. A utility program included in this repository, WPSGeoTiff, is a simple command line utility that
takes a GeoTiff file and writes converts the data into geogrid binary format. The GeoTiff format was chosen because it is a highly ubiquitous format
for geotagged data and it has a cross-platform and open source c library called [http://trac.osgeo.org/geotiff/ libGeoTIFF]. Most, if not all, GIS application
software is capable of converting or exporting a dataset as a GeoTiff file.

=Prerequisites=

The WPSGeoTiff utility requires two external libraries in order to compile. You should pick a location to install the libraries, for instance <tt>PREFIX=${HOME}/opt</tt>.
* [http://www.libtiff.org/ libTIFF] The following commands are sufficient to install libTIFF for most systems.
<code>./configure --prefix=$PREFIX
make
make install</code>
* [http://trac.osgeo.org/geotiff/ libGeoTIFF] A similar set of commands install libGeoTIFF, but we must tell the configure script were we put libTIFF.
<code>./configure --prefix=$PREFIX --with-libtiff=$PREFIX
make
make install</code>

=Obtaining the WPSGeoTiff source=

The autoWPS package is available as a git repository hosted at [http://github.com/jbeezley/autoWPS github]. The repository can be cloned with the
[http://git-scm.com/ git] command:
<code>git clone git://github.com/jbeezley/autoWPS.git</code>
A tarball of the latest release can also be obtained
at [http://github.com/jbeezley/autoWPS/tarball/master http://github.com/jbeezley/autoWPS/tarball/master].

=Compiling WPSGeoTiff=

Inside the main directory of the autoWPS release is a subdirectory called WPSGeoTiff. This utility is written in pure c and creates a standalone binary.
In most cases it can be compiled by issuing the following command.
<code>LIBTIFF=$PREFIX GEOTIFF=$PREFIX make</code>
The main binary <tt>convert_geotiff.x</tt>, should now reside in the current directory.

=Running WPSGeoTiff=

Running <tt>convert_geotiff.x</tt> with no arguments will produce a usage description.
<code><pre>Usage: ./convert_geotiff.x [OPTIONS] FileName

Converts geotiff file `FileName' into geogrid binary format
into the current directory.

Options:
-h : Show this help message and exit
-c NUM : Indicates categorical data (NUM = number of categories)
-b NUM : Tile border width (default 3)
-w [1,2,4] : Word size in output in bytes (default 2)
-z : Indicates unsigned data (default FALSE)
-t NUM : Output tile size (default 100)
-s SCALE : Scale factor in output (default 1.)
-m MISSING : Missing value in output (default 0., ignored for categorical data)
-u UNITS : Units of the data (default "NO UNITS")
-d DESC : Description of data set (default "NO DESCRIPTION")
</pre></code>
All of the files will be created in the current directory, so it is best to run the program from an empty directory. A more detailed description of the
arguments to this program follows.
*; <tt>-b</tt>
:The data tiles in the geogrid binary format are allowed to overlap by a fixed number of grid points. The extra border around the tile is called the halo, and this argument sets the width of the halo. For instance with a halo of size three, the file named <tt>00101-00200.00051-00100</tt> would actually contain columns 98-203 and rows 48-103 of the full dataset. This halo is necessary for the interpolation scheme inside of WPS. The default should be acceptable for most situations.
*; <tt>-w</tt>
:The number of bytes to represent each data point as an integer. These integers are scaled by the scaling parameter before being truncated to an integer. scaledA lower value will make the output data smaller, at the cost of accuracy or the dynamic range of the input.
*; <tt> -m</tt>
:Any grid point that is missing data, such as the outer border of the edge tiles, or grid points that the GeoTIFF file indicates as missing will be set to this value. This argument is currently ignored when the categorical flag is set, instead missing data will be set to the maximum category + 1.
*;<tt>-s</tt>
:Because the data is always stored as an integer, a scaling parameter is needed to represent fractional numbers or large values. The data set will be divided by this number prior to being truncated to an integer. If the data set has an accuracy of 2 decimal places, a reasonable scale to use would be 0.01.
*;<tt>-u, -d</tt>
:The units and a small description of the data set should be included as arguments. Multi-word arguments should be quoted as follows. <code><pre>-u meters -d "elevation above sea level"</pre></code>
*; <tt>FileName</tt>
:The final argument must always be present. This is the (absolute or relative) path to the GeoTIFF file to be converted.

If you get an error that says something like "<tt>error while loading shared libraries: libgeotiff.so</tt>...", this means that GeoTIFF was compiled in as a shared library. You just need to tell the system where to find this library. This can be done by adding the path to the GeoTIFF library to the environment variable <tt>LD_LIBRARY_PATH</tt>. For example,
<code>export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${PREFIX}/lib</code>
where $PREFIX is the location where you installed GeoTIFF.

=Limitations=

The current code has several limitations which are listed here.
* Datasets must not contain more than 99,999 grid points in each axis. This is a limitation of the geogrid format itself, due to the naming convention of the tiles. However, it is possible (but inefficient) to split a single dataset into multiple directories for this purpose. A better solution would be to resample the data to a lower spatial resolution prior to converting.
* This program cannot convert between geographic projections, so the input data must be in a projection supported by WPS. All of the projections [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3.1/users_guide_chap3.htm#_Description_of_index supported by WPS] should work for this conversion program; however, only UTM, Albers equal area, and lat-lon have been tested. In addition, data sources may not conform to [http://www.spatialreference.org/ EPSG standards] in their projection tags; the output should always be checked before use.

[[Category:WRF-Fire]]
[[Category:Howtos|Convert data for Geogrid]]
[[Category:Data]]

File:Hurricane center.png

2011-10-31T08:58:24Z

Jbeezley: uploaded a new version of "File:Hurricane center.png"

Jbeezley/hurricane

2011-10-31T08:30:02Z

Jbeezley:

Hurricane [http://www-math.ucdenver.edu/~jbeezley/data/u_v_t_q_slp_all_50mems_2009080600.tar.gz data] received from Fuqing Zhang. The tarball received contains 50 randomly perturbed ensemble members for an operational hurricane simulation in the Gulf of Mexico. Each NetCDF file contained in this tarball contains only the surface layer of variables U, V, SLP, T, and QVAPOR. Nine of the ensemble members given in the tarball are visualized in the gallary below along with some basic statistical analysis of the ensemble.

[[File:Hurricane center.png|left|frame|The centers of each hurricane calculated as the location of minimum
surface pressure displayed as an asterisk. The color of the asterisks show the value of the minimum pressure.
The black oval shows the range of 1 standard deviation from the mean position.]]

<gallery perrow=4>
File:Hurricane SLP 001.png
File:Hurricane T 001.png
File:Hurricane QVAPOR 001.png
File:Hurricane wind 001.png
File:Hurricane SLP 002.png
File:Hurricane T 002.png
File:Hurricane QVAPOR 002.png
File:Hurricane wind 002.png
File:Hurricane SLP 003.png
File:Hurricane T 003.png
File:Hurricane QVAPOR 003.png
File:Hurricane wind 003.png
File:Hurricane SLP 004.png
File:Hurricane T 004.png
File:Hurricane QVAPOR 004.png
File:Hurricane wind 004.png
File:Hurricane SLP 005.png
File:Hurricane T 005.png
File:Hurricane QVAPOR 005.png
File:Hurricane wind 005.png
File:Hurricane SLP 006.png
File:Hurricane T 006.png
File:Hurricane QVAPOR 006.png
File:Hurricane wind 006.png
File:Hurricane SLP 007.png
File:Hurricane T 007.png
File:Hurricane QVAPOR 007.png
File:Hurricane wind 007.png
File:Hurricane SLP 008.png
File:Hurricane T 008.png
File:Hurricane QVAPOR 008.png
File:Hurricane wind 008.png
File:Hurricane SLP 009.png
File:Hurricane T 009.png
File:Hurricane QVAPOR 009.png
File:Hurricane wind 009.png
</gallery>

<gallery perrow=4 caption="The sample mean of each variable given in the ensemble.">
File:Hurricane mean p.png
File:Hurricane Mean t.png
File:Hurricane Mean q.png
File:Hurricane mean wind.png
</gallery>

<gallery perrow=4 caption="The sample standard deviation of each variable given in the ensemble.">
File:Hurricane P stdev.png
File:Hurricane T stdev.png
File:Hurricane Q stdev.png
</gallery>

File:Hurricane T stdev.png

2011-10-31T08:27:31Z

Jbeezley:

File:Hurricane Q stdev.png

2011-10-31T08:26:52Z

Jbeezley:

File:Hurricane P stdev.png

2011-10-31T08:26:07Z

Jbeezley:

File:Hurricane mean p.png

2011-10-31T08:24:53Z

Jbeezley:

File:Hurricane Mean q.png

2011-10-31T08:24:09Z

Jbeezley:

File:Hurricane Mean t.png

2011-10-31T08:23:32Z

Jbeezley:

File:Hurricane mean wind.png

2011-10-31T08:20:44Z

Jbeezley:

File:Hurricane center.png

2011-10-31T08:13:07Z

Jbeezley:

User talk:Jbeezley

2011-10-31T08:00:23Z

Jbeezley: moved User talk:Jbeezley to Jbeezley/hurricane

#REDIRECT [[Jbeezley/hurricane]]

Jbeezley/hurricane

2011-10-31T08:00:23Z

Jbeezley: moved User talk:Jbeezley to Jbeezley/hurricane

<gallery perrow=4>
File:Hurricane SLP 001.png
File:Hurricane T 001.png
File:Hurricane QVAPOR 001.png
File:Hurricane wind 001.png
File:Hurricane SLP 002.png
File:Hurricane T 002.png
File:Hurricane QVAPOR 002.png
File:Hurricane wind 002.png
File:Hurricane SLP 003.png
File:Hurricane T 003.png
File:Hurricane QVAPOR 003.png
File:Hurricane wind 003.png
File:Hurricane SLP 004.png
File:Hurricane T 004.png
File:Hurricane QVAPOR 004.png
File:Hurricane wind 004.png
File:Hurricane SLP 005.png
File:Hurricane T 005.png
File:Hurricane QVAPOR 005.png
File:Hurricane wind 005.png
File:Hurricane SLP 006.png
File:Hurricane T 006.png
File:Hurricane QVAPOR 006.png
File:Hurricane wind 006.png
File:Hurricane SLP 007.png
File:Hurricane T 007.png
File:Hurricane QVAPOR 007.png
File:Hurricane wind 007.png
File:Hurricane SLP 008.png
File:Hurricane T 008.png
File:Hurricane QVAPOR 008.png
File:Hurricane wind 008.png
File:Hurricane SLP 009.png
File:Hurricane T 009.png
File:Hurricane QVAPOR 009.png
File:Hurricane wind 009.png
</gallery>

Visualization in Google Earth

2011-10-08T02:02:38Z

Jbeezley: updating dependencies

{{users guide}}
[http://www.google.com/earth/index.html Google Earth] is proprietary software from Google allowing the user to explore 3D imagery of the earth's surface. Using its native support for [http://code.google.com/apis/kml/documentation/ kml files], it is possible to overlay images from numerical simulations onto the surface of the earth. However, Google Earth is not designed to be a visualization suite for numerical models. It can't, for example, create a pseudo color image from raw data. One must generate a bitmap image (jpg or png) of the data first before it can be used in Google Earth. Once that is done, it is a simple matter of creating a kml file which tells google where to display the image on the ground.

The code described on this page is maintained in a repository at
[https://github.com/jbeezley/WRF-GoogleEarth]. Contained within it is a simple script
for generating KMZ files for visualizing the heat flux from a fire simulation for users
that do not wish to customize the output. The
script requires python modules, [http://matplotlib.sourceforge.net/ matplotlib], [http://www.scipy.org/ scipy], and
[http://code.google.com/p/netcdf4-python/ netCDF4]. The script takes a single
argument, the WRF output file,
<code>python nc2kmz.py <wrfout file></code>.

=Generating an image from raw data=
When one generates a pseudocolor image from raw data, for example in Matlab using the <code>imshow</code> command, the image will usually contain a border with titles and axis labels. In order to align the image properly in Google Earth, we want just the image itself without any borders whatsoever. The easiest way to do this would be to open the image in Gimp and crop it manually; however, this is not suitable for generating a large number of visualizations or for an automated system.

==Using python and matplotlib==
The [http://www.python.org/ python] programming language contains a large number of packages useful for scientific computing and visualization. In particular, [http://matplotlib.sourceforge.net/ matplotlib] combines the numerical processing capabilities of [http://numpy.scipy.org/ numpy] with a full-featured 2D plotting package, which is very similar to Matlab's 2D plotting capabilities. In this example, we will use the function [http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow imshow] to generate a psuedo color image from some data in an [[EpiSim]] output file. In order to run this example yourself, you must have python with the [http://matplotlib.sourceforge.net/ matplotlib] and [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] (for reading the output [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files) packages installed.

When we run EpiSim, we are left with a series of [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files as output. These files contain the raw data from the model for a single time step. We want to create an image of the <code>Infected</code> variable from file <code>episim_0100.nc</code> to overlay onto Google Earth. We start by reading the file using the [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] package.

<pre>
from Scientific.IO import NetCDF

file=NetCDF.NetCDFFile('episim_0100.nc','r')
infected=file.variables['Infected']
</pre>

Now we load the [http://matplotlib.sourceforge.net/ matplotlib] package, and create a new figure window. Ordinarily, doing this is unnecessary. Because we want the image to contain no borders, we must initialize the figure window to contain only the figure axis. Note that the figure must be created with the correct aspect ratio, or the image will contain borders. We will use a constant width of 5 inches and find the correct height by multiplying the aspect ratio of the input data (the number of rows divided by the number of columns of the variable).

<pre>
import pylab

width=5
height=width*float(infected.shape[0])/float(infected.shape[1])

fig=pylab.figure(figsize=(width,height))
fig.add_axes([0,0,1,1])
</pre>

This should have created an empty figure window. We are now able to generate image using the <code>imshow</code> command. Note that <code>imshow</code> draws the figure from top to bottom (like an image) so we must flip the data vertically (using <code>flipud</code>) prior to displaying. Also, we want to visualize the data on a log color scale, so we will take the logarithm of the data (<code>log 0</code> will show up as white in the figure).

<pre>
data=pylab.flipud(infected)
data=pylab.log(data)

pylab.imshow(data)
</pre>

Finally, we will turn off the axis to remove any remnants of tick marks from the display axis, and save the file to a png image named <code>Infected.png</code>.

<pre>
pylab.axis('off')
pylab.savefig('Infected.png')
</pre>

You should now have an image that is ready to use as an overlay in Google Earth.

=Creating a kml file=
External images can be included into Google Earth in a number of different ways. What we are interested in is displaying our image over the ground. This is what is known as a [http://code.google.com/apis/kml/documentation/kmlreference.html#groundoverlay GroundOverlay]. A minimal kml file which will do this with the <code>Infected.png</code> image we generated above is as follows.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<GroundOverlay>
<name>Infected</name>
<Icon>
<href>Infected.png</href>
</Icon>
<altitude>0.0</altitude>
<altitudeMode>clampToGround</altitudeMode>
<LatLonBox>
<north>14.958334</north>
<south>-10.000000</south>
<east>40.958336</east>
<west>16.000000</west>
<rotation>0.0</rotation>
</LatLonBox>
</GroundOverlay>
</kml>
</pre>

The primary components of this file are the name of image as it is displayed in the Google Earth menu, the <code>Icon</code> key which tells where to find the image, the <code>altitudeMode</code> key tells it to stretch the image of the ground. Finally, the <code>LatLonBox</code> tells Google Earth where to put the image. The image is assumed to be defined on a regular latitude/longitude grid (not projected). The keys give the lines of latitude and longitude where the edges of the image should be placed. For the EpiSim output files, this can be found by looking beginning and end of the variables <code>latitude</code> and <code>longitude</code>.

<pre>
In [1]: from Scientific.IO import NetCDF

In [2]: file=NetCDF.NetCDFFile('episim_0100.nc','r')

In [3]: lat=file.variables['latitude']

In [4]: lon=file.variables['longitude']

In [5]: lat[-1],lat[0],lon[-1],lon[0]
Out[5]: (14.958334, -10.0, 40.958336, 16.0)
</pre>

Many more features for displaying overlays are available in the kml standard. See the [http://code.google.com/apis/kml/documentation/kmlreference.html documentation] for further details.

=Creating preloaded WRF-Fire animations=
'''This is only for users who have older versions of Google Earth. If you have Google Earth 6, loading multiple images from KMZ files is no longer an issue.'''

If you have older versions of Google Earth, either download and update to [http://www.google.com/earth/download/ge/ Google Earth 6] or use [https://github.com/zhlin/WRF-GoogleEarth/blob/movScript/nc2kmz_GE5.py this script] for preloading multiple images, and use as follows:

<pre>
python nc2kmz_GE5.py <wrfout_filename>
</pre>

The preloading functionality is an extension of the ncEarth module that accomplishes preloading the set of images that is in KMZ files by adding a static copy of the [http://code.google.com/apis/kml/documentation/time.html#example2 animated GroundOverlays]. The static copy of GroundOverlays is without the [http://code.google.com/apis/kml/documentation/kmlreference.html#timespan TimeSpan] element. When opening preloaded animation KMZ files, Google Earth automatically loads all the static GroundOverlays which caches the images that are needed in the animation, and when it finishes loading the static GroundOverlays, the timeline slider will appear on the left top corner of the screen for playing the animation. Loading time depends on the number of GroundOverlays in the animation, and if the animation is very large in size, Google Earth may appear frozen while loading. Unfortunately, Google Earth does not provide a way to display a message to the users while loading.

=Creating WRF-Fire animation legend =
For conveying information, we will need a legend for the animation. First of all, get the script [https://github.com/zhlin/WRF-GoogleEarth/blob/master/colorbarImg.py here] to generate the image for the legend. Use it as the following example:
<pre>
import colorbarImg
colorbarImg.getImages('wrfout.nc','FGRNHFX')
</pre>
Passing the name of a dataset and the variable name, and the resulting images will be stored in a subfolder called “colorbarImages”.
After selecting a colorbar image, we can use [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay ScreenOverlay] to display the legend in a fixed position on the screen.
Here are some examples of ScreenOverlay.

Refers to an image at given URL:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>http://server.com/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="1" y="-1" xunits="fraction" yunits="fraction"/>
</ScreenOverlay>
</pre>

Refers to an image in the KMZ file folder:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<folder>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>files/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="-1" y="-1" xunits="fraction" yunits="fraction"/>
</folder>
</ScreenOverlay>
</pre>

The <code><Icon></code> element points to the image to be used. This image file can be located on a file system or on a web server. To position the overlay, change the x and y values of the <code><overlayXY></code> and <code><screenXY></code> elements, <code>overlayXY</code> maps a point in the image to a point on the screen specified by <code>screenXY</code>, the unit for x and y values can be one of three units: pixels, fraction, and insetPixels. Also the values can be specified in different ways, for example x can be in fraction and y can be in pixels. The <code><size></code> element determines the size of the ScreenOverlay, vaule of -1 indicates to use the images’ original dimension.
For more detailed explanation of ScreenOverlay’ elements, see [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay KML reference document].

=External links=

https://github.com/jbeezley/WRF-GoogleEarth
[[Category:Visualization]]
[[Category:WRF-Fire]]

Visualization in Google Earth

2011-08-08T10:18:35Z

Jbeezley:

{{users guide}}
[http://www.google.com/earth/index.html Google Earth] is proprietary software from Google allowing the user to explore 3D imagery of the earth's surface. Using its native support for [http://code.google.com/apis/kml/documentation/ kml files], it is possible to overlay images from numerical simulations onto the surface of the earth. However, Google Earth is not designed to be a visualization suite for numerical models. It can't, for example, create a pseudo color image from raw data. One must generate a bitmap image (jpg or png) of the data first before it can be used in Google Earth. Once that is done, it is a simple matter of creating a kml file which tells google where to display the image on the ground.

The code described on this page is maintained in a repository at
[https://github.com/jbeezley/WRF-GoogleEarth]. Contained within it is a simple script
for generating KMZ files for visualizing the heat flux from a fire simulation for users
that do not wish to customize the output. The
script requires python modules, [http://matplotlib.sourceforge.net/ matplotlib] and
either [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] or
[http://code.google.com/p/netcdf4-python/ netCDF4]. The script takes a single
argument, the WRF output file,
<code>python nc2kmz.py <wrfout file></code>.

=Generating an image from raw data=
When one generates a pseudocolor image from raw data, for example in Matlab using the <code>imshow</code> command, the image will usually contain a border with titles and axis labels. In order to align the image properly in Google Earth, we want just the image itself without any borders whatsoever. The easiest way to do this would be to open the image in Gimp and crop it manually; however, this is not suitable for generating a large number of visualizations or for an automated system.

==Using python and matplotlib==
The [http://www.python.org/ python] programming language contains a large number of packages useful for scientific computing and visualization. In particular, [http://matplotlib.sourceforge.net/ matplotlib] combines the numerical processing capabilities of [http://numpy.scipy.org/ numpy] with a full-featured 2D plotting package, which is very similar to Matlab's 2D plotting capabilities. In this example, we will use the function [http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow imshow] to generate a psuedo color image from some data in an [[EpiSim]] output file. In order to run this example yourself, you must have python with the [http://matplotlib.sourceforge.net/ matplotlib] and [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] (for reading the output [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files) packages installed.

When we run EpiSim, we are left with a series of [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files as output. These files contain the raw data from the model for a single time step. We want to create an image of the <code>Infected</code> variable from file <code>episim_0100.nc</code> to overlay onto Google Earth. We start by reading the file using the [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] package.

<pre>
from Scientific.IO import NetCDF

file=NetCDF.NetCDFFile('episim_0100.nc','r')
infected=file.variables['Infected']
</pre>

Now we load the [http://matplotlib.sourceforge.net/ matplotlib] package, and create a new figure window. Ordinarily, doing this is unnecessary. Because we want the image to contain no borders, we must initialize the figure window to contain only the figure axis. Note that the figure must be created with the correct aspect ratio, or the image will contain borders. We will use a constant width of 5 inches and find the correct height by multiplying the aspect ratio of the input data (the number of rows divided by the number of columns of the variable).

<pre>
import pylab

width=5
height=width*float(infected.shape[0])/float(infected.shape[1])

fig=pylab.figure(figsize=(width,height))
fig.add_axes([0,0,1,1])
</pre>

This should have created an empty figure window. We are now able to generate image using the <code>imshow</code> command. Note that <code>imshow</code> draws the figure from top to bottom (like an image) so we must flip the data vertically (using <code>flipud</code>) prior to displaying. Also, we want to visualize the data on a log color scale, so we will take the logarithm of the data (<code>log 0</code> will show up as white in the figure).

<pre>
data=pylab.flipud(infected)
data=pylab.log(data)

pylab.imshow(data)
</pre>

Finally, we will turn off the axis to remove any remnants of tick marks from the display axis, and save the file to a png image named <code>Infected.png</code>.

<pre>
pylab.axis('off')
pylab.savefig('Infected.png')
</pre>

You should now have an image that is ready to use as an overlay in Google Earth.

=Creating a kml file=
External images can be included into Google Earth in a number of different ways. What we are interested in is displaying our image over the ground. This is what is known as a [http://code.google.com/apis/kml/documentation/kmlreference.html#groundoverlay GroundOverlay]. A minimal kml file which will do this with the <code>Infected.png</code> image we generated above is as follows.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<GroundOverlay>
<name>Infected</name>
<Icon>
<href>Infected.png</href>
</Icon>
<altitude>0.0</altitude>
<altitudeMode>clampToGround</altitudeMode>
<LatLonBox>
<north>14.958334</north>
<south>-10.000000</south>
<east>40.958336</east>
<west>16.000000</west>
<rotation>0.0</rotation>
</LatLonBox>
</GroundOverlay>
</kml>
</pre>

The primary components of this file are the name of image as it is displayed in the Google Earth menu, the <code>Icon</code> key which tells where to find the image, the <code>altitudeMode</code> key tells it to stretch the image of the ground. Finally, the <code>LatLonBox</code> tells Google Earth where to put the image. The image is assumed to be defined on a regular latitude/longitude grid (not projected). The keys give the lines of latitude and longitude where the edges of the image should be placed. For the EpiSim output files, this can be found by looking beginning and end of the variables <code>latitude</code> and <code>longitude</code>.

<pre>
In [1]: from Scientific.IO import NetCDF

In [2]: file=NetCDF.NetCDFFile('episim_0100.nc','r')

In [3]: lat=file.variables['latitude']

In [4]: lon=file.variables['longitude']

In [5]: lat[-1],lat[0],lon[-1],lon[0]
Out[5]: (14.958334, -10.0, 40.958336, 16.0)
</pre>

Many more features for displaying overlays are available in the kml standard. See the [http://code.google.com/apis/kml/documentation/kmlreference.html documentation] for further details.

=Creating preloaded WRF-Fire animations=
'''This is only for users who have older versions of Google Earth. If you have Google Earth 6, loading multiple images from KMZ files is no longer an issue.'''

If you have older versions of Google Earth, either download and update to [http://www.google.com/earth/download/ge/ Google Earth 6] or use [https://github.com/zhlin/WRF-GoogleEarth/blob/movScript/nc2kmz_GE5.py this script] for preloading multiple images, and use as follows:

<pre>
python nc2kmz_GE5.py <wrfout_filename>
</pre>

The preloading functionality is an extension of the ncEarth module that accomplishes preloading the set of images that is in KMZ files by adding a static copy of the [http://code.google.com/apis/kml/documentation/time.html#example2 animated GroundOverlays]. The static copy of GroundOverlays is without the [http://code.google.com/apis/kml/documentation/kmlreference.html#timespan TimeSpan] element. When opening preloaded animation KMZ files, Google Earth automatically loads all the static GroundOverlays which caches the images that are needed in the animation, and when it finishes loading the static GroundOverlays, the timeline slider will appear on the left top corner of the screen for playing the animation. Loading time depends on the number of GroundOverlays in the animation, and if the animation is very large in size, Google Earth may appear frozen while loading. Unfortunately, Google Earth does not provide a way to display a message to the users while loading.

=Creating WRF-Fire animation legend =
For conveying information, we will need a legend for the animation. First of all, get the script [https://github.com/zhlin/WRF-GoogleEarth/blob/master/colorbarImg.py here] to generate the image for the legend. Use it as the following example:
<pre>
import colorbarImg
colorbarImg.getImages('wrfout.nc','FGRNHFX')
</pre>
Passing the name of a dataset and the variable name, and the resulting images will be stored in a subfolder called “colorbarImages”.
After selecting a colorbar image, we can use [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay ScreenOverlay] to display the legend in a fixed position on the screen.
Here are some examples of ScreenOverlay.

Refers to an image at given URL:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>http://server.com/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="1" y="-1" xunits="fraction" yunits="fraction"/>
</ScreenOverlay>
</pre>

Refers to an image in the KMZ file folder:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<folder>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>files/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="-1" y="-1" xunits="fraction" yunits="fraction"/>
</folder>
</ScreenOverlay>
</pre>

The <code><Icon></code> element points to the image to be used. This image file can be located on a file system or on a web server. To position the overlay, change the x and y values of the <code><overlayXY></code> and <code><screenXY></code> elements, <code>overlayXY</code> maps a point in the image to a point on the screen specified by <code>screenXY</code>, the unit for x and y values can be one of three units: pixels, fraction, and insetPixels. Also the values can be specified in different ways, for example x can be in fraction and y can be in pixels. The <code><size></code> element determines the size of the ScreenOverlay, vaule of -1 indicates to use the images’ original dimension.
For more detailed explanation of ScreenOverlay’ elements, see [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay KML reference document].

=External links=

https://github.com/jbeezley/WRF-GoogleEarth
[[Category:Visualization]]
[[Category:WRF-Fire]]

Visualization in Google Earth

2011-08-08T04:36:01Z

Jbeezley: /* Python Class for creating WRF-Fire animations */

{{users guide}}
[http://www.google.com/earth/index.html Google Earth] is proprietary software from Google allowing the user to explore 3D imagery of the earth's surface. Using its native support for [http://code.google.com/apis/kml/documentation/ kml files], it is possible to overlay images from numerical simulations onto the surface of the earth. However, Google Earth is not designed to be a visualization suite for numerical models. It can't, for example, create a pseudo color image from raw data. One must generate a bitmap image (jpg or png) of the data first before it can be used in Google Earth. Once that is done, it is a simple matter of creating a kml file which tells google where to display the image on the ground.

=Generating an image from raw data=
When one generates a pseudocolor image from raw data, for example in Matlab using the <code>imshow</code> command, the image will usually contain a border with titles and axis labels. In order to align the image properly in Google Earth, we want just the image itself without any borders whatsoever. The easiest way to do this would be to open the image in Gimp and crop it manually; however, this is not suitable for generating a large number of visualizations or for an automated system.

==Using python and matplotlib==
The [http://www.python.org/ python] programming language contains a large number of packages useful for scientific computing and visualization. In particular, [http://matplotlib.sourceforge.net/ matplotlib] combines the numerical processing capabilities of [http://numpy.scipy.org/ numpy] with a full-featured 2D plotting package, which is very similar to Matlab's 2D plotting capabilities. In this example, we will use the function [http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow imshow] to generate a psuedo color image from some data in an [[EpiSim]] output file. In order to run this example yourself, you must have python with the [http://matplotlib.sourceforge.net/ matplotlib] and [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] (for reading the output [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files) packages installed.

When we run EpiSim, we are left with a series of [http://www.unidata.ucar.edu/software/netcdf/ NetCDF] files as output. These files contain the raw data from the model for a single time step. We want to create an image of the <code>Infected</code> variable from file <code>episim_0100.nc</code> to overlay onto Google Earth. We start by reading the file using the [http://sourcesup.cru.fr/projects/scientific-py/ Scientific Python] package.

<pre>
from Scientific.IO import NetCDF

file=NetCDF.NetCDFFile('episim_0100.nc','r')
infected=file.variables['Infected']
</pre>

Now we load the [http://matplotlib.sourceforge.net/ matplotlib] package, and create a new figure window. Ordinarily, doing this is unnecessary. Because we want the image to contain no borders, we must initialize the figure window to contain only the figure axis. Note that the figure must be created with the correct aspect ratio, or the image will contain borders. We will use a constant width of 5 inches and find the correct height by multiplying the aspect ratio of the input data (the number of rows divided by the number of columns of the variable).

<pre>
import pylab

width=5
height=width*float(infected.shape[0])/float(infected.shape[1])

fig=pylab.figure(figsize=(width,height))
fig.add_axes([0,0,1,1])
</pre>

This should have created an empty figure window. We are now able to generate image using the <code>imshow</code> command. Note that <code>imshow</code> draws the figure from top to bottom (like an image) so we must flip the data vertically (using <code>flipud</code>) prior to displaying. Also, we want to visualize the data on a log color scale, so we will take the logarithm of the data (<code>log 0</code> will show up as white in the figure).

<pre>
data=pylab.flipud(infected)
data=pylab.log(data)

pylab.imshow(data)
</pre>

Finally, we will turn off the axis to remove any remnants of tick marks from the display axis, and save the file to a png image named <code>Infected.png</code>.

<pre>
pylab.axis('off')
pylab.savefig('Infected.png')
</pre>

You should now have an image that is ready to use as an overlay in Google Earth.

=Creating a kml file=
External images can be included into Google Earth in a number of different ways. What we are interested in is displaying our image over the ground. This is what is known as a [http://code.google.com/apis/kml/documentation/kmlreference.html#groundoverlay GroundOverlay]. A minimal kml file which will do this with the <code>Infected.png</code> image we generated above is as follows.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<GroundOverlay>
<name>Infected</name>
<Icon>
<href>Infected.png</href>
</Icon>
<altitude>0.0</altitude>
<altitudeMode>clampToGround</altitudeMode>
<LatLonBox>
<north>14.958334</north>
<south>-10.000000</south>
<east>40.958336</east>
<west>16.000000</west>
<rotation>0.0</rotation>
</LatLonBox>
</GroundOverlay>
</kml>
</pre>

The primary components of this file are the name of image as it is displayed in the Google Earth menu, the <code>Icon</code> key which tells where to find the image, the <code>altitudeMode</code> key tells it to stretch the image of the ground. Finally, the <code>LatLonBox</code> tells Google Earth where to put the image. The image is assumed to be defined on a regular latitude/longitude grid (not projected). The keys give the lines of latitude and longitude where the edges of the image should be placed. For the EpiSim output files, this can be found by looking beginning and end of the variables <code>latitude</code> and <code>longitude</code>.

<pre>
In [1]: from Scientific.IO import NetCDF

In [2]: file=NetCDF.NetCDFFile('episim_0100.nc','r')

In [3]: lat=file.variables['latitude']

In [4]: lon=file.variables['longitude']

In [5]: lat[-1],lat[0],lon[-1],lon[0]
Out[5]: (14.958334, -10.0, 40.958336, 16.0)
</pre>

Many more features for displaying overlays are available in the kml standard. See the [http://code.google.com/apis/kml/documentation/kmlreference.html documentation] for further details.

=Creating preloaded WRF-Fire animations=
'''This is only for users who have older versions of Google Earth. If you have Google Earth 6, loading multiple images from KMZ files is no longer an issue.'''

If you have older versions of Google Earth, either download and update to [http://www.google.com/earth/download/ge/ Google Earth 6] or use [https://github.com/zhlin/WRF-GoogleEarth/blob/movScript/nc2kmz_GE5.py this script] for preloading multiple images, and use as follows:

<pre>
python nc2kmz_GE5.py <wrfout_filename>
</pre>

The preloading functionality is an extension of the ncEarth module that accomplishes preloading the set of images that is in KMZ files by adding a static copy of the [http://code.google.com/apis/kml/documentation/time.html#example2 animated GroundOverlays]. The static copy of GroundOverlays is without the [http://code.google.com/apis/kml/documentation/kmlreference.html#timespan TimeSpan] element. When opening preloaded animation KMZ files, Google Earth automatically loads all the static GroundOverlays which caches the images that are needed in the animation, and when it finishes loading the static GroundOverlays, the timeline slider will appear on the left top corner of the screen for playing the animation. Loading time depends on the number of GroundOverlays in the animation, and if the animation is very large in size, Google Earth may appear frozen while loading. Unfortunately, Google Earth does not provide a way to display a message to the users while loading.

=Creating WRF-Fire animation legend =
For conveying information, we will need a legend for the animation. First of all, get the script [https://github.com/zhlin/WRF-GoogleEarth/blob/master/colorbarImg.py here] to generate the image for the legend. Use it as the following example:
<pre>
import colorbarImg
colorbarImg.getImages('wrfout.nc','FGRNHFX')
</pre>
Passing the name of a dataset and the variable name, and the resulting images will be stored in a subfolder called “colorbarImages”.
After selecting a colorbar image, we can use [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay ScreenOverlay] to display the legend in a fixed position on the screen.
Here are some examples of ScreenOverlay.

Refers to an image at given URL:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>http://server.com/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="1" y="-1" xunits="fraction" yunits="fraction"/>
</ScreenOverlay>
</pre>

Refers to an image in the KMZ file folder:

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

<ScreenOverlay>
<folder>
<name>Legend name</name>
<color>ffffffff</color>
<Icon>
<href>files/legend.png</href>
</Icon>
<overlayXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<screenXY x="0" y="1" xunits="fraction" yunits="fraction"/>
<rotationXY x="0" y="0" xunits="fraction" yunits="fraction"/>
<size x="-1" y="-1" xunits="fraction" yunits="fraction"/>
</folder>
</ScreenOverlay>
</pre>

The <code><Icon></code> element points to the image to be used. This image file can be located on a file system or on a web server. To position the overlay, change the x and y values of the <code><overlayXY></code> and <code><screenXY></code> elements, <code>overlayXY</code> maps a point in the image to a point on the screen specified by <code>screenXY</code>, the unit for x and y values can be one of three units: pixels, fraction, and insetPixels. Also the values can be specified in different ways, for example x can be in fraction and y can be in pixels. The <code><size></code> element determines the size of the ScreenOverlay, vaule of -1 indicates to use the images’ original dimension.
For more detailed explanation of ScreenOverlay’ elements, see [http://code.google.com/apis/kml/documentation/kmlreference.html#screenoverlay KML reference document].

==External links==

https://github.com/jbeezley/WRF-GoogleEarth
[[Category:Visualization]]
[[Category:WRF-Fire]]

How to interpret WRF variables

2011-05-11T16:38:10Z

Jbeezley: /* Fire */ extra information about fire grid variables

==Grid==

[[File:Wrfgrid.png|250px]][[File:WRF_staggered_grid.gif|500px]]

Grids in WRF are logically rectilinear. Variables for WRF cell indexed '''(i,j,k)''' can be located at one of 4 possible points. You can tell where by looking at the WRF registry or the attributes of [[NetCDF]] files, which WRF uses as I/O format. You can also tell by the fact that staggered variables have the staggered dimension larger by one, since there needs to be variable at the last boundary face.
* at the center of the cell - theta points, not staggered
* at the center of the left face - U point, staggered in X
* at the center of the front face - V point, staggered in Y
* at the center of the bottom face - W point, staggered in Z
Scalar variables (such as thermodynamical variables, hence the theta: temperature, pressure,...) generally live at theta-points. One exception is the geopotential, which lives at W-points.
The documentation, some variable names, and comments in the WRF code also associate theta with the vertical position of the mid-plane of the cell and at W with the vertical position of the bottom of the cell.

The orientation of the axes in the real world, such as "east-west", in the order of increasing index, such as '''i''', are defined in the registry. For postprocessing, they can be found at runtime as attributes in the NetCDF files.

==Arrays==

Arrays are stored in files and in memory. All arrays are described in the Registry, which is a collection of text files in '''WRFV3/Registry'''. The variable names in memory and in files are sometimes different.

Files are (by default) in [[NetCDF]] format. The values associated with the cell '''(i,j,k)''' at time step '''n''' are stored in the files as the array entry '''u(i,j,k,n)''', e.t.c. The value of the time at the step '''n''' is stored in character array '''Times(:,n)'''.

While arrays in files are indexed as '''(i,j,k,n)''', arrays in memory are indexed as '''(i,k,j)''' by [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. Of course, there is no 4th index for the time step in arrays in memory, and in some arrays there is no vertical '''k''' dimension.

==Wind==

Components of the wind velocity vector '''U''', '''V''', '''W''' live at the corresponding points, hence the point names. These are in the geometrically horizontal and vertical directions. On flat ground, '''W''' on the first level ''k=1'' is zero. However, when the ground has nonzero slope, the vertical velocity components '''W''' is generally not zero, because the normal vector to the ground is not vertical.

Note that the picture above center and right (from [http://www.mmm.ucar.edu/wrf/users/docs/arw_v3.pdf WRF documentation]) use half integer indexing.
* The horizontal wind component '''Ui-1/2,j,k''' in the X direction is stored in the array entry '''u(i,j,k)'''
* The horizontal wind component '''Vi,j-1/2,k''' in the Y is stored in the array entry '''v(i,j,k)'''
* The vertical wind component '''Wi,j,k-1/2''' is stored in the array entry '''w(i,j,k)'''
In particular, the lowest layer in WRF is '''k=1''', and, on flat ground, '''w(:,:,1)=0''', since the ground is impermeable in the normal direction. On a ground with nonzero slope, '''w(:,:,1)=0''' is generally nonzero. The winds at the middle of the first layer, at the height '''eta1''', are '''u(:,:,1)''', '''v(:,:,1)''', and they are generally nonzero.

Because the components of the wind velocity vector are on different staggered grids, and visualization software usually expects all three components of the velocity vector based at the same point, they need to be interpolated to theta-points (cell centers) for display:
: '''U_THETA(i,j,k) = 0.5*(U(i,j,k) + U(i+1,j,k))'''
: '''V_THETA(i,j,k) = 0.5*(V(i,j,k) + V(i,j+1,k))'''
: '''W_THETA(i,j,k) = 0.5*(W(i,j,k) + W(i,j,k+1))'''

==Location==

The longitude and latitude of the theta and U nodes are given by arrays '''XLONG''' and '''XLAT''', which are set at initialization and then do not change. However the elevation has to be computed from the flow solution as [[wikipedia:Geopotential height|geopotential height]] by
: '''ELEVATION_W(i,j,k) = (PHB(i,j,k) + PH(i,j,k))/9.81
where '''PHB + PH''' is the [[wikipedia:geopotential|geopotential]]. '''PHB''' is constant, set at initialization, and '''PH''', called perturbation geopotential, starts as zero and varies with time.

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''HGT(i,j) = PHB(i,j,1)/9.81
up to rounding error.

To find the elevation of the cell theta-points (the cell midplane), you need to interpolate between the elevation of the top and the bottom:
:'''ELEVATION_THETA(i,j,k) =0.5*(PHB(i,j,k) + PH(i,j,k) + PHB(i,j,k+1) + PH(i,j,k+1))/9.81

==Temperature==

[[wikipedia:Potential temperature|Potential temperature]] in K is 300+'''T'''. The potential temperature is most suitable for visualization. However, the temperature as measured by instruments is sometimes needed for comparison. The potential temperature is converted by... ''coming soon''

==Pressure==

''coming soon''

==Fire==

[[File:firemesh.png|400px]]

The fire mesh is 2D. Every atmosphere cell is divided into '''sr_x''' by '''sr_y''' fire cells. The submesh ratios '''sr_x''' and '''sr_y''' are specified in the file '''namelist.input'''. These values are not stored in the NetCDF files, but can be computed from the dimension sizes.

sr_x=west_east_subgrid/west_east_stag = west_east_subgrid/(west_east + 1)
sr_y=south_north_subgrid/south_north_stag = south_north_subgrid/(south_north + 1)

For historical reasons, the fire grid dimensions in the output files are larger than what is actually used by the code internally. The extra space is at the end of the variables of size <code>sr_x</code> in <code>x</code> and <code>sr_y</code> in <code>y</code>. The following is an example of python code for correctly reading <code>FGRNHFX</code> from the file <code>wrfout</code>.

from netCDF4 import Dataset
f=Dataset('wrfout','r')
sr_x=len(f.dimensions['west_east_subgrid'])/(len(f.dimensions['west_east'])+1)
sr_y=len(f.dimensions['south_north_subgrid'])/(len(f.dimensions['south_north'])+1)
fgrnhfx=f.variables['FGRNHFX']
fgrnhfx=fgrnhfx[...,:-sr_y,:-sr_x]

Variables on the fire mesh are located at the centers of the fire mesh cells of a 2D fire mesh. The position of the centers is stored in the arrays '''FXLONG''' and '''FXLAT'''.

Fire variables important for visualization:

* '''FGRNHFX''' - heat flux from the ground fire. Higher value means a more intense fire, so it should be brighter.
* '''FUEL_FRAC''' - the fuel fraction remaning. 1 means no fire yet, so one can display the original ground colors. 0 or small means burned, so the ground can have a different color, e.g. it could be blackened.

See the [[Media:Users guide chap-wrf-fire.pdf|WRF-Fire user's guide]] for the description of all fire model variables.

==See also==

* [[WRF-Fire documentation]]
* [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#fields WRF output fields from the WRF-ARW user's guide]
* Grid: [http://www.mmm.ucar.edu/wrf/users/docs/arw_v3.pdf A Description of the Advanced Research WRF Version 3 (June 2008)] Fig 7.3 page 59
* [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF Coding Conventions]
* [http://www.mmm.ucar.edu/wrf/users/tutorial/200807/WRF%20Registry%20and%20Examples.pdf WRF Registry and Examples]
* [http://www.mmm.ucar.edu/wrf/WG2/software_v2/ WRF v2 Software Tools and Documentation] (there does not seem to be a document for V3?)
* [http://www.mmm.ucar.edu/wrf/WG2/software_2.0/registry_schaffer.pdf Description of WRF Registry]
* [http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fyosemite.epa.gov%2FR10%2Fairpage.nsf%2Fc36cf12146018ddc882569e5005f1951%2F75f93e40b30302fc88257408008069e9%2F%24FILE%2FBowman.pdf&ei=Xt5hTJH6MseNnQf9rd3NAQ&usg=AFQjCNHsnOPC4nuQjHikOMx4sm40IJMquw&sig2=_4BrV5z1fh0ahYC5s9_t0Q Moving from MM5 to WRF]

[[Category:WRF-Fire]]
[[Category:Howtos|Interpret WRF-Fire variables]]

Jbeezley/hurricane

2011-04-20T18:41:04Z

Jbeezley:

Jbeezley/hurricane

2011-04-19T23:48:11Z

Jbeezley:

<gallery perrow=3>
File:Hurricane SLP 001.png
File:Hurricane T 001.png
File:Hurricane wind 001.png
File:Hurricane SLP 002.png
File:Hurricane T 002.png
File:Hurricane wind 002.png
File:Hurricane SLP 003.png
File:Hurricane T 003.png
File:Hurricane wind 003.png
File:Hurricane SLP 004.png
File:Hurricane T 004.png
File:Hurricane wind 004.png
File:Hurricane SLP 005.png
File:Hurricane T 005.png
File:Hurricane wind 005.png
File:Hurricane SLP 006.png
File:Hurricane T 006.png
File:Hurricane wind 006.png
File:Hurricane SLP 007.png
File:Hurricane T 007.png
File:Hurricane wind 007.png
File:Hurricane SLP 008.png
File:Hurricane T 008.png
File:Hurricane wind 008.png
File:Hurricane SLP 009.png
File:Hurricane T 009.png
File:Hurricane wind 009.png
</gallery>

File:Hurricane wind 009.png

2011-04-19T22:06:26Z

Jbeezley: Hurricane ensemble data provided by Fuqing Zhang.