openwfm - User contributions [en]

Vertical wind interpolation

2025-09-11T00:31:32Z

Adamko: /* Options */

{{users guide}}
==Vertical log interpolation and wind reduction factors==
The wind speed that enters the spread rate formula is found by vertical interpolation to a specified height '''fwh''', sometimes called ''midflame height'', using the ideal logarithmic wind profile: the wind speed at height '''z''' is assumed to be proportional to log '''z/z0''', where '''z0''' is the ''roughness height'' (clearly, this is the height where the wind speed is zero). The special logarithmic interpolation we use preserves such functions just like linear interpolation preserves linear functions. The numbers '''fwh''' and '''z0''' need to be known at every point of the fire mesh.

In [[BEHAVE]], the wind is measured at 20ft (6.096m) and log interpolated to the midflame height. The interpolation is the same as multiplying the wind speed by a given ''wind reduction factor'' ([http://www.firemodels.org/downloads/behaveplus/publications/Baughman_and_Albini_1980_6thConFireForMet_EstMidflamWind.pdf Baughman and Albini, 1980]), which we denote by '''windrf'''.

See [http://www.geosci-model-dev.net/4/591/2011/gmd-4-591-2011.html Mandel et al. 2011] Sec. 5.2 for more details.

==Implementation==

In the code, we thus have two choices:
# [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L184 Interpolate] to 6.096m and [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L622 apply] the wind reduction factors. This is much simpler and faster.
# Interpolate the wind at each point of the fire mesh to the midflame height at that point [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L874 separately]. This is more complicated.

The vertical interpolation is somewhat complicated because of the way how WRF represents [[How_to_interpret_WRF-Fire_variables#Wind|the wind speed]] and [[How_to_interpret_WRF-Fire_variables#Location|the vertical coordinate]]. In particular, because the altitude of nodes in WRF changes during the run, the number of vertical levels needed for the interpolation is not known in advance.

==Data input==

In WRF, the roughness height '''z0''' is specified by the surface model in land use. This is typically taken from file [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/run/LANDUSE.TBL LANDUSE.TBL]. The values of the midflame height '''fwh''', the fuel roughness height '''fz0''', the wind reduction factors '''windrf''' for each fuel category, and the BEHAVE height '''fire_wind_height''', are specified in the file [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/test/em_fire/small/namelist.fire '''namelist.fire'''] as a part of the fuel properties. If these values are not given in the file, the [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_phys.F#L93 defaults] in the code apply.

Note that the roughness height '''z0''' from land use and '''fz0''' will be generally different, and besides they are given on different meshes.

==Options==

The interpolation mode is controlled by the values of the variables '''fire_wind_log_interp''' and '''fire_use_windrf''' in the file [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/test/em_fire/small/namelist.input#L180 '''namelist.input''']:
<pre>
fire_wind_log_interp = 1, ! 1 = from fuel categories, 2= roughness piecewise constant from atm, 3=bilinear from atm, 4=on atmosphere mesh
fire_use_windrf=2, ! if fire_wind_log_interp.ne.4: 0=ignore wind reduction factors, 1=multiply, 2=use to set fwh, 3=adjust fwh for z0
</pre>

Supported combinations of the options are listed below. In particular, do not use '''fire_use_windrf'''=1, which is for experiments only.

===Interpolation to common height and wind reduction factors===

* '''fire_wind_log_interp'''=4, '''fire_use_windrf''' is not used: vertical log interpolation on the atmospheric mesh to '''fire_wind_height''' with '''z0''' from land use, the interpolated wind speed is then multiplied by '''windrf''' at every fire mesh node. The values of '''fwh''' and '''fz0''' are ignored.

===Interpolation to different heights on the fire mesh===

The following group of combinations of options controls the interpolation by the wind reduction factor '''windrf'''; '''fwh''' is not used.

* '''fire_wind_log_interp'''=1, '''fire_use_windrf'''=2: use the roughness height '''fz0''' from fuel categories, ignore '''fwh''' and [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L786 set it automatically] to the height that corresponds to the given '''windrf'''.
* '''fire_wind_log_interp'''=2, '''fire_use_windrf'''=2: the same, but using roughness height '''z0''' interpolated from land use as piecewise constant, ignore '''fz0'''.
* '''fire_wind_log_interp'''=3, '''fire_use_windrf'''=2: the same, but using roughness height '''z0''' interpolated from land use as piecewise bilinear, ignore '''fz0'''.

The above options will produce similar results as the interpolation to common height and using wind reduction factors; the only difference is from the wind not obeying the log profile exactly. In particular, if the first WRF level is above the '''fire_wind_height''' (of 6.096m, which is usually the case), these three option will give ''the same result as the interpolation on the atmospheric mesh and multiplication by the wind reduction factors'', except for slight differences caused by a different technique used for the interpolation of the atmospheric variables, and by rounding errors.

The combinations of options below control the interpolation by the midflame height '''fwh''', and all three will again produce similar results; '''windrf''' is not used.

* '''fire_wind_log_interp'''=1, '''fire_use_windrf'''=0: Use the values of '''fwh''' and '''fz0''' as given.
* '''fire_wind_log_interp'''=2, '''fire_use_windrf'''=3: Interpolate '''z0''' as piecewise constant and adjust '''fwh''' for a similar result as with '''fz0'''.
* '''fire_wind_log_interp'''=3, '''fire_use_windrf'''=3: Interpolate '''z0''' as piecewise bilinear and adjust '''fwh''' for a similar result as with '''fz0'''.

The adjustment of '''fwh''' is done by first [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L809 computing] the wind reduction factor when going from '''fire_wind_height''' to the given height '''fwh''' with the given roughness '''fz0''', then [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/wrfv2_fire/phys/module_fr_sfire_atm.F#L809 changing] '''fwh''' to the value that corresponds to the same wind reduction factor but with the interpolated '''z0'''.

==Diagnostics==

You can use function [https://github.com/jbeezley/wrf-fire/blob/e062dbf62b7591e71a486a7c512efd75e48ed9a1/other/Matlab/vis3d/vprofile.m '''vprofile'''] in [[Matlab]] ('''cd em_fire''', '''matlab''', help '''vprofile''') to view the resulting wind profiles and the computed value of '''fwh'''. See [[How to visualize vertical profiles from WRF in Matlab]] for details.

==References==
#Robert G. Baughman and Frank A. Albini, Estimating Midflame Windspeeds, Sixth Conference on Fire and Forest Meteorology, Seattle, WA April 22-24, 1980, pp. 88-92 [http://www.firemodels.org/downloads/behaveplus/publications/Baughman_and_Albini_1980_6thConFireForMet_EstMidflamWind.pdf pdf]
#Jan Mandel, Jonathan D. Beezley, and Adam K. Kochanski, [http://www.geosci-model-dev.net/4/591/2011/gmd-4-591-2011.html '''Coupled atmosphere-wildland fire modeling with WRF 3.3 and SFIRE 2011'''], [http://www.geoscientific-model-development.net Geoscientific Model Development (GMD)] 4, 591-610, 2011. {{doi|10.5194/gmd-4-591-2011}}

==Works with==
* {{WRF-Fire-commit|e062dbf62b7591e71a48|SFIRE July 31, 2011}}. In particular, note that these options are not present in WRF-Fire in WRF 3.3 release; the interpolation to different heights on the fire mesh was not implemented yet, and the wind factors were [[Changes in WRF-Fire 3.3 release|removed from the release]].
* Matlab 2011a
[[Category:WRF-Fire]]

FireFlux Dataset

2022-06-10T17:09:03Z

Adamko:

Clements, C. B., S. Zhong, S. Goodrick, J. Li, X. Bian, B.E. Potter, W. E. Heilman, J.J. Charney, R. Perna, M. Jang, D. Lee, M.Patel,S. Street and G. Aumann, 2007: "[http://ams.allenpress.com/perlserv/?request=get-abstract&doi=10.1175/BAMS-88-9-1369&ct=1 Observing the Dynamics of Wildland Grass Fires: FireFlux- A Field Validation Experiment.]" Bulletin of the American Meteorological Society , 88(9),1369-1382.

[[http://demo.openwfm.org/web/wiki/FireFlux_data.zip Fire Flux Dataset]]

[[Category:Data]]

How to convert data for Geogrid

2021-02-17T01:59:28Z

Adamko: /* Install environment */

{{users guide}}

This wiki page explains how to transform geotiff files to geogrid using convert_geotiff script in [https://github.com/openwfm/wrfxpy.git wrfxpy].

== Get Anaconda3 distribution ==

Download and install the Python 3 [https://www.anaconda.com/products/individual Anaconda Python] distribution for your platform. We recommend an installation into the user's home directory.

== Install environment ==

Create the python environment:

<pre>
conda update -n base -c defaults conda
conda create -n wrfx python=3 gdal netcdf4 pyproj paramiko dill h5py psutil proj4 pytz flask pandas
conda activate wrfx
conda install -c conda-forge simplekml pygrib f90nml pyhdf xmltodict basemap rasterio scipy
pip install MesoPy python-cmr
</pre>

Note that <tt>conda</tt> and <tt>pip</tt> are package managers available in the Anaconda Python distribution.

== Get wrfxpy repository ==

Get repository wrfxpy and checkout to convert_geotiff branch. Shortly, it is going to be available in the master branch.
git clone https://github.com/openwfm/wrfxpy
cd wrfxpy
git checkout convert_geotiff

== Run convert_geotiff.sh ==

Run the code to generate geogrid from geotiff files. Run the following line for each variable to process.
./convert_geotiff.sh geotiff_file geo_data_path wrf_variable_name [bbox]

where:

* <tt>geotiff_file</tt> - path to a geotiff file to be converted to geogrid
* <tt>geo_data_path</tt> - any path where to save all the variables
* <tt>wrf_variable</tt> - WRF variable created on src/geo/var_wisdom.py
* <tt>bbox</tt> - optional, bounding box to sample the original geotiff file from, using WGS84 coordinates. Format: min_lon,max_lon,min_lat,max_lat

If you want to know more information and the existing options for wrf_variable, run ./convert_geotiff.sh without inputs
./convert_geotiff.sh

Some examples:
./convert_geotiff.sh elevation.tif geo_data ZSF
./convert_geotiff.sh fuel.tif geo_data NFUEL_CAT
./convert_geotiff.sh fuel.tif geo_data NFUEL_CAT -112.8115,-112.1661,39.4820,39.9750

== Results from convert_geotiff.sh ==

The convert_geotiff.sh script will generate a folder specified by the user by <tt>geo_data_path</tt> with

* '''Variable folders:''' A folder for each variable previously run (ZSF and NFUEL_CAT folders) containing:
** a geogrid file of the variable.
** an index file of the variable.
* '''geogrid_tbl.json:''' A JSON file with all the geogrid information for each variable.
* '''GEOGRID.TBL:''' A text file with the information to add to GEOGRID.TBL (depends on src/geo/var_wisdom.py, so only copy what you need).
* '''index.json:''' A JSON file with index information for each variable.

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

How to convert data for Geogrid

2021-02-13T19:31:36Z

Adamko: /* Get wrfxpy repository */

{{users guide}}

This wiki page explains how to transform geotiff files to geogrid using convert_geotiff script in [https://github.com/openwfm/wrfxpy.git wrfxpy].

== Get Anaconda3 distribution ==

Download and install the Python 3 [https://www.anaconda.com/products/individual Anaconda Python] distribution for your platform. We recommend an installation into the user's home directory.

== Install environment ==

Create the python environment:

<pre>
conda update -n base -c defaults conda
conda create -n wrfx python=3 gdal netcdf4 pyproj paramiko dill h5py psutil proj4 pytz flask pandas
conda activate wrfx
conda install -c conda-forge simplekml pygrib f90nml pyhdf xmltodict basemap rasterio
pip install MesoPy python-cmr
</pre>

Note that <tt>conda</tt> and <tt>pip</tt> are package managers available in the Anaconda Python distribution.

== Get wrfxpy repository ==

Get repository wrfxpy and checkout to convert_geotiff branch. Shortly, it is going to be available in the master branch.
git clone https://github.com/openwfm/wrfxpy
cd wrfxpy
git checkout convert_geotiff

== Run convert_geotiff.sh ==

Run the code to generate geogrid from geotiff files. Run the following line for each variable to process.
./convert_geotiff.sh geotiff_file geo_data_path wrf_variable_name [bbox]

where:

* <tt>geotiff_file</tt> - path to a geotiff file to be converted to geogrid
* <tt>geo_data_path</tt> - any path where to save all the variables
* <tt>wrf_variable</tt> - WRF variable created on src/geo/var_wisdom.py
* <tt>bbox</tt> - optional, bounding box to sample the original geotiff file from, using WGS84 coordinates. Format: min_lon,max_lon,min_lat,max_lat

If you want to know more information and the existing options for wrf_variable, run ./convert_geotiff.sh without inputs
./convert_geotiff.sh

Some examples:
./convert_geotiff.sh elevation.tif geo_data ZSF
./convert_geotiff.sh fuel.tif geo_data NFUEL_CAT
./convert_geotiff.sh fuel.tif geo_data NFUEL_CAT -112.8115,-112.1661,39.4820,39.9750

== Results from convert_geotiff.sh ==

The convert_geotiff.sh script will generate a folder specified by the user by <tt>geo_data_path</tt> with

* '''Variable folders:''' A folder for each variable previously run (ZSF and NFUEL_CAT folders) containing:
** a geogrid file of the variable.
** an index file of the variable.
* '''geogrid_tbl.json:''' A JSON file with all the geogrid information for each variable.
* '''GEOGRID.TBL:''' A text file with the information to add to GEOGRID.TBL (depends on src/geo/var_wisdom.py, so only copy what you need).
* '''index.json:''' A JSON file with index information for each variable.

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

Running WRF-SFIRE with real data in the WRFx system

2020-08-24T15:15:28Z

Adamko: /* Get static data */

Instructions to set up the whole WRFx system right now using the last version of all the components with a couple of working examples. WRFx consists of a Fortran coupled atmosphere-fire model [https://github.com/openwfm/wrf-fire WRF-SFIRE], a python automatic HPC system [https://github.com/openwfm/wrfxpy wrfxpy], a visualization web interface [https://github.com/openwfm/wrfxweb wrfxweb], and a simulation web interface [https://github.com/openwfm/wrfxctrl wrfxctrl].

=WRF-SFIRE model=

A coupled weather-fire forecasting model built on top of Weather Research and Forecasting (WRF).

==WRF-SFIRE: Requirements and environment==

===Install required libraries===
* General requirements:
** C-shell
** Traditional UNIX utilities: zip, tar, make, etc.
* WRF-SFIRE requirements:
** Fortran and C compilers (Intel recomended)
** MPI (compiled using the same compiler, usually comes with the system)
** NetCDF libraries (compiled using the same compiler)
* WPS requirements:
** zlib compression library (zlib)
** PNG reference library (libpng)
** JasPer compression library
** libtiff and geotiff libraries

See https://www2.mmm.ucar.edu/wrf/users/prepare_for_compilation.html for the required versions of the libraries.

===Set environment===
Set specific libraries installed
setenv NETCDF /path/to/netcdf
setenv JASPERLIB /path/to/jasper/lib
setenv JASPERINC /path/to/jasper/include
setenv LIBTIFF /path/to/libtiff
setenv GEOTIFF /path/to/libtiff
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
Should your executables fail on unresolved libraries, also add all the library folders into your LD_LIBRARY_PATH:
setenv LD_LIBRARY_PATH /path/to/netcdf/lib:/path/to/jasper/lib:/path/to/libtiff/lib:/path/to/geotiff/lib:$LD_LIBRARY_PATH

==WRF-SFIRE: Installation==
===Clone github repositories===
Clone WRF-SFIRE and WPS github repositories
git clone <nowiki>https://github.com/openwfm/WRF-SFIRE</nowiki>
git clone <nowiki>https://github.com/openwfm/WPS</nowiki>

===Configure WRF-SFIRE===
cd WRF-SFIRE
./configure

Options 15 (INTEL ifort/icc dmpar) and 1 (simple nesting) if available

===Compile WRF-SFIRE===
Compile em_real
./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log

If any compilation error, compile em_fire
./compile em_fire >& compile_em_fire.log &
grep Error compile_em_fire.log

If any of the previous step fails:
./clean -a
./configure
Add to configure.wrf -nostdinc at the end of the CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Configure WPS===
cd ../WPS
./configure

Option 17 (Intel compiler (serial)) if available

===Compile WPS===
./compile >& compile_wps.log &
grep Error compile_wps.log

and
ls -l *.exe

should contain geogrid.exe, metgrid.exe, and ungrib.exe. If not
./clean -a
./configure
Add to configure.wps -nostdinc at the end of CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Get static data===
Get tar file with the static data and untar it. Keep in mind that this is the file that contains landuse, elevation, soiltype data, etc for WRF (geogrid.exe to be psecific).
cd ..
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/WPS_GEOG.tbz</nowiki>
tar xvfj WPS_GEOG.tbz

=WRFx system=

==WRFx: Requirements and environment==

===Install Anaconda distribution===
Download and install the Python 3 [https://repo.continuum.io/archive Anaconda Python] distribution for your platform. We recommend an installation into the users' home directory.
wget <nowiki>https://repo.continuum.io/archive/Anaconda3-2020.02-Linux-x86_64.sh</nowiki>
chmod +x Anaconda3-2020.02-Linux-x86_64.sh
./Anaconda3-2020.02-Linux-x86_64.sh

===Install necessary packages===
We recommend the creation of an environment. Install pre-requisites:
conda update -n base -c defaults conda
conda create -n wrfx python=3 gdal netcdf4 pyproj paramiko dill h5py psutil proj4 pytz scipy matplotlib flask
conda activate wrfx
conda install -c conda-forge simplekml pygrib f90nml pyhdf xmltodict basemap rasterio
pip install MesoPy python-cmr

Note that conda and pip are package managers available in the Anaconda Python distribution.

===Set environment===
If you created the wrfx environment as shown above, check that PROJ_LIB path is pointing to
$HOME/anaconda3/envs/wrfx/share/proj
If not, you can try setting it to
setenv PROJ_LIB "$HOME/anaconda3/share/proj"

==WRFx: wrfxpy==

WRF-SFIRE forecasting and data assimilation in python using an HPC environment.

===wrfxpy: Installation===
====Clone github repository====
Clone wrfxpy repository
git clone <nowiki>https://github.com/openwfm/wrfxpy</nowiki>
Change to the directory where the wrfxpy repository has been created
cd wrfxpy
and in wrxpy folder
git checkout angel

====General configuration====
An etc/conf.json file must be created with the keys discussed below. A template file etc/conf.json.initial is provided as a starting point.

cd wrfxpy
cp etc/conf.json.initial etc/conf.json

Configure the queuing system, system directories, WPS/WRF-SFIRE locations, and workspace locations by editing the following keys in etc/conf.json:
"qsys": "key from clusters.json",
"wps_install_path": "/path/to/WPS",
"wrf_install_path": "/path/to/WRF",
"sys_install_path": "/path/to/wrfxpy"
"wps_geog_path" : "/path/to/WPS_GEOG",
"wget" : /path/to/wget"

Note that all these paths are created from previous steps of this wiki except the wget path, which needs to be specified to use a preferred version. To find the default wget,
which wget

====Cluster configuration====

Next, wrfxpy needs to know how jobs are submitted on your cluster. Create an entry for your cluster in etc/clusters.json, here we use speedy as an example:

{
"speedy" : {
"qsub_cmd" : "qsub",
"qdel_cmd" : "qdel",
"qstat_cmd" : "qstat",
"qstat_arg" : "",
"qsub_delimiter" : ".",
"qsub_job_num_index" : 0,
"qsub_script" : "etc/qsub/speedy.sub"
}
}

And then the file etc/qsub/speedy.sub should contain a submission script template, that makes use of the following variables supplied by wrfxpy based on job configuration:

%(nodes)d the number of nodes requested
%(ppn)d the number of processors per node requested
%(wall_time_hrs)d the number of hours requested
%(exec_path)d the path to the wrf.exe that should be executed
%(cwd)d the job working directory
%(task_id)d a task id that can be used to identify the job
%(np)d the total number of processes requested, equals nodes x ppn

Note that not all keys need to be used, as shown in the speedy example:

#$ -S /bin/bash
#$ -N %(task_id)s
#$ -wd %(cwd)s
#$ -l h_rt=%(wall_time_hrs)d:00:00
#$ -pe mpich %(np)d
mpirun_rsh -np %(np)d -hostfile $TMPDIR/machines %(exec_path)s

The script template should be derived from a working submission script.

Note: wrfxpy has already configuration for colibri, gross, kingspeak, and cheyenne.

====Tokens configuration====

When running wrfxpy, sometimes the data needs to be accessed and downloaded using a specific token created for the user. For instance, in the case of running the Fuel Moisture Model, one needs a token from a valid [https://simplekml.readthedocs.org/en/latest MesoWest] user to download data automatically. Also, when downloading satellite data, one needs a token from an [https://earthdata.nasa.gov/ Earthdata] user. All of these can be specified with the creation of the file etc/tokens.json from the template etc/tokens.json.initial containing:

{
"mesowest" : "token-from-mesowest",
"appkey" : "token-from-earthdata"
}

So, if any of the previous capabilities are required, create a token from the specific page, do

cp etc/tokens.json.initial etc/tokens.json

and edit the file to include your previously created token.

For running fuel moisture model, a new MesoWest user can be created in [https://mesowest.utah.edu/cgi-bin/droman/my_join.cgi?came_from=http://mesowest.utah.edu MesoWest New User]. Then, the token can be acquired and replaced in the etc/tokens.json file.

For acquiring satellite data, a new Earthdata user can be created in [https://urs.earthdata.nasa.gov/users/new Earthdata New User]. Then, the token can be acquired and replaced in the etc/tokens.json file. There are some data centers that need to be accessed using the $HOME/.netrc file. Therefore, creating the $HOME/.netrc file is recommended as follows

machine urs.earthdata.nasa.gov
login your_earthdata_id
password your_earthdata_password

====Get static data====

When running WRF-SFIRE simulations, one needs to use high-resolution elevation and fuel category data. If you have a GeoTIFF file for elevation and fuel, you can specify the location of these files using etc/vtables/geo_vars.json. So, you can do

cp etc/vtables/geo_vars.json.initial etc/vtables/geo_vars.json

and add the absolute path to your GeoTIFF files. The routine is going to automatically process these files and convert them into geogrid files to fit WPS. If you need to map the categories from the GeoTIFF files to the 13 Rothermel categories, you can modify the dictionary _var_wisdom on file src/geo/var_wisdom.py to specify the mapping. By default, the categories form the LANDFIRE dataset are going to be mapped according to 13 Rothermel categories. You can also specify what categories you want to interpolate using nearest neighbors. Therefore, the ones that you cannot map to 13 Rothermel categories. Finally, you can specify what categories should be no burnable using category 14.

To get GeoTIFF files from CONUS, you can use the LANDFIRE dataset following the steps on [[How_to_run_WRF-SFIRE_with_real_data#Obtaining_data_for_geogrid]]. Or you can just use the GeoTIFF files included in the static dataset WPS_GEOG/fuel_cat_fire and WPS_GEOG/topo_fire specifying in etc/vtables/geo_vars.json

{
"NFUEL_CAT": "/path/to/WPS_GEOG/fuel_cat_fire/lf_data.tif",
"ZSF": "/path/to/WPS_GEOG/topo_fire/ned_data.tif"
}

For running fuel moisture model, terrain static data is needed. '''This is a separate file from the static data downloaded for WRF.''' To get the static data for the fuel moisture model, go to wrfxpy and do:
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/static.tbz</nowiki>
tar xvfj static.tbz
this will untar a static folder with the static terrain on it.

This dataset is needed for the fuel moisture data assimilation system. The fuel moisture model run as a part of WRF-SFIRE doesn't need this dataset and uses data processed by WPS.

===wrxpy: Testing===
====Simple forecast====
At this point, one should be able to run wrfxpy with a simple example:
conda activate wrfxpy
./simple_forecast.sh
Press enter at all the steps to set everything to the default values until the queuing system, then we select the cluster we configure (speedy in the example).

This will generate a job under jobs/experiment.json (or the name of the experiment that we chose).

Then, we can run our first forecast by
./forecast.sh jobs/experiment.json >& logs/experiment.log &

Show generate the experiment in the path specified in the etc/conf.json file and under a folder using the experiment name. The file logs/experiment.log should show the whole process step by step without any error.

====Fuel moisture model====
If tokens.json is set, "mesowest" token is provided, and static data is gotten, you can run
./rtma_cycler.sh anything >& logs/rtma_cycler.log &
which will download all the necessary weather stations and estimate the fuel moisture model in the whole continental US.

===wrfxpy: Possible errors===
====real.exe fails====

Depending on the cluster, wrfxpy could fail when tries to execute ./real.exe. This happens on systems that do not allow executing MPI binary from the command line. We do not run real.exe by mpirun because mpirun on head node may not be allowed. Then, one needs to provide an installation of WRF-SFIRE in serial mode in order to run real.exe in serial. In that case, we want to repeat the [[Setting_up_current_WRFx_system#Installation|previous steps]] but using the serial version of WRF-SFIRE
cd ..
git clone <nowiki>https://github.com/openwfm/wrf-fire wrf-fire-serial</nowiki>
cd wrf-fire-serial/wrfv2_fire
./configure
Options 13 (INTEL ifort/icc serial) and 0 (no nesting)

./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log
Again, if any of the previous step fails:
./clean -a
./configure
Add -nostdinc in CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

Note: This time, we only need to compile em_real because we only need real.exe. However, if you want to test serial vs parallel for any reason, you can proceed to compile em_fire the same way.

Then, we need to add this path in etc/conf.json file in wrfxpy, so
cd ../wrfxpy
and add to etc/conf.json file key
"wrf_serial_install_path": "/path/to/WRF/serial"

This should solve the problem, if not check log files from previous compilations.

==WRFx: wrfxweb==

Web-based visualization system for imagery generated by wrfxpy.

===wrfxweb: Account creation===

Create ~/.ssh directory (if you have not one)
mkdir ~/.ssh
cd ~/.ssh

Create an id_rsa key (if you have not one) doing
ssh-keygen
and following all the steps (you can select defaults, so always press enter).

Send an email to Jan Mandel (jan.mandel@gmail.com) asking for the creation of an account in demo server providing:
* Purpose of your request (including information about you)
* User id you would like (user_id)
* Short user id you would like (short_user_id)
* Public key (~/.ssh/id_rsa.pub file previously created)

After that, you will receive an answer from Jan and you will be able to ssh the demo server without any password (only the passcode from the id_rsa key if you set one).

===wrfxweb: Installation===

====Clone github repository====
Clone wrfxweb repository in the demo server
ssh user_id@demo.openwfm.org
git clone <nowiki>https://github.com/openwfm/wrfxweb.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxweb
cp etc/conf.json.template etc/conf.json

Configure the following key in etc/conf.json:
"url_root": "<nowiki>http://demo.openwfm.org/short_user_id</nowiki>"

The next steps are going to be set in a desired installation of wrfxpy (generated in the previous section).

Configure the following keys in etc/conf.json in any wrfxpy installation
"shuttle_ssh_key": "/path/to/id_rsa"
"shuttle_remote_user": "user_id"
"shuttle_remote_host": "demo.openwfm.org"
"shuttle_remote_root": "/path/to/remote/storage/directory"
"shuttle_lock_path": "/tmp/short_user_id"

The "shuttle_remote_root" key is usually defined as "/home/user_id/wrfxweb/fdds/simulations". So, everything should be ready to send post-processing simulations into the visualization server.

===wrfxweb: Testing===
====Simple forecast====
Finally, one can repeat the previous [[Setting_up_current_WRFx_system#Simple_forecast|simple forecast test]] but when simple forecast asks
Send variables to visualization server? [default=no]
you will answer yes.

Then, you should see your simulation post-processed time steps appearing in real-time on http://demo.openwfm.org under your short_user_id.

====Fuel moisture model====
The [[Setting_up_current_WRFx_system#Fuel_moisture_model|fuel moisture model test]] can be also run and a special visualization will appear on http://demo.openwfm.org under your short_user_id.

==WRFx: wrfxctrl==

A website that enables users to submit jobs to the wrfxpy framework for fire simulation.

===wrfxctrl: Installation===

====Clone github repository====
Clone wrfxctrl repository in your cluster
git clone <nowiki>https://github.com/openwfm/wrfxctrl.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxctrl
cp etc/conf-template.json etc/conf.json

Configure following keys in etc/conf.json
"host" : "127.1.2.3",
"port" : "5050",
"root" : "/short_user_id/",
"wrfxweb_url" : "<nowiki>http://demo.openwfm.org/short_user_id/</nowiki>",
"wrfxpy_path" : "/path/to/wrfxpy",
"jobs_path" : "/path/to/jobs",
"logs_path" : "/path/to/logs",
"sims_path" : "/path/to/sims"
Notes:
* Entries "host", "port", "root" are only examples but, for security reasons, you should choose different ones of your own and as random as possible.
* Entries "jobs_path", "logs_path", and "sims_path" are recommended to be removed. By default they are defined to be in wrfxctrl directories wrfxctrl/jobs, wrfxctrl/logs, and wrfxctrl/simulations.

===wrfxctrl: Testing===

====Running wrfxctrl====

Activate conda environment and run wrfxctrl.py doing

conda activate wrfx
python wrfxctrl.py

This will show a message similar to

Welcome page is <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki>
* Serving Flask app "wrfxctrl" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
INFO:werkzeug: * Running on <nowiki>http://127.1.2.3:5050/</nowiki> (Press CTRL+C to quit)

====Starting page====

Now you can go to your favorite internet browser and navigate to <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki> webpage. This will show you a screen similar than that

[[File:Start.png|400px|center]]
 

This starting page shows general information of the cluster and provides an option of starting a new fire using ''Start a new fire'' button and browsing the existent jobs using the ''Show current jobs'' button.

====Submission page====

From the previous page, if you select ''Start a new fire'', you will be able to access the submission page. In this page, you can specify 1) a short description of the simulation, 2) the ignition location clicking in an interactive map or specifying the degree lat-lon coordinates, 3) the ignition time and the forecast length, 4) the simulation profile which defines the number of domains with their resolutions and sizes and the atmospheric boundary conditions data. Finally, once you have all the simulation options defined, you can scroll down to the end (next figure) and select the ''Ignite'' button. This will automatically show the monitor page where you will be able to track the progress of the simulation. See the image below to see an example of a simulation submission.

[[File:Submit1.png|400px|center]][[File:Submit2.png|400px|center]][[File:Submit3.png|402px|center]]
 

====Monitoring page====

At the beginning of the monitoring page, you will see a list of important information about the simulation (see figure below). After the information, there is a list of steps with their current status. The different possible statuses are:

* Waiting (grey): Represent that the process has not started and needs to wait for the other process. All the processes are initialized with this status.
* Running (yellow): Represent that the process is still running so in progress. All processes switch their status from Waiting to Running when they start running.
* Success (green): Represent that the process finished well. All processes switch their status from Running to Success when they finish running successfully.
* Available (green): Represent that some part is done and some other is still in progress. This status is only used by the Output process because the visualization is available once the process starts running.
* Failed (red): Represent that the process finished with a failure. All processes switch their status from Running to Failed when they finish running with a failure.

In the monitor page, the log file can be also retrieved clicking the ''Retrieve log'' button at the end of the page, which provides a scroll down window with the log file information.

[[File:Monitor1.png|502px|center]][[File:Monitor2.png|500px|center]][[File:Monitor3.png|500px|center]]
 

Finally, once the Output process becomes Available, in the ''Visualization'' element of the information section will appear a link to the simulation in the web server generated using wrfxweb. In this page, one can interactively plot the results in real-time while the simulation is still running

[[File:Visualization.png|500px|center]]
 

====Overview page====

From most of the previous pages, you can navigate to the current jobs which shows a list of jobs that are running and it allows the user to cancel or delete any simulation that has run or is running.

[[File:Overview.png|500px|center]]

Running WRF-SFIRE with real data in the WRFx system

2020-08-24T15:05:10Z

Adamko: /* Clone github repository */

Instructions to set up the whole WRFx system right now using the last version of all the components with a couple of working examples. WRFx consists of a Fortran coupled atmosphere-fire model [https://github.com/openwfm/wrf-fire WRF-SFIRE], a python automatic HPC system [https://github.com/openwfm/wrfxpy wrfxpy], a visualization web interface [https://github.com/openwfm/wrfxweb wrfxweb], and a simulation web interface [https://github.com/openwfm/wrfxctrl wrfxctrl].

=WRF-SFIRE model=

A coupled weather-fire forecasting model built on top of Weather Research and Forecasting (WRF).

==WRF-SFIRE: Requirements and environment==

===Install required libraries===
* General requirements:
** C-shell
** Traditional UNIX utilities: zip, tar, make, etc.
* WRF-SFIRE requirements:
** Fortran and C compilers (Intel recomended)
** MPI (compiled using the same compiler, usually comes with the system)
** NetCDF libraries (compiled using the same compiler)
* WPS requirements:
** zlib compression library (zlib)
** PNG reference library (libpng)
** JasPer compression library
** libtiff and geotiff libraries

See https://www2.mmm.ucar.edu/wrf/users/prepare_for_compilation.html for the required versions of the libraries.

===Set environment===
Set specific libraries installed
setenv NETCDF /path/to/netcdf
setenv JASPERLIB /path/to/jasper/lib
setenv JASPERINC /path/to/jasper/include
setenv LIBTIFF /path/to/libtiff
setenv GEOTIFF /path/to/libtiff
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
Should your executables fail on unresolved libraries, also add all the library folders into your LD_LIBRARY_PATH:
setenv LD_LIBRARY_PATH /path/to/netcdf/lib:/path/to/jasper/lib:/path/to/libtiff/lib:/path/to/geotiff/lib:$LD_LIBRARY_PATH

==WRF-SFIRE: Installation==
===Clone github repositories===
Clone WRF-SFIRE and WPS github repositories
git clone <nowiki>https://github.com/openwfm/WRF-SFIRE</nowiki>
git clone <nowiki>https://github.com/openwfm/WPS</nowiki>

===Configure WRF-SFIRE===
cd WRF-SFIRE
./configure

Options 15 (INTEL ifort/icc dmpar) and 1 (simple nesting) if available

===Compile WRF-SFIRE===
Compile em_real
./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log

If any compilation error, compile em_fire
./compile em_fire >& compile_em_fire.log &
grep Error compile_em_fire.log

If any of the previous step fails:
./clean -a
./configure
Add to configure.wrf -nostdinc at the end of the CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Configure WPS===
cd ../WPS
./configure

Option 17 (Intel compiler (serial)) if available

===Compile WPS===
./compile >& compile_wps.log &
grep Error compile_wps.log

and
ls -l *.exe

should contain geogrid.exe, metgrid.exe, and ungrib.exe. If not
./clean -a
./configure
Add to configure.wps -nostdinc at the end of CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Get static data===
Get tar file with the static data and untar it. Keep in mind that this is the file that contains landuse, elevation, soiltype data, etc for WRF (geogrid.exe to be psecific).
cd ..
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/WPS_GEOG.tbz</nowiki>
tar xvfj WPS_GEOG.tbz

=WRFx system=

==WRFx: Requirements and environment==

===Install Anaconda distribution===
Download and install the Python 3 [https://repo.continuum.io/archive Anaconda Python] distribution for your platform. We recommend an installation into the users' home directory.
wget <nowiki>https://repo.continuum.io/archive/Anaconda3-2020.02-Linux-x86_64.sh</nowiki>
chmod +x Anaconda3-2020.02-Linux-x86_64.sh
./Anaconda3-2020.02-Linux-x86_64.sh

===Install necessary packages===
We recommend the creation of an environment. Install pre-requisites:
conda update -n base -c defaults conda
conda create -n wrfx python=3 gdal netcdf4 pyproj paramiko dill h5py psutil proj4 pytz scipy matplotlib flask
conda activate wrfx
conda install -c conda-forge simplekml pygrib f90nml pyhdf xmltodict basemap rasterio
pip install MesoPy python-cmr

Note that conda and pip are package managers available in the Anaconda Python distribution.

===Set environment===
If you created the wrfx environment as shown above, check that PROJ_LIB path is pointing to
$HOME/anaconda3/envs/wrfx/share/proj
If not, you can try setting it to
setenv PROJ_LIB "$HOME/anaconda3/share/proj"

==WRFx: wrfxpy==

WRF-SFIRE forecasting and data assimilation in python using an HPC environment.

===wrfxpy: Installation===
====Clone github repository====
Clone wrfxpy repository
git clone <nowiki>https://github.com/openwfm/wrfxpy</nowiki>
Change to the directory where the wrfxpy repository has been created
cd wrfxpy
and in wrxpy folder
git checkout angel

====General configuration====
An etc/conf.json file must be created with the keys discussed below. A template file etc/conf.json.initial is provided as a starting point.

cd wrfxpy
cp etc/conf.json.initial etc/conf.json

Configure the queuing system, system directories, WPS/WRF-SFIRE locations, and workspace locations by editing the following keys in etc/conf.json:
"qsys": "key from clusters.json",
"wps_install_path": "/path/to/WPS",
"wrf_install_path": "/path/to/WRF",
"sys_install_path": "/path/to/wrfxpy"
"wps_geog_path" : "/path/to/WPS_GEOG",
"wget" : /path/to/wget"

Note that all these paths are created from previous steps of this wiki except the wget path, which needs to be specified to use a preferred version. To find the default wget,
which wget

====Cluster configuration====

Next, wrfxpy needs to know how jobs are submitted on your cluster. Create an entry for your cluster in etc/clusters.json, here we use speedy as an example:

{
"speedy" : {
"qsub_cmd" : "qsub",
"qdel_cmd" : "qdel",
"qstat_cmd" : "qstat",
"qstat_arg" : "",
"qsub_delimiter" : ".",
"qsub_job_num_index" : 0,
"qsub_script" : "etc/qsub/speedy.sub"
}
}

And then the file etc/qsub/speedy.sub should contain a submission script template, that makes use of the following variables supplied by wrfxpy based on job configuration:

%(nodes)d the number of nodes requested
%(ppn)d the number of processors per node requested
%(wall_time_hrs)d the number of hours requested
%(exec_path)d the path to the wrf.exe that should be executed
%(cwd)d the job working directory
%(task_id)d a task id that can be used to identify the job
%(np)d the total number of processes requested, equals nodes x ppn

Note that not all keys need to be used, as shown in the speedy example:

#$ -S /bin/bash
#$ -N %(task_id)s
#$ -wd %(cwd)s
#$ -l h_rt=%(wall_time_hrs)d:00:00
#$ -pe mpich %(np)d
mpirun_rsh -np %(np)d -hostfile $TMPDIR/machines %(exec_path)s

The script template should be derived from a working submission script.

Note: wrfxpy has already configuration for colibri, gross, kingspeak, and cheyenne.

====Tokens configuration====

When running wrfxpy, sometimes the data needs to be accessed and downloaded using a specific token created for the user. For instance, in the case of running the Fuel Moisture Model, one needs a token from a valid [https://simplekml.readthedocs.org/en/latest MesoWest] user to download data automatically. Also, when downloading satellite data, one needs a token from an [https://earthdata.nasa.gov/ Earthdata] user. All of these can be specified with the creation of the file etc/tokens.json from the template etc/tokens.json.initial containing:

{
"mesowest" : "token-from-mesowest",
"appkey" : "token-from-earthdata"
}

So, if any of the previous capabilities are required, create a token from the specific page, do

cp etc/tokens.json.initial etc/tokens.json

and edit the file to include your previously created token.

For running fuel moisture model, a new MesoWest user can be created in [https://mesowest.utah.edu/cgi-bin/droman/my_join.cgi?came_from=http://mesowest.utah.edu MesoWest New User]. Then, the token can be acquired and replaced in the etc/tokens.json file.

For acquiring satellite data, a new Earthdata user can be created in [https://urs.earthdata.nasa.gov/users/new Earthdata New User]. Then, the token can be acquired and replaced in the etc/tokens.json file. There are some data centers that need to be accessed using the $HOME/.netrc file. Therefore, creating the $HOME/.netrc file is recommended as follows

machine urs.earthdata.nasa.gov
login your_earthdata_id
password your_earthdata_password

====Get static data====

When running WRF-SFIRE simulations, one needs to use high-resolution elevation and fuel category data. If you have a GeoTIFF file for elevation and fuel, you can specify the location of these files using etc/vtables/geo_vars.json. So, you can do

cp etc/vtables/geo_vars.json.initial etc/vtables/geo_vars.json

and add the absolute path to your GeoTIFF files. The routine is going to automatically process these files and convert them into geogrid files to fit WPS. If you need to map the categories from the GeoTIFF files to the 13 Rothermel categories, you can modify the dictionary _var_wisdom on file src/geo/var_wisdom.py to specify the mapping. By default, the categories form the LANDFIRE dataset are going to be mapped according to 13 Rothermel categories. You can also specify what categories you want to interpolate using nearest neighbors. Therefore, the ones that you cannot map to 13 Rothermel categories. Finally, you can specify what categories should be no burnable using category 14.

To get GeoTIFF files from CONUS, you can use the LANDFIRE dataset following the steps on [[How_to_run_WRF-SFIRE_with_real_data#Obtaining_data_for_geogrid]]. Or you can just use the GeoTIFF files included in the static dataset WPS_GEOG/fuel_cat_fire and WPS_GEOG/topo_fire specifying in etc/vtables/geo_vars.json

{
"NFUEL_CAT": "/path/to/WPS_GEOG/fuel_cat_fire/lf_data.tif",
"ZSF": "/path/to/WPS_GEOG/topo_fire/ned_data.tif"
}

For running fuel moisture model, terrain static data is needed. So, inside wrfxpy do
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/static.tbz</nowiki>
tar xvfj static.tbz
this will untar a static folder with the static terrain on it.

===wrxpy: Testing===
====Simple forecast====
At this point, one should be able to run wrfxpy with a simple example:
conda activate wrfxpy
./simple_forecast.sh
Press enter at all the steps to set everything to the default values until the queuing system, then we select the cluster we configure (speedy in the example).

This will generate a job under jobs/experiment.json (or the name of the experiment that we chose).

Then, we can run our first forecast by
./forecast.sh jobs/experiment.json >& logs/experiment.log &

Show generate the experiment in the path specified in the etc/conf.json file and under a folder using the experiment name. The file logs/experiment.log should show the whole process step by step without any error.

====Fuel moisture model====
If tokens.json is set, "mesowest" token is provided, and static data is gotten, you can run
./rtma_cycler.sh anything >& logs/rtma_cycler.log &
which will download all the necessary weather stations and estimate the fuel moisture model in the whole continental US.

===wrfxpy: Possible errors===
====real.exe fails====

Depending on the cluster, wrfxpy could fail when tries to execute ./real.exe. This happens on systems that do not allow executing MPI binary from the command line. We do not run real.exe by mpirun because mpirun on head node may not be allowed. Then, one needs to provide an installation of WRF-SFIRE in serial mode in order to run real.exe in serial. In that case, we want to repeat the [[Setting_up_current_WRFx_system#Installation|previous steps]] but using the serial version of WRF-SFIRE
cd ..
git clone <nowiki>https://github.com/openwfm/wrf-fire wrf-fire-serial</nowiki>
cd wrf-fire-serial/wrfv2_fire
./configure
Options 13 (INTEL ifort/icc serial) and 0 (no nesting)

./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log
Again, if any of the previous step fails:
./clean -a
./configure
Add -nostdinc in CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

Note: This time, we only need to compile em_real because we only need real.exe. However, if you want to test serial vs parallel for any reason, you can proceed to compile em_fire the same way.

Then, we need to add this path in etc/conf.json file in wrfxpy, so
cd ../wrfxpy
and add to etc/conf.json file key
"wrf_serial_install_path": "/path/to/WRF/serial"

This should solve the problem, if not check log files from previous compilations.

==WRFx: wrfxweb==

Web-based visualization system for imagery generated by wrfxpy.

===wrfxweb: Account creation===

Create ~/.ssh directory (if you have not one)
mkdir ~/.ssh
cd ~/.ssh

Create an id_rsa key (if you have not one) doing
ssh-keygen
and following all the steps (you can select defaults, so always press enter).

Send an email to Jan Mandel (jan.mandel@gmail.com) asking for the creation of an account in demo server providing:
* Purpose of your request (including information about you)
* User id you would like (user_id)
* Short user id you would like (short_user_id)
* Public key (~/.ssh/id_rsa.pub file previously created)

After that, you will receive an answer from Jan and you will be able to ssh the demo server without any password (only the passcode from the id_rsa key if you set one).

===wrfxweb: Installation===

====Clone github repository====
Clone wrfxweb repository in the demo server
ssh user_id@demo.openwfm.org
git clone <nowiki>https://github.com/openwfm/wrfxweb.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxweb
cp etc/conf.json.template etc/conf.json

Configure the following key in etc/conf.json:
"url_root": "<nowiki>http://demo.openwfm.org/short_user_id</nowiki>"

The next steps are going to be set in a desired installation of wrfxpy (generated in the previous section).

Configure the following keys in etc/conf.json in any wrfxpy installation
"shuttle_ssh_key": "/path/to/id_rsa"
"shuttle_remote_user": "user_id"
"shuttle_remote_host": "demo.openwfm.org"
"shuttle_remote_root": "/path/to/remote/storage/directory"
"shuttle_lock_path": "/tmp/short_user_id"

The "shuttle_remote_root" key is usually defined as "/home/user_id/wrfxweb/fdds/simulations". So, everything should be ready to send post-processing simulations into the visualization server.

===wrfxweb: Testing===
====Simple forecast====
Finally, one can repeat the previous [[Setting_up_current_WRFx_system#Simple_forecast|simple forecast test]] but when simple forecast asks
Send variables to visualization server? [default=no]
you will answer yes.

Then, you should see your simulation post-processed time steps appearing in real-time on http://demo.openwfm.org under your short_user_id.

====Fuel moisture model====
The [[Setting_up_current_WRFx_system#Fuel_moisture_model|fuel moisture model test]] can be also run and a special visualization will appear on http://demo.openwfm.org under your short_user_id.

==WRFx: wrfxctrl==

A website that enables users to submit jobs to the wrfxpy framework for fire simulation.

===wrfxctrl: Installation===

====Clone github repository====
Clone wrfxctrl repository in your cluster
git clone <nowiki>https://github.com/openwfm/wrfxctrl.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxctrl
cp etc/conf-template.json etc/conf.json

Configure following keys in etc/conf.json
"host" : "127.1.2.3",
"port" : "5050",
"root" : "/short_user_id/",
"wrfxweb_url" : "<nowiki>http://demo.openwfm.org/short_user_id/</nowiki>",
"wrfxpy_path" : "/path/to/wrfxpy",
"jobs_path" : "/path/to/jobs",
"logs_path" : "/path/to/logs",
"sims_path" : "/path/to/sims"
Notes:
* Entries "host", "port", "root" are only examples but, for security reasons, you should choose different ones of your own and as random as possible.
* Entries "jobs_path", "logs_path", and "sims_path" are recommended to be removed. By default they are defined to be in wrfxctrl directories wrfxctrl/jobs, wrfxctrl/logs, and wrfxctrl/simulations.

===wrfxctrl: Testing===

====Running wrfxctrl====

Activate conda environment and run wrfxctrl.py doing

conda activate wrfx
python wrfxctrl.py

This will show a message similar to

Welcome page is <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki>
* Serving Flask app "wrfxctrl" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
INFO:werkzeug: * Running on <nowiki>http://127.1.2.3:5050/</nowiki> (Press CTRL+C to quit)

====Starting page====

Now you can go to your favorite internet browser and navigate to <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki> webpage. This will show you a screen similar than that

[[File:Start.png|400px|center]]
 

This starting page shows general information of the cluster and provides an option of starting a new fire using ''Start a new fire'' button and browsing the existent jobs using the ''Show current jobs'' button.

====Submission page====

From the previous page, if you select ''Start a new fire'', you will be able to access the submission page. In this page, you can specify 1) a short description of the simulation, 2) the ignition location clicking in an interactive map or specifying the degree lat-lon coordinates, 3) the ignition time and the forecast length, 4) the simulation profile which defines the number of domains with their resolutions and sizes and the atmospheric boundary conditions data. Finally, once you have all the simulation options defined, you can scroll down to the end (next figure) and select the ''Ignite'' button. This will automatically show the monitor page where you will be able to track the progress of the simulation. See the image below to see an example of a simulation submission.

[[File:Submit1.png|400px|center]][[File:Submit2.png|400px|center]][[File:Submit3.png|402px|center]]
 

====Monitoring page====

At the beginning of the monitoring page, you will see a list of important information about the simulation (see figure below). After the information, there is a list of steps with their current status. The different possible statuses are:

* Waiting (grey): Represent that the process has not started and needs to wait for the other process. All the processes are initialized with this status.
* Running (yellow): Represent that the process is still running so in progress. All processes switch their status from Waiting to Running when they start running.
* Success (green): Represent that the process finished well. All processes switch their status from Running to Success when they finish running successfully.
* Available (green): Represent that some part is done and some other is still in progress. This status is only used by the Output process because the visualization is available once the process starts running.
* Failed (red): Represent that the process finished with a failure. All processes switch their status from Running to Failed when they finish running with a failure.

In the monitor page, the log file can be also retrieved clicking the ''Retrieve log'' button at the end of the page, which provides a scroll down window with the log file information.

[[File:Monitor1.png|502px|center]][[File:Monitor2.png|500px|center]][[File:Monitor3.png|500px|center]]
 

Finally, once the Output process becomes Available, in the ''Visualization'' element of the information section will appear a link to the simulation in the web server generated using wrfxweb. In this page, one can interactively plot the results in real-time while the simulation is still running

[[File:Visualization.png|500px|center]]
 

====Overview page====

From most of the previous pages, you can navigate to the current jobs which shows a list of jobs that are running and it allows the user to cancel or delete any simulation that has run or is running.

[[File:Overview.png|500px|center]]

Running WRF-SFIRE with real data in the WRFx system

2020-08-24T15:03:28Z

Adamko: /* Get static data */

Instructions to set up the whole WRFx system right now using the last version of all the components with a couple of working examples. WRFx consists of a Fortran coupled atmosphere-fire model [https://github.com/openwfm/wrf-fire WRF-SFIRE], a python automatic HPC system [https://github.com/openwfm/wrfxpy wrfxpy], a visualization web interface [https://github.com/openwfm/wrfxweb wrfxweb], and a simulation web interface [https://github.com/openwfm/wrfxctrl wrfxctrl].

=WRF-SFIRE model=

A coupled weather-fire forecasting model built on top of Weather Research and Forecasting (WRF).

==WRF-SFIRE: Requirements and environment==

===Install required libraries===
* General requirements:
** C-shell
** Traditional UNIX utilities: zip, tar, make, etc.
* WRF-SFIRE requirements:
** Fortran and C compilers (Intel recomended)
** MPI (compiled using the same compiler, usually comes with the system)
** NetCDF libraries (compiled using the same compiler)
* WPS requirements:
** zlib compression library (zlib)
** PNG reference library (libpng)
** JasPer compression library
** libtiff and geotiff libraries

See https://www2.mmm.ucar.edu/wrf/users/prepare_for_compilation.html for the required versions of the libraries.

===Set environment===
Set specific libraries installed
setenv NETCDF /path/to/netcdf
setenv JASPERLIB /path/to/jasper/lib
setenv JASPERINC /path/to/jasper/include
setenv LIBTIFF /path/to/libtiff
setenv GEOTIFF /path/to/libtiff
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
Should your executables fail on unresolved libraries, also add all the library folders into your LD_LIBRARY_PATH:
setenv LD_LIBRARY_PATH /path/to/netcdf/lib:/path/to/jasper/lib:/path/to/libtiff/lib:/path/to/geotiff/lib:$LD_LIBRARY_PATH

==WRF-SFIRE: Installation==
===Clone github repositories===
Clone WRF-SFIRE and WPS github repositories
git clone <nowiki>https://github.com/openwfm/WRF-SFIRE</nowiki>
git clone <nowiki>https://github.com/openwfm/WPS</nowiki>

===Configure WRF-SFIRE===
cd WRF-SFIRE
./configure

Options 15 (INTEL ifort/icc dmpar) and 1 (simple nesting) if available

===Compile WRF-SFIRE===
Compile em_real
./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log

If any compilation error, compile em_fire
./compile em_fire >& compile_em_fire.log &
grep Error compile_em_fire.log

If any of the previous step fails:
./clean -a
./configure
Add to configure.wrf -nostdinc at the end of the CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Configure WPS===
cd ../WPS
./configure

Option 17 (Intel compiler (serial)) if available

===Compile WPS===
./compile >& compile_wps.log &
grep Error compile_wps.log

and
ls -l *.exe

should contain geogrid.exe, metgrid.exe, and ungrib.exe. If not
./clean -a
./configure
Add to configure.wps -nostdinc at the end of CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

===Get static data===
Get tar file with the static data and untar it. Keep in mind that this is the file that contains landuse, elevation, soiltype data, etc for WRF (geogrid.exe to be psecific).
cd ..
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/WPS_GEOG.tbz</nowiki>
tar xvfj WPS_GEOG.tbz

=WRFx system=

==WRFx: Requirements and environment==

===Install Anaconda distribution===
Download and install the Python 3 [https://repo.continuum.io/archive Anaconda Python] distribution for your platform. We recommend an installation into the users' home directory.
wget <nowiki>https://repo.continuum.io/archive/Anaconda3-2020.02-Linux-x86_64.sh</nowiki>
chmod +x Anaconda3-2020.02-Linux-x86_64.sh
./Anaconda3-2020.02-Linux-x86_64.sh

===Install necessary packages===
We recommend the creation of an environment. Install pre-requisites:
conda update -n base -c defaults conda
conda create -n wrfx python=3 gdal netcdf4 pyproj paramiko dill h5py psutil proj4 pytz scipy matplotlib flask
conda activate wrfx
conda install -c conda-forge simplekml pygrib f90nml pyhdf xmltodict basemap rasterio
pip install MesoPy python-cmr

Note that conda and pip are package managers available in the Anaconda Python distribution.

===Set environment===
If you created the wrfx environment as shown above, check that PROJ_LIB path is pointing to
$HOME/anaconda3/envs/wrfx/share/proj
If not, you can try setting it to
setenv PROJ_LIB "$HOME/anaconda3/share/proj"

==WRFx: wrfxpy==

WRF-SFIRE forecasting and data assimilation in python using an HPC environment.

===wrfxpy: Installation===
====Clone github repository====
Clone wrfxpy repository
git clone <nowiki>https://github.com/openwfm/wrfxpy</nowiki>
and
git checkout angel

====General configuration====
An etc/conf.json file must be created with the keys discussed below. A template file etc/conf.json.initial is provided as a starting point.

cd wrfxpy
cp etc/conf.json.initial etc/conf.json

Configure the queuing system, system directories, WPS/WRF-SFIRE locations, and workspace locations by editing the following keys in etc/conf.json:
"qsys": "key from clusters.json",
"wps_install_path": "/path/to/WPS",
"wrf_install_path": "/path/to/WRF",
"sys_install_path": "/path/to/wrfxpy"
"wps_geog_path" : "/path/to/WPS_GEOG",
"wget" : /path/to/wget"

Note that all these paths are created from previous steps of this wiki except the wget path, which needs to be specified to use a preferred version. To find the default wget,
which wget

====Cluster configuration====

Next, wrfxpy needs to know how jobs are submitted on your cluster. Create an entry for your cluster in etc/clusters.json, here we use speedy as an example:

{
"speedy" : {
"qsub_cmd" : "qsub",
"qdel_cmd" : "qdel",
"qstat_cmd" : "qstat",
"qstat_arg" : "",
"qsub_delimiter" : ".",
"qsub_job_num_index" : 0,
"qsub_script" : "etc/qsub/speedy.sub"
}
}

And then the file etc/qsub/speedy.sub should contain a submission script template, that makes use of the following variables supplied by wrfxpy based on job configuration:

%(nodes)d the number of nodes requested
%(ppn)d the number of processors per node requested
%(wall_time_hrs)d the number of hours requested
%(exec_path)d the path to the wrf.exe that should be executed
%(cwd)d the job working directory
%(task_id)d a task id that can be used to identify the job
%(np)d the total number of processes requested, equals nodes x ppn

Note that not all keys need to be used, as shown in the speedy example:

#$ -S /bin/bash
#$ -N %(task_id)s
#$ -wd %(cwd)s
#$ -l h_rt=%(wall_time_hrs)d:00:00
#$ -pe mpich %(np)d
mpirun_rsh -np %(np)d -hostfile $TMPDIR/machines %(exec_path)s

The script template should be derived from a working submission script.

Note: wrfxpy has already configuration for colibri, gross, kingspeak, and cheyenne.

====Tokens configuration====

When running wrfxpy, sometimes the data needs to be accessed and downloaded using a specific token created for the user. For instance, in the case of running the Fuel Moisture Model, one needs a token from a valid [https://simplekml.readthedocs.org/en/latest MesoWest] user to download data automatically. Also, when downloading satellite data, one needs a token from an [https://earthdata.nasa.gov/ Earthdata] user. All of these can be specified with the creation of the file etc/tokens.json from the template etc/tokens.json.initial containing:

{
"mesowest" : "token-from-mesowest",
"appkey" : "token-from-earthdata"
}

So, if any of the previous capabilities are required, create a token from the specific page, do

cp etc/tokens.json.initial etc/tokens.json

and edit the file to include your previously created token.

For running fuel moisture model, a new MesoWest user can be created in [https://mesowest.utah.edu/cgi-bin/droman/my_join.cgi?came_from=http://mesowest.utah.edu MesoWest New User]. Then, the token can be acquired and replaced in the etc/tokens.json file.

For acquiring satellite data, a new Earthdata user can be created in [https://urs.earthdata.nasa.gov/users/new Earthdata New User]. Then, the token can be acquired and replaced in the etc/tokens.json file. There are some data centers that need to be accessed using the $HOME/.netrc file. Therefore, creating the $HOME/.netrc file is recommended as follows

machine urs.earthdata.nasa.gov
login your_earthdata_id
password your_earthdata_password

====Get static data====

When running WRF-SFIRE simulations, one needs to use high-resolution elevation and fuel category data. If you have a GeoTIFF file for elevation and fuel, you can specify the location of these files using etc/vtables/geo_vars.json. So, you can do

cp etc/vtables/geo_vars.json.initial etc/vtables/geo_vars.json

and add the absolute path to your GeoTIFF files. The routine is going to automatically process these files and convert them into geogrid files to fit WPS. If you need to map the categories from the GeoTIFF files to the 13 Rothermel categories, you can modify the dictionary _var_wisdom on file src/geo/var_wisdom.py to specify the mapping. By default, the categories form the LANDFIRE dataset are going to be mapped according to 13 Rothermel categories. You can also specify what categories you want to interpolate using nearest neighbors. Therefore, the ones that you cannot map to 13 Rothermel categories. Finally, you can specify what categories should be no burnable using category 14.

To get GeoTIFF files from CONUS, you can use the LANDFIRE dataset following the steps on [[How_to_run_WRF-SFIRE_with_real_data#Obtaining_data_for_geogrid]]. Or you can just use the GeoTIFF files included in the static dataset WPS_GEOG/fuel_cat_fire and WPS_GEOG/topo_fire specifying in etc/vtables/geo_vars.json

{
"NFUEL_CAT": "/path/to/WPS_GEOG/fuel_cat_fire/lf_data.tif",
"ZSF": "/path/to/WPS_GEOG/topo_fire/ned_data.tif"
}

For running fuel moisture model, terrain static data is needed. So, inside wrfxpy do
wget <nowiki>http://math.ucdenver.edu/~farguella/tmp/static.tbz</nowiki>
tar xvfj static.tbz
this will untar a static folder with the static terrain on it.

===wrxpy: Testing===
====Simple forecast====
At this point, one should be able to run wrfxpy with a simple example:
conda activate wrfxpy
./simple_forecast.sh
Press enter at all the steps to set everything to the default values until the queuing system, then we select the cluster we configure (speedy in the example).

This will generate a job under jobs/experiment.json (or the name of the experiment that we chose).

Then, we can run our first forecast by
./forecast.sh jobs/experiment.json >& logs/experiment.log &

Show generate the experiment in the path specified in the etc/conf.json file and under a folder using the experiment name. The file logs/experiment.log should show the whole process step by step without any error.

====Fuel moisture model====
If tokens.json is set, "mesowest" token is provided, and static data is gotten, you can run
./rtma_cycler.sh anything >& logs/rtma_cycler.log &
which will download all the necessary weather stations and estimate the fuel moisture model in the whole continental US.

===wrfxpy: Possible errors===
====real.exe fails====

Depending on the cluster, wrfxpy could fail when tries to execute ./real.exe. This happens on systems that do not allow executing MPI binary from the command line. We do not run real.exe by mpirun because mpirun on head node may not be allowed. Then, one needs to provide an installation of WRF-SFIRE in serial mode in order to run real.exe in serial. In that case, we want to repeat the [[Setting_up_current_WRFx_system#Installation|previous steps]] but using the serial version of WRF-SFIRE
cd ..
git clone <nowiki>https://github.com/openwfm/wrf-fire wrf-fire-serial</nowiki>
cd wrf-fire-serial/wrfv2_fire
./configure
Options 13 (INTEL ifort/icc serial) and 0 (no nesting)

./compile em_real >& compile_em_real.log &
grep Error compile_em_real.log
Again, if any of the previous step fails:
./clean -a
./configure
Add -nostdinc in CPP flag, and repeat compilation. If this does not solve compilation, look for issues in your environment.

Note: This time, we only need to compile em_real because we only need real.exe. However, if you want to test serial vs parallel for any reason, you can proceed to compile em_fire the same way.

Then, we need to add this path in etc/conf.json file in wrfxpy, so
cd ../wrfxpy
and add to etc/conf.json file key
"wrf_serial_install_path": "/path/to/WRF/serial"

This should solve the problem, if not check log files from previous compilations.

==WRFx: wrfxweb==

Web-based visualization system for imagery generated by wrfxpy.

===wrfxweb: Account creation===

Create ~/.ssh directory (if you have not one)
mkdir ~/.ssh
cd ~/.ssh

Create an id_rsa key (if you have not one) doing
ssh-keygen
and following all the steps (you can select defaults, so always press enter).

Send an email to Jan Mandel (jan.mandel@gmail.com) asking for the creation of an account in demo server providing:
* Purpose of your request (including information about you)
* User id you would like (user_id)
* Short user id you would like (short_user_id)
* Public key (~/.ssh/id_rsa.pub file previously created)

After that, you will receive an answer from Jan and you will be able to ssh the demo server without any password (only the passcode from the id_rsa key if you set one).

===wrfxweb: Installation===

====Clone github repository====
Clone wrfxweb repository in the demo server
ssh user_id@demo.openwfm.org
git clone <nowiki>https://github.com/openwfm/wrfxweb.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxweb
cp etc/conf.json.template etc/conf.json

Configure the following key in etc/conf.json:
"url_root": "<nowiki>http://demo.openwfm.org/short_user_id</nowiki>"

The next steps are going to be set in a desired installation of wrfxpy (generated in the previous section).

Configure the following keys in etc/conf.json in any wrfxpy installation
"shuttle_ssh_key": "/path/to/id_rsa"
"shuttle_remote_user": "user_id"
"shuttle_remote_host": "demo.openwfm.org"
"shuttle_remote_root": "/path/to/remote/storage/directory"
"shuttle_lock_path": "/tmp/short_user_id"

The "shuttle_remote_root" key is usually defined as "/home/user_id/wrfxweb/fdds/simulations". So, everything should be ready to send post-processing simulations into the visualization server.

===wrfxweb: Testing===
====Simple forecast====
Finally, one can repeat the previous [[Setting_up_current_WRFx_system#Simple_forecast|simple forecast test]] but when simple forecast asks
Send variables to visualization server? [default=no]
you will answer yes.

Then, you should see your simulation post-processed time steps appearing in real-time on http://demo.openwfm.org under your short_user_id.

====Fuel moisture model====
The [[Setting_up_current_WRFx_system#Fuel_moisture_model|fuel moisture model test]] can be also run and a special visualization will appear on http://demo.openwfm.org under your short_user_id.

==WRFx: wrfxctrl==

A website that enables users to submit jobs to the wrfxpy framework for fire simulation.

===wrfxctrl: Installation===

====Clone github repository====
Clone wrfxctrl repository in your cluster
git clone <nowiki>https://github.com/openwfm/wrfxctrl.git</nowiki>

====Configuration====

Change directory and copy template to create new etc/conf.json
cd wrfxctrl
cp etc/conf-template.json etc/conf.json

Configure following keys in etc/conf.json
"host" : "127.1.2.3",
"port" : "5050",
"root" : "/short_user_id/",
"wrfxweb_url" : "<nowiki>http://demo.openwfm.org/short_user_id/</nowiki>",
"wrfxpy_path" : "/path/to/wrfxpy",
"jobs_path" : "/path/to/jobs",
"logs_path" : "/path/to/logs",
"sims_path" : "/path/to/sims"
Notes:
* Entries "host", "port", "root" are only examples but, for security reasons, you should choose different ones of your own and as random as possible.
* Entries "jobs_path", "logs_path", and "sims_path" are recommended to be removed. By default they are defined to be in wrfxctrl directories wrfxctrl/jobs, wrfxctrl/logs, and wrfxctrl/simulations.

===wrfxctrl: Testing===

====Running wrfxctrl====

Activate conda environment and run wrfxctrl.py doing

conda activate wrfx
python wrfxctrl.py

This will show a message similar to

Welcome page is <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki>
* Serving Flask app "wrfxctrl" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
INFO:werkzeug: * Running on <nowiki>http://127.1.2.3:5050/</nowiki> (Press CTRL+C to quit)

====Starting page====

Now you can go to your favorite internet browser and navigate to <nowiki>http://127.1.2.3:5050/short_user_id/start</nowiki> webpage. This will show you a screen similar than that

[[File:Start.png|400px|center]]
 

This starting page shows general information of the cluster and provides an option of starting a new fire using ''Start a new fire'' button and browsing the existent jobs using the ''Show current jobs'' button.

====Submission page====

From the previous page, if you select ''Start a new fire'', you will be able to access the submission page. In this page, you can specify 1) a short description of the simulation, 2) the ignition location clicking in an interactive map or specifying the degree lat-lon coordinates, 3) the ignition time and the forecast length, 4) the simulation profile which defines the number of domains with their resolutions and sizes and the atmospheric boundary conditions data. Finally, once you have all the simulation options defined, you can scroll down to the end (next figure) and select the ''Ignite'' button. This will automatically show the monitor page where you will be able to track the progress of the simulation. See the image below to see an example of a simulation submission.

[[File:Submit1.png|400px|center]][[File:Submit2.png|400px|center]][[File:Submit3.png|402px|center]]
 

====Monitoring page====

At the beginning of the monitoring page, you will see a list of important information about the simulation (see figure below). After the information, there is a list of steps with their current status. The different possible statuses are:

* Waiting (grey): Represent that the process has not started and needs to wait for the other process. All the processes are initialized with this status.
* Running (yellow): Represent that the process is still running so in progress. All processes switch their status from Waiting to Running when they start running.
* Success (green): Represent that the process finished well. All processes switch their status from Running to Success when they finish running successfully.
* Available (green): Represent that some part is done and some other is still in progress. This status is only used by the Output process because the visualization is available once the process starts running.
* Failed (red): Represent that the process finished with a failure. All processes switch their status from Running to Failed when they finish running with a failure.

In the monitor page, the log file can be also retrieved clicking the ''Retrieve log'' button at the end of the page, which provides a scroll down window with the log file information.

[[File:Monitor1.png|502px|center]][[File:Monitor2.png|500px|center]][[File:Monitor3.png|500px|center]]
 

Finally, once the Output process becomes Available, in the ''Visualization'' element of the information section will appear a link to the simulation in the web server generated using wrfxweb. In this page, one can interactively plot the results in real-time while the simulation is still running

[[File:Visualization.png|500px|center]]
 

====Overview page====

From most of the previous pages, you can navigate to the current jobs which shows a list of jobs that are running and it allows the user to cancel or delete any simulation that has run or is running.

[[File:Overview.png|500px|center]]

Smoke and coupling with WRF-Chem

2019-11-23T17:06:43Z

Adamko: /* References */

{{users guide}}

As of WRF 3.4, WRF-Chem is now included in the SFire repository. Fire emissions can be now input into WRF-Chem as chemical species or a simple smoke tracer. [[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 '''WRF_CHEM''' and configure with the argument '''chem''' 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 [https://github.com/jbeezley/wrf-fire/tree/master/wrfv2_fire/test/em_fire/chem '''test/em_fire/chem''']
Note that '''sfc_full_init =.true.''' is required in the '''&fire''' section of '''namelist.input''' to initialize USGS landuse, which is required by WRF-Chem.
The tracer selected by '''tracer_opt=1''' will appear as an atmospheric variable in the output file with the name '''smoke'''. The chemical species in the atmosphere, selected by '''chem_opt''', will appear under their respective names, such as '''n2o5'''.

==Configuration==
The selection of the model in WRF-Chem is controlled by namelist variables '''tracer_opt''' in the [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/test/em_fire/chem/namelist.input#L78 '''&dynamics'''] section and '''chem_opt''' in the [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/test/em_fire/chem/namelist.input#L203 '''&chemistry'''] section of '''namelist.input'''. At the moment, the coupling supports '''tracer_opt = 1''', which creates a single tracer called '''smoke''', and a subset of RADM2 ('''chem_opt=2''') and MOZART ('''chem_opt=112''' or '''119''') variables. The option '''tracer_opt = 2''' does not require WRF-Chem, and it creates tracers called '''tr17_1''' to '''tr17_8''', which are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. The properties of the tracers slightly differ, and the tracers work slightly differently with and without WRF-Chem compiled, as described in file chem/module_input_tracer.F.

In each time step, the coupling code adds the fire emissions created in the time step to the first layer of atmosphere cells. The chemistry state arrays are have unit of concentrations ('''ppmv'''), so the amounts of the inserted species are scaled by the dry air mass in the first layer. The amount of the chemical species created is determined from the amount of fuel burned directly by an emissions table, while the smoke tracer uses the fire ground heat flux '''GRNHFX''' as a proxy. The emissions table contains the amounts of emissions fuel burned in '''g/kg''' or '''mol/kg'''. The emissions tables are specified in file '''namelist.fire_emissions'''. This file contains a line for each species like
<pre>
no2=3.2,3.2,3.2,1.4,1.4,1.4,1.4,2.7,2.7,2.7,3,3,3,
</pre>
with emissions (g/kg fuel or mol/kg fuel) for each of the fuel categories used (by default, the 13 Anderson's categories).

There are two additional variables in '''namelist.fire_emissions''':
<pre>
compatible_chem_opt=112,119
</pre>
is a list of '''chem_opt''' values intended to be used with the table. However, presently, the code does not check if the file lists other chemistry species supported by the coupling code, not just those for the given '''chem_opt'''. If it does, the results can be upredictable.
The variable
<pre>
printsums=1
</pre>
will enable printing of the totals of each emissions species at the end of every time step.

There are currently two emissions tables available:
* {{Wrf-fire-path|wrfv2_fire/test/em_fire/chem/namelist.fire_emissions.RADM2|namelist.fire_emissions.RADM2}} for [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2]
* {{Wrf-fire-path|wrfv2_fire/test/em_fire/chem/namelist.fire_emissions.MOZART|namelist.fire_emissions.MOZART}} for [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART]
You need to copy or link one of them to '''namelist.fire_emissions''', such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set '''chem_opt''' appropriately in '''namelist.input''', here '''chem_opt=2'''.

==Implementation==

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 [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/chem/module_emissions_anthropogenics.F emissions] 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 arrays '''chem''' and '''tracer'''. These arrays are four dimensional indexed like '''(x,z,y,s)''', where s is the chemical
species. The domain structure contains scalars such as '''p_smoke''' (into the '''tracer''' array) and '''p_nh4''' (into the '''chem''' array) that give the species index for
each type. The species selections are specific to different chemistry options ('''chem_opt''')
from the registry; however, even unused species have their index set to 1. The dynamics section of the namelist has an option for '''tracer_opt'''. This
controls what tracers are generated for Chem.

Since fuel is given at the fire grid resolution, the emissions are computed at the fire resolution and then averaged to the atmospheric resolution, where the chemistry operates. However, since the memory demands of a 3D array at fire resolution (two surface dimensions and chemical species) would be excessive, the contributions of the emissions are computed on the fly and added to the respective atmospheric cell immediately. This results in code that straddles the otherwise strict division in SFIRE between fire computations on the fire grid, which are independent of WRF, and the atmospheric computations related to WRF, which otherwise consist of interpolation only and should not contain any other code. So, subroutine [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F#L276 '''add_fire_emissions_to_chem'''], which adds chemical species to the '''chem''' array, was derived from the utility [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_util.F#L471 '''sum_2d_cells'''] by adding chemistry-specific code.

The chemistry coupling code is compiled only when WRF-Chem is being compiled. It resides in [https://github.com/jbeezley/wrf-fire/blob4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F module_fr_sfire_atm.F], which is allowed by the SFIRE architecture to contain code both at atmosphere and fire resolution. Besides subroutine '''add_fire_emissions_to_chem''', the code consists of subroutine [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F#L151 '''read_emissions_table'''], which reads file '''namelist.fire_emissions''', subroutine [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F#L276 '''add_fire_emissions_to_chem'''], which adds chemical species to the '''chem''' array, the [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F#L78 emissions tables] as module variables, subroutine [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_atm.F#L1914 '''fire_emission'''], which adds the smoke tracer, and the corresponding call statements in [https://github.com/jbeezley/wrf-fire/blob/4c0851085eeb25d9143bd5b07e736fe949700497/wrfv2_fire/phys/module_fr_sfire_driver.F '''module_fr_sfire_driver'''].

==References==
* Kochanski A. K., Jenkins M.A., Yedinak K., Mandel J., Beezley J, and Lamb B. (2015) '''Toward an integrated system for fire, smoke and air quality simulations''', International Journal of Wildland Fire - http://dx.doi.org/10.1071/WF14074
* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Craig B. Clements, '''Air pollution forecasting by coupled atmosphere-fire model WRF and SFIRE with WRF-Chem''', 4th Fire Behavior and Fuels Conference, February 18-22, 2013, Raleigh, NC, {{arXiv|1304.7703}}, 2013
* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, and Minjeong Kim, '''WRF fire simulation coupled with a fuel moisture model and smoke transport by WRF-Chem''', [http://www.mmm.ucar.edu/events/2012_wrfusers/ 2012 WRF Users Workshop], [http://www.openwfm.org/wiki/File:WRF_workshop_2012_poster.pdf Poster 51] [http://www.mmm.ucar.edu/events/2012_wrfusers/abstracts/p51.htm abstract] [https://www.regonline.com/AttendeeDocuments/1077122/43365086/wrf2012.pdf paper] {{arXiv|1208.1059}}
* [http://ruc.noaa.gov/wrf/WG11/Users_guide.pdf WRF-Chem Users' Guide]
* Georg A. Grell, Steven E. Peckham, Rainer Schmitz, Stuart A. McKeen, Gregory Frost, William C. Skamarock, Brian Eder, [http://dx.doi.org/10.1016/j.atmosenv.2005.04.027 Fully coupled “online” chemistry within the WRF model], Atmospheric Environment, Volume 39, Issue 37, December 2005, Pages 6957–6975
* C. Wiedinmyer, S. K. Akagi, R. J. Yokelson, L. K. Emmons, J. A. Al-Saadi, J. J. Orlando, and A. J. Soja. [http://dx.doi.org/10.5194/gmd-4-625-2011 The Fire INventory from NCAR (FINN): a high resolution global model to estimate the emissions from open burning], Geosci. Model Dev., 4, 625-641, 2011
* L. K. Emmons, S. Walters, P. G. Hess, J.-F. Lamarque, G. G. Pfister, D. Fillmore, C. Granier, A. Guenther, D. Kinnison, T. Laepple, J. Orlando, X. Tie, G. Tyndall, C. Wiedinmyer, S. L. Baughcum, and S. Kloster, [http://dx.doi.org/10.5194/gmd-3-43-2010 Description and evaluation of the Model for Ozone and Related chemical Tracers, version 4 (MOZART-4)], Geosci. Model Dev., 3, 43-67, 2010

==External links==
* [http://ruc.noaa.gov/wrf/WG11/ WRF-Chem] home page
* [https://www2.acom.ucar.edu/modeling/finn-fire-inventory-ncar Finn] emissions model
* [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] chemistry model

WRF-SFIRE user guide

2019-01-19T00:45:25Z

Adamko: /* Running a real case */

:''This guide applies to WRF-SFIRE, available from [[How_to_get_WRF-Fire|OpenWFM.org]]. [[Fire_code_in_WRF_release|WRF-Fire]] available in [http://www.wrf-model.org/users/release.php WRF release], is a limited version from 2010. This guide evolves with the software and it complements the technical description in J. Mandel, J. D. Beezley, and A. K. Kochanski, '''Coupled atmosphere-wildland fire modeling with WRF 3.3 and SFIRE 2011''', Geoscientific Model Development (GMD) 4, 591-610, 2011, {{doi|10.5194/gmd-4-591-2011}} and J. Mandel, S. Amram, J. D. Beezley, G. Kelman, A. K. Kochanski, V. Y. Kondratenko, B. H. Lynn, B. Regev, M. Vejmelka, 2014, '''Recent advances and applications of WRF–SFIRE''', Natural Hazards and Earth System Science, 14, 2829-2845, 2014, {{doi|10.5194/nhess-14-2829-2014}}.''
==Mailing list==
Please consider joining the mailing list wrf-sfire@googlegroups.com, which is monitored by the developers. Go to https://googlegroups.com/group/wrf-sfire and log into your google account, or,
to join without a google account, send any email to [mailto://wrf-sfire+subscribe@googlegroups.com wrf-sfire+subscribe@googlegroups.com].

==Getting started==
# [[How to get WRF-Fire|Downloading the software]]
# [[How to run WRF-Fire|Building the software and running an ideal case]]

==Configuration==
# [[namelist.input]]
# [[namelist.fire]]
# [[Vertical wind interpolation]]
# [[WRF-Fire ignition|Ignition]]
==Running a real case==
#[[How to run WRF-Fire with real data|Basics of running a real case]]
#[[How to convert data for Geogrid|Converting fuel data]]
#[[WPS with GeoTIFF support|Using GeoTIFF files]]

==Coupling with fuel moisture and smoke==
# [[Fuel moisture model]]
# [[Assimilation of RAWS fuel moisture data]]
# [[Coupling with WRF-Chem]]

==Data assimilation and ignition from a perimeter==
# [[Fire replay and cycling]]

==Standalone fire model==
#[[How_to_run_the_standalone_fire_model_in_WRF-Fire|Running the standalone fire model]]

==Visualisation==
#[[How to visualize WRF-Fire output in VAPOR|VAPOR]]
#[[Visualization in Google Earth|Google Earth]]
#[[How to visualize WRF-Fire output in Mayavi2|Mayavi2]]
#[[How to visualize WRF-Fire output in VisTrails|VisTrails]]
#[[How to visualize WRF-Fire output in Matlab|Matlab]]
#[[Visualizations links|Examples and case studies]]

==Diagnostics==
#[[How to visualize vertical profiles from WRF in Matlab|Wind profiles]]
#[[How to diagnose fuel properties in WRF-Fire|Fuel properties]]
#[[How to load WRF files in Matlab|Loading WRF files into Matlab]]
#[[How to interpret WRF variables|WRF variables]]
#[[SFIRE variables]]
==Publications==
# [[Publications#WRF-Fire description|Model description]]
# [[Publications#Other WRF-Fire publications|Other publications]]

==Acknowledgements==
This work was partially supported by NSF grants ATM-0835579 and DMS-1216481.
[[Category:WRF-Fire|User's guide]]
[[Category:WRF-SFIRE users guide]]

==See also==
* [[WRF-Fire development notes]]
* [[Fire code in WRF release]]s
* [[Publications]]

WRF-SFIRE user guide

2019-01-19T00:42:33Z

Adamko:

:''This guide applies to WRF-SFIRE, available from [[How_to_get_WRF-Fire|OpenWFM.org]]. [[Fire_code_in_WRF_release|WRF-Fire]] available in [http://www.wrf-model.org/users/release.php WRF release], is a limited version from 2010. This guide evolves with the software and it complements the technical description in J. Mandel, J. D. Beezley, and A. K. Kochanski, '''Coupled atmosphere-wildland fire modeling with WRF 3.3 and SFIRE 2011''', Geoscientific Model Development (GMD) 4, 591-610, 2011, {{doi|10.5194/gmd-4-591-2011}} and J. Mandel, S. Amram, J. D. Beezley, G. Kelman, A. K. Kochanski, V. Y. Kondratenko, B. H. Lynn, B. Regev, M. Vejmelka, 2014, '''Recent advances and applications of WRF–SFIRE''', Natural Hazards and Earth System Science, 14, 2829-2845, 2014, {{doi|10.5194/nhess-14-2829-2014}}.''
==Mailing list==
Please consider joining the mailing list wrf-sfire@googlegroups.com, which is monitored by the developers. Go to https://googlegroups.com/group/wrf-sfire and log into your google account, or,
to join without a google account, send any email to [mailto://wrf-sfire+subscribe@googlegroups.com wrf-sfire+subscribe@googlegroups.com].

==Getting started==
# [[How to get WRF-Fire|Downloading the software]]
# [[How to run WRF-Fire|Building the software and running an ideal case]]

==Configuration==
# [[namelist.input]]
# [[namelist.fire]]
# [[Vertical wind interpolation]]
# [[WRF-Fire ignition|Ignition]]
==Running a real case==
#[[How to run WRF-Fire with real data|Basics of running a real case]]
#[[How to convert data for Geogrid|Acquiring and converting fine-resolution data for Geogrid]]
#[[WPS with GeoTIFF support|Using GeoTIFF files]]

==Coupling with fuel moisture and smoke==
# [[Fuel moisture model]]
# [[Assimilation of RAWS fuel moisture data]]
# [[Coupling with WRF-Chem]]

==Data assimilation and ignition from a perimeter==
# [[Fire replay and cycling]]

==Standalone fire model==
#[[How_to_run_the_standalone_fire_model_in_WRF-Fire|Running the standalone fire model]]

==Visualisation==
#[[How to visualize WRF-Fire output in VAPOR|VAPOR]]
#[[Visualization in Google Earth|Google Earth]]
#[[How to visualize WRF-Fire output in Mayavi2|Mayavi2]]
#[[How to visualize WRF-Fire output in VisTrails|VisTrails]]
#[[How to visualize WRF-Fire output in Matlab|Matlab]]
#[[Visualizations links|Examples and case studies]]

==Diagnostics==
#[[How to visualize vertical profiles from WRF in Matlab|Wind profiles]]
#[[How to diagnose fuel properties in WRF-Fire|Fuel properties]]
#[[How to load WRF files in Matlab|Loading WRF files into Matlab]]
#[[How to interpret WRF variables|WRF variables]]
#[[SFIRE variables]]
==Publications==
# [[Publications#WRF-Fire description|Model description]]
# [[Publications#Other WRF-Fire publications|Other publications]]

==Acknowledgements==
This work was partially supported by NSF grants ATM-0835579 and DMS-1216481.
[[Category:WRF-Fire|User's guide]]
[[Category:WRF-SFIRE users guide]]

==See also==
* [[WRF-Fire development notes]]
* [[Fire code in WRF release]]s
* [[Publications]]

WRF-SFIRE user guide

2019-01-19T00:41:48Z

Adamko: /* Running a real case */

How to run WRF-SFIRE with real data

2019-01-19T00:39:38Z

Adamko: /* Outline */

{{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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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|Converting fuel data]].
# [[#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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".
[[File:Landfire4.png]]
Again, we key in the coordinates determined before and click "Add Area".
 
In the next window click again "Modify Data Request", make sure only us_Elevation is selected, change format to "Geotiff" and click "Save Changes & Return to Summary"
[[File:Landfire5.png]]
 
In the next window you should be able to click "Download" in order to download the GeoTIFF file containing topography. This sample file can be downloaded from here:
[[File:09159064.tif]]

=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]]

How to run WRF-SFIRE with real data

2016-11-07T20:22:26Z

Adamko: /* Downloading high resolution elevation 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".
[[File:Landfire4.png]]
Again, we key in the coordinates determined before and click "Add Area".
 
In the next window click again "Modify Data Request", make sure only us_Elevation is selected, change format to "Geotiff" and click "Save Changes & Return to Summary"
[[File:Landfire5.png]]
 
In the next window you should be able to click "Download" in order to download the GeoTIFF file containing topography. This sample file can be downloaded from here:
[[File:09159064.tif]]

=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]]

How to run WRF-SFIRE with real data

2016-11-07T20:21:46Z

Adamko: /* Downloading high resolution elevation 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".
[[File:Landfire4.png]]
Again, we key in the coordinates determined before and click "Add Area".
 
In the next window click again "Modify Data Request", make sure only us_Elevation is selected, change format to "Geotiff" and click "Save Changes & Return to Summary"
[[File:Landfire5.png]]
 
In the next window you should be able to click "Download" in order to download the GeoTIFF file containing topography. This sample file can be downloaded from here:
[[Media:09159064.tif]]

=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]]

File:Landfire5.png

2016-11-07T20:11:54Z

Adamko: Landfire elevation menu

Landfire elevation menu

How to run WRF-SFIRE with real data

2016-11-07T20:07:52Z

Adamko: /* Downloading high resolution elevation 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".
[[File:Landfire4.png]]
Again, we key in the coordinates determined before and click "Add Area".
 
In the next window click again "Modify Data Request", make sure us_Elevation is selected, change format to "Geotiff" and click "=Save Changes & Return to Summary"
[[File:Landfire5.png]]
 

=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]]

How to run WRF-SFIRE with real data

2016-11-07T19:51:46Z

Adamko: /* Downloading high resolution elevation 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".

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:Landfire4.png]]
 
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]]

File:Landfire4.png

2016-11-07T19:47:06Z

Adamko: Landfire menu for elevation retrieval

Landfire menu for elevation retrieval

How to run WRF-SFIRE with real data

2016-11-07T19:46:33Z

Adamko: /* Downloading high resolution elevation 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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==

For the United States, elevation data is also available at the [http://landfire.cr.usgs.gov/viewer/ landfire] website. Repeat the steps described above for downloading the fuel data, but instead of selecting "LF2014 (LF_140) US_140 13 Fire Behavior Models-Anderson, this time select: "Topographic" and "us Elevation".

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:Landfire4.png.]]
 
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]]

How to run WRF-SFIRE with real data

2016-11-07T19:39:13Z

Adamko: /* Downloading fuel category 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfire3.png]]
 
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]]

How to run WRF-SFIRE with real data

2016-11-07T19:37:58Z

Adamko: /* Downloading fuel category 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. Then go to the bottom of the page and click "Save Changes".
[[File:landfir3.png]]
 
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]]

File:Landfire3.png

2016-11-07T19:36:07Z

Adamko: Landfire third menu with data format selection

Landfire third menu with data format selection

File:Landfire2.png

2016-11-07T19:30:38Z

Adamko: Landfire second menu with lat lon and data selection

Landfire second menu with lat lon and data selection

How to run WRF-SFIRE with real data

2016-11-07T19:27:04Z

Adamko: /* Downloading fuel category 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu, and select option 'Download Data'
[[File:Landfire1.png]]
 
This will open a new window on the right. Click on 'x y' icon that will open a form that lets you key in the the longitude and latitude range of your selection. In this window, we will input the coordinates computed earlier, and below we will select 'LF_2014 (LF_140)', then 'Fuel', and 'us_140 13 Fire Behavior Fuel Models-Anderson, and click 'Add Area' button.
[[File:landfire2.png]]
 
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 "US_140 13 Fire Behavior Fuel Models-Anderson" and change the data format from "ArcGRID_with_attribs" to "GeoTIFF_with _attribs". At the bottom make sure "Maximum size (MB) per piece:" is set to 250. 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]]

File:Landfire1.png

2016-11-07T19:01:43Z

Adamko: Landfire menu

Landfire menu

How to run WRF-SFIRE with real data

2016-11-07T19:01:12Z

Adamko: /* Downloading fuel category 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://www2.mmm.ucar.edu/wrf/users/supports/tutorial.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,
click roughly on your are of interest, the map will zoom in, you will see a menu on the top of the screen. Click on the earth icon, that should display a drop down menu
[[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]]

How to visualize WRF-Fire output in VAPOR

2016-05-04T19:44:41Z

Adamko: /* Directions */

{{users guide}}
==Prerequistes==

* [[How to run WRF-Fire|A working installation]] of [[WRF-Fire]], possibly on a remote supercomputer or a cluster.
* A visualization computer with a [http://www.vapor.ucar.edu/docs/install/index.php?id=depbin decent graphics card and drivers] (hardware accelerated [[wikipedia:OpenGL|OpenGL]] required), 3 button mouse.
* [http://www.vapor.ucar.edu Download] and install [[VAPOR]] ('''for idealized cases we recommend using Vapor version 2.0.0''' as newer versions have problems with processing wrfoutput data without valid latitude and longitude provided in degrees)
** Read [http://www.vapor.ucar.edu/start Getting started with VAPOR] first.
** On a Mac, run the installation package, then add to your path '''/Applications/VAPOR.app/Contents/MacOS'''
** Do the exercises in the first few pages of the [http://www.vapor.ucar.edu/docs/tutorial VAPOR quick start guide] to learn the basics of the controls.
** VAPOR can be [http://www.cisl.ucar.edu/hss/dasg/userinfo/remotevis.shtml used remotely] over a version of [[wikipedia:VNC|VNC]] with OpenGL support, to avoid transferring huge datasets to your visualization computer.

==Directions==
* [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#Nml Change in '''namelist.input'''] the line with '''history_interval''' to the desired frame interval in seconds, for example '''history_interval_s=1'''. Make sure '''frames_per_outfile''' is large enough so that only one '''wrfout''' file is produced.
* [[How to run WRF-Fire|Run WRF-Fire]]. The pictures below are from the "hill" ideal run in WRF-Fire.
* If the visualization computer is different from the computer where you run WRF-Fire, transfer the '''wrfout''' file to the visualization computer
* Start VAPOR by clicking on its icon or '''vaporgui''' from the command line
* In the GUI, click "Data" on the top menu bar, then "Import WRF output files into current session" or "Data", then "Import data into current session" then select "WRF_ARW" from the submenu, and navigate to your '''wrfout''' file.
[[File:Vapor_WRF_import.png]]

In the black right panel, you should see an empty wireframe box from the top.
* Click the "Flow" tab, check the box "Instance 1", click "OK" on a warning about flow lines below zero. Select "Refinement" 2. You should see a picture like this (the starting points of the flow lines are picked randomly so they are different in every session):
[[File:Vapor-flowlines-window.png|600px]]
* Click the "Animation" tab and move the "Frame position" slider to the middle (in the ideal "hill" example), or to a time when you know that the fire has already well developed. The flowlines should move a little.
* Click the "2D" tab, check "Instance 1", select "Refinement" 2, and 2D variable '''GRNHFX''', check "Apply color and opacity to terrain surface", and push the "Fit data" button at the bottom.
* Rotate the image with a mouse to see something like this:
[[File:Vapor-fire-window.png|600px]]
* Click on the "Animation" tab, click on the rewind and play VCR controls, and watch the movie. If the movie is too slow, go back to the "Flow" tab and reduce the "Refinement" value.
* To capture the movie, use "Capture", "Begin image capture sequence in visualizer 0", select directory, then run the movie, when done "Capture" "End image capture sequence". You get the movie frames as jpg files.
* Use the DVR tab and other VAPOR features for a more advanced visualization as desired.

==More advanced visualization==

* Optional: If you plan to work with large files (over 2GB), you must have WRF compiled with large file support. This requires a netcdf
library with large file support as well. To compile netcdf with large file support, follow the instructions at [[How to run WRF-Fire]], but add the flag
<code>--enable-largefile</code> to the configure command, and set the environment variable
<code>WRFIO_NCD_LARGE_FILE_SUPPORT=1</code> prior to compiling WRF.

If you are running on a Mac, you can install nco with large file support using [http://www.macports.org/ macports],
sudo port install nco
and see its [http://nco.sourceforge.net/nco.html user's guide] if you wish. On some linux distributions, the binaries that come with the package manager do not support large files. You will need to recompile nco manually from the [http://nco.sourceforge.net/src/nco-4.0.3.tar.gz source package] with the following environment variables set to the location of you netcdf library.
export NETCDF_LIB=${NETCDF}/lib
export NETCDF_INC=${NETCDF}/include

* If the wrfout file contains all WRF variables, which is way more than we need at this point, it is convenient to select only the desired variables: U,V,W for wind streamlines, GRNHFX for fire, QVAPOR for smoke and AVG_FUEL_FRAC for the burned area.
The selection of variables can be done in two ways:
* create new NetCDF file with these variables by ("-O" switch overrides the file and if some variable is not available, it will simply skip it)
ncks -v U,V,W,QVAPOR,P,T,GRNHFX,AVG_FUEL_FRAC,PH,PHB,ROS,UF,VF,HGT,ZSF,Times wrfout -O file
wrfvdfcreate file file.vdf
wrf2vdf file.vdf file
The wrfvdfcreate command creates a vdf metafile with a description of the data for Vapor and wrf2vdf created a directory file_data with the actual data.
* the other option is to specify the variables in the wrfvdfcreate call, i.e., run something like
wrfvdfcreate -vars3d U:V:W:QVAPOR -vars2d GRNHFX:AVG_FUEL_FRAC wrfout file.vdf
wrf2vdf file.vdf wrfout
This would create a directory wrfout_data with the same content as the directory file_data above.

* Start VAPOR by clicking on its icon or vaporgui from the command line.
* If you are provided a "Vapor saved session file" *.vss click "File" in the top menu bar and load this file by "Open session" dialogue. In either case, click "Data" in the top menu bar, then "load dataset in the current session", and navigate to the file.vdf (you might have just created). In the black right panel, you should see an empty wireframe box.
* To label the axes with coordinate values click "Edit" in the top main menu, then "Edit Visualizer Features" and check "Show X, Y, Z (R,G,B) Arrows". You can also add "Enable axis annotation", "Time annotation", etc. In case you do not have a terrain image and you will not be able to acquire one using the steps described below, you might check "Display Terrain Surface" and pick (a constant) "Color" you like. If you have an image, do not import it here, but use the "Image tab" discussed below.
* If you do not have an image of the terrain, but your wrfout file contains the geo-coordinates of the domain you can acquire the image from the internet. If you already have an image or you don't know the coordinates then skip this step. We will use Vapor's bash-shell script [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/getWMSImage getWMSImage.sh] for retrieving maps and imagery from a Web Mapping Server (WMS). The call of the script has a general form
getWMSImage.sh [options] minLon minLat maxLon maxLat
where we will use the following options to specify: map type -m landsat (the other option to consider is BMNG, but it seems to give worse quality images), the output file -o filename.tiff and the pixel resolution -r xres yres (the default is 1024x768). Assuming that minLon minLat maxLon maxLat are given as -95.03 29.3 -95.01 29.4, an example call of getWMSImage.sh can be
getWMSImage.sh -m landsat -o fireflux_terrain_geo.tiff -r 1180 1580 -95.03 29.3 -95.01 29.4
Such an image will be automatically geo-referenced, i.e. it will include the longitude/latitude information.
If you have a tiff image which is not geo-referenced, e.g., an image obtained from the Google Earth screenshot, you can use [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/tiff2geotiff tiff2geotiff] to convert it to a geo-referenced terrain image as
tiff2geotiff -4 "+proj=longlat" -n "-95.03 29.3 -95.01 29.4" fireflux_terrain.tiff fireflux_terrain_geo.tiff
* If you have a tiff image of the terrain click on the "Image" tab. In VAPOR 1.5.0 you are allowed to use only tiff images without any compression. If your image is a tiff but not a geotiff (or you are not sure) uncheck "Georeference", then "Select Image File" and navigate to your file. Finally check "Apply image to terrain" and "Instance: 1". After the image is displayed you may also check "Crop to bounds" if needed.
* Click the "Animation" tab and move the "Frame position" slider to a time when you know that the fire has already well developed.
* Click the "2D" tab, select variable GRNHFX, check "Refinement" 2, and "Apply color and opacity to terrain surface", If you do not have *.vtf file, set at the bottom of the tab the colormap and opacity as, e.g., in the following picture (the opacity is sharply cut off near zeros values and set full elsewhere, so that the areas not on fire are fully transparent):
[[File:Vapor-fire-colormap-window.png|600px]]

If there is a *.vtf file available for the colormap and opacity, click "Load TF" and navigate to the file. Finally, check "Instance: 1". You should see the fire area on the terrain. One might also check that the "Z-center" coordinate has a slightly higher value in the "2D" tab than in the "Image" tab, i.e., that the fire will be displayed 'on top of the terrain'.
* On top of the "2D" tab under "Renderer Control" click "New" push "Instance: 2" and select the AVG_FUEL_FRAC variable, check "Refinement" 2, and "Apply color and opacity to terrain surface". Scroll down to "Transfer Function Editor", click "Load Installed TF" and select '''grayscale.vtf'''. The settings for opacity are illustrated by the picture below (the opacity is high and color is dark for regions with little fuel remaining):
[[File:Vapor-avg_fuel_frac-window.png|600px]]

One might also like to make sure that the z-coordinate for AVG_FUEL_FRAC is a bit below the GRNHFX z-coordinate and a bit above the z-coordinate for the terrain image.
Note that the AVG_FUEL_FRAC variable might not be convenient if there are areas that do not contain any fuel a-priori.
* Click the "Flow" tab, make sure that the "steady field" variables are U, V, W and select "Refinement" 2. Scroll down to "Flow Seeding Parameters", select "Nonrandom Rake" and "seed count ... By dimension" to ,e.g., 3, 3, 1. In the "Shape parameters" area set "shape" to arrows, decrease "Diameter" to e.g., 0.5 and in "Color/Opacity mapping" area set "Color" to "Position along flow". Check the box "Instance: 1". If there is a warning about flow lines below zero click "OK", but follow the instructions: in "Edit" top menu select "Edit Visualizer Features" and in the "Variable values outside grid" uncheck for U,V and W the "Extend, down" box so that the "Below" appears in white with 0 value in the box. Hit "Apply" and "OK". One might also like to position the flow streamlines in the vertical direction. This can be done in two ways: either by sliding the "Rake center/sizes" slides in the "Flow Seeding Parameters" portion of the tab, or by clicking the "Region Select Mode" which is the second icon (the box) from the left under the top menu bar. This will display a box with handles in the visualizer window (see the image below) which can be resized by clicking and dragging with the right-button on the mouse. After the region is set, click the"Navigation Mode" icon (the rudder) which is the very left one under the top menu bar.
* Click on the DVR (Direct Volume Rendering) tab and select the QVAPOR variable, which is used to visualize the smoke. This is the tricky part which can be in my opinion hardly 'automated'. One might like to decrease the vertical size of the region in a way described above because there might be a significant amount of vapor present higher in the atmosphere. An example of setting for color and opacity are illustrated by the following picture:
[[File:Vapor-qvapor-window.png|600px]]

Note that the displayed data correspond to the lower 1/3~1/4 (approximately) of the range of values and opacity increases slightly with the values. "Load Installed TF" as '''grayscale.vtf''' and ev. shuffle the color control points if you want the smoke to appear more dark. Also, it might be better to leave the "Refinement" 0 not only because DVR is computationally demanding but also it might provide (surprisingly) better appearance of the fire. Also if one is still looking for the best point of view and is moving the region, it is recommended to uncheck the "Instance: 1" for the moment until the final point of view on the region is found. If the ultimate goal is a video sequence it is better to watch the full sequence using the controls in the "Animation" tab before the final decision about the (color and opacity) settings in the DVR tab for the QVAPOR variable are made.
* To capture a single jpg image, click "Capture" in the top menu bar and "Capture a single image in visualizer 0" and follow the instructions.
* To capture a sequence of jpg images (to be post-processed into a video out of Vapor) click "Capture" in the top menu bar and "Begin image capture sequence in visualizer 0", select directory, then run the movie in the "Animation" tab or using the controls next to the top menu bar, when done click again "Capture" followed by "End image capture sequence". You get the movie frames as a sequence of jpg files. The sequence of images can be processed into an avi in Virtual Dub under windows or using
ffmpeg -f image2 -r 1 -i fireflux_small_%04d.jpg -r 25 -s 512x512 movie.avi

under linux/Mac. The first '-r 1' means the frame rate of the input, so 1 means each picture is displayed for 1 second, 10 means 1/10 of a second, and so on. Use this to adjust the speed of playback. The '-s 512x512' means the resolution of the output in pixels (width x height). While ffmpeg will let you put any numbers here, you should make sure that the width and height are both divisible by 16 otherwise some movie players will not be able to play it.

It looks for input images starting at fireflux_small_0001.jpg and continues until a file doesn't exist. This means if the output starts at 0000, then the first frame will not be in the movie. I don't believe there is a way to configure this aspect of ffmpeg.

This command will create the movie and compress it using a common video codec. It will you use the highest quality setting by default, which is overboard for this kind of movie. So if the files still end up larger than we want, we can always add a couple of more flags to limit the bitrate of the output.

* Use other VAPOR features for a more advanced visualization as desired.

==Works with==
* WRF-Fire {{WRF-Fire-commit|1e710fc81479ea71ed74dd9903da9917fc9dcd93|May 26 2010}} and hopefully later
* VAPOR 1.5.2 and hopefully later
* Tested on MacBook Pro 4GB OS X 10.6 GeForce 8600M GT 512MB

[[Category:Howtos|Visualize WRF-Fire output in VAPOR]]
[[Category:WRF-Fire]]
[[Category:Visualization]]

File:Vapor WRF import.png

2016-05-04T19:41:25Z

Adamko: Adamko uploaded a new version of File:Vapor WRF import.png

Importing WRF-SFIRE data into Vapor.

File:Vapor WRF import.png

2016-05-04T19:38:33Z

Adamko: Adamko uploaded a new version of File:Vapor WRF import.png

Importing WRF-SFIRE data into Vapor.

File:Vapor WRF import.png

2016-05-04T19:26:27Z

Adamko: Importing WRF-SFIRE data into Vapor.

Importing WRF-SFIRE data into Vapor.

How to visualize WRF-Fire output in VAPOR

2016-05-04T19:17:15Z

Adamko: /* Directions */

{{users guide}}
==Prerequistes==

* [[How to run WRF-Fire|A working installation]] of [[WRF-Fire]], possibly on a remote supercomputer or a cluster.
* A visualization computer with a [http://www.vapor.ucar.edu/docs/install/index.php?id=depbin decent graphics card and drivers] (hardware accelerated [[wikipedia:OpenGL|OpenGL]] required), 3 button mouse.
* [http://www.vapor.ucar.edu Download] and install [[VAPOR]] ('''for idealized cases we recommend using Vapor version 2.0.0''' as newer versions have problems with processing wrfoutput data without valid latitude and longitude provided in degrees)
** Read [http://www.vapor.ucar.edu/start Getting started with VAPOR] first.
** On a Mac, run the installation package, then add to your path '''/Applications/VAPOR.app/Contents/MacOS'''
** Do the exercises in the first few pages of the [http://www.vapor.ucar.edu/docs/tutorial VAPOR quick start guide] to learn the basics of the controls.
** VAPOR can be [http://www.cisl.ucar.edu/hss/dasg/userinfo/remotevis.shtml used remotely] over a version of [[wikipedia:VNC|VNC]] with OpenGL support, to avoid transferring huge datasets to your visualization computer.

==Directions==
* [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#Nml Change in '''namelist.input'''] the line with '''history_interval''' to the desired frame interval in seconds, for example '''history_interval_s=1'''. Make sure '''frames_per_outfile''' is large enough so that only one '''wrfout''' file is produced.
* [[How to run WRF-Fire|Run WRF-Fire]]. The pictures below are from the "hill" ideal run in WRF-Fire.
* If the visualization computer is different from the computer where you run WRF-Fire, transfer the '''wrfout''' file to the visualization computer
* Start VAPOR by clicking on its icon or '''vaporgui''' from the command line
* In the GUI, click "Data" on the top menu bar, then "Import WRF output files into current session" or "Data", then "Import data into current session" then select "WRF_ARW" from the submenu, and navigate to your '''wrfout''' file. In the black right panel, you should see an empty wireframe box from the top.
* Click the "Flow" tab, check the box "Instance 1", click "OK" on a warning about flow lines below zero. Select "Refinement" 2. You should see a picture like this (the starting points of the flow lines are picked randomly so they are different in every session):
[[File:Vapor-flowlines-window.png|600px]]
* Click the "Animation" tab and move the "Frame position" slider to the middle (in the ideal "hill" example), or to a time when you know that the fire has already well developed. The flowlines should move a little.
* Click the "2D" tab, check "Instance 1", select "Refinement" 2, and 2D variable '''GRNHFX''', check "Apply color and opacity to terrain surface", and push the "Fit data" button at the bottom.
* Rotate the image with a mouse to see something like this:
[[File:Vapor-fire-window.png|600px]]
* Click on the "Animation" tab, click on the rewind and play VCR controls, and watch the movie. If the movie is too slow, go back to the "Flow" tab and reduce the "Refinement" value.
* To capture the movie, use "Capture", "Begin image capture sequence in visualizer 0", select directory, then run the movie, when done "Capture" "End image capture sequence". You get the movie frames as jpg files.
* Use the DVR tab and other VAPOR features for a more advanced visualization as desired.

==More advanced visualization==

* Optional: If you plan to work with large files (over 2GB), you must have WRF compiled with large file support. This requires a netcdf
library with large file support as well. To compile netcdf with large file support, follow the instructions at [[How to run WRF-Fire]], but add the flag
<code>--enable-largefile</code> to the configure command, and set the environment variable
<code>WRFIO_NCD_LARGE_FILE_SUPPORT=1</code> prior to compiling WRF.

If you are running on a Mac, you can install nco with large file support using [http://www.macports.org/ macports],
sudo port install nco
and see its [http://nco.sourceforge.net/nco.html user's guide] if you wish. On some linux distributions, the binaries that come with the package manager do not support large files. You will need to recompile nco manually from the [http://nco.sourceforge.net/src/nco-4.0.3.tar.gz source package] with the following environment variables set to the location of you netcdf library.
export NETCDF_LIB=${NETCDF}/lib
export NETCDF_INC=${NETCDF}/include

* If the wrfout file contains all WRF variables, which is way more than we need at this point, it is convenient to select only the desired variables: U,V,W for wind streamlines, GRNHFX for fire, QVAPOR for smoke and AVG_FUEL_FRAC for the burned area.
The selection of variables can be done in two ways:
* create new NetCDF file with these variables by ("-O" switch overrides the file and if some variable is not available, it will simply skip it)
ncks -v U,V,W,QVAPOR,P,T,GRNHFX,AVG_FUEL_FRAC,PH,PHB,ROS,UF,VF,HGT,ZSF,Times wrfout -O file
wrfvdfcreate file file.vdf
wrf2vdf file.vdf file
The wrfvdfcreate command creates a vdf metafile with a description of the data for Vapor and wrf2vdf created a directory file_data with the actual data.
* the other option is to specify the variables in the wrfvdfcreate call, i.e., run something like
wrfvdfcreate -vars3d U:V:W:QVAPOR -vars2d GRNHFX:AVG_FUEL_FRAC wrfout file.vdf
wrf2vdf file.vdf wrfout
This would create a directory wrfout_data with the same content as the directory file_data above.

* Start VAPOR by clicking on its icon or vaporgui from the command line.
* If you are provided a "Vapor saved session file" *.vss click "File" in the top menu bar and load this file by "Open session" dialogue. In either case, click "Data" in the top menu bar, then "load dataset in the current session", and navigate to the file.vdf (you might have just created). In the black right panel, you should see an empty wireframe box.
* To label the axes with coordinate values click "Edit" in the top main menu, then "Edit Visualizer Features" and check "Show X, Y, Z (R,G,B) Arrows". You can also add "Enable axis annotation", "Time annotation", etc. In case you do not have a terrain image and you will not be able to acquire one using the steps described below, you might check "Display Terrain Surface" and pick (a constant) "Color" you like. If you have an image, do not import it here, but use the "Image tab" discussed below.
* If you do not have an image of the terrain, but your wrfout file contains the geo-coordinates of the domain you can acquire the image from the internet. If you already have an image or you don't know the coordinates then skip this step. We will use Vapor's bash-shell script [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/getWMSImage getWMSImage.sh] for retrieving maps and imagery from a Web Mapping Server (WMS). The call of the script has a general form
getWMSImage.sh [options] minLon minLat maxLon maxLat
where we will use the following options to specify: map type -m landsat (the other option to consider is BMNG, but it seems to give worse quality images), the output file -o filename.tiff and the pixel resolution -r xres yres (the default is 1024x768). Assuming that minLon minLat maxLon maxLat are given as -95.03 29.3 -95.01 29.4, an example call of getWMSImage.sh can be
getWMSImage.sh -m landsat -o fireflux_terrain_geo.tiff -r 1180 1580 -95.03 29.3 -95.01 29.4
Such an image will be automatically geo-referenced, i.e. it will include the longitude/latitude information.
If you have a tiff image which is not geo-referenced, e.g., an image obtained from the Google Earth screenshot, you can use [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/tiff2geotiff tiff2geotiff] to convert it to a geo-referenced terrain image as
tiff2geotiff -4 "+proj=longlat" -n "-95.03 29.3 -95.01 29.4" fireflux_terrain.tiff fireflux_terrain_geo.tiff
* If you have a tiff image of the terrain click on the "Image" tab. In VAPOR 1.5.0 you are allowed to use only tiff images without any compression. If your image is a tiff but not a geotiff (or you are not sure) uncheck "Georeference", then "Select Image File" and navigate to your file. Finally check "Apply image to terrain" and "Instance: 1". After the image is displayed you may also check "Crop to bounds" if needed.
* Click the "Animation" tab and move the "Frame position" slider to a time when you know that the fire has already well developed.
* Click the "2D" tab, select variable GRNHFX, check "Refinement" 2, and "Apply color and opacity to terrain surface", If you do not have *.vtf file, set at the bottom of the tab the colormap and opacity as, e.g., in the following picture (the opacity is sharply cut off near zeros values and set full elsewhere, so that the areas not on fire are fully transparent):
[[File:Vapor-fire-colormap-window.png|600px]]

If there is a *.vtf file available for the colormap and opacity, click "Load TF" and navigate to the file. Finally, check "Instance: 1". You should see the fire area on the terrain. One might also check that the "Z-center" coordinate has a slightly higher value in the "2D" tab than in the "Image" tab, i.e., that the fire will be displayed 'on top of the terrain'.
* On top of the "2D" tab under "Renderer Control" click "New" push "Instance: 2" and select the AVG_FUEL_FRAC variable, check "Refinement" 2, and "Apply color and opacity to terrain surface". Scroll down to "Transfer Function Editor", click "Load Installed TF" and select '''grayscale.vtf'''. The settings for opacity are illustrated by the picture below (the opacity is high and color is dark for regions with little fuel remaining):
[[File:Vapor-avg_fuel_frac-window.png|600px]]

One might also like to make sure that the z-coordinate for AVG_FUEL_FRAC is a bit below the GRNHFX z-coordinate and a bit above the z-coordinate for the terrain image.
Note that the AVG_FUEL_FRAC variable might not be convenient if there are areas that do not contain any fuel a-priori.
* Click the "Flow" tab, make sure that the "steady field" variables are U, V, W and select "Refinement" 2. Scroll down to "Flow Seeding Parameters", select "Nonrandom Rake" and "seed count ... By dimension" to ,e.g., 3, 3, 1. In the "Shape parameters" area set "shape" to arrows, decrease "Diameter" to e.g., 0.5 and in "Color/Opacity mapping" area set "Color" to "Position along flow". Check the box "Instance: 1". If there is a warning about flow lines below zero click "OK", but follow the instructions: in "Edit" top menu select "Edit Visualizer Features" and in the "Variable values outside grid" uncheck for U,V and W the "Extend, down" box so that the "Below" appears in white with 0 value in the box. Hit "Apply" and "OK". One might also like to position the flow streamlines in the vertical direction. This can be done in two ways: either by sliding the "Rake center/sizes" slides in the "Flow Seeding Parameters" portion of the tab, or by clicking the "Region Select Mode" which is the second icon (the box) from the left under the top menu bar. This will display a box with handles in the visualizer window (see the image below) which can be resized by clicking and dragging with the right-button on the mouse. After the region is set, click the"Navigation Mode" icon (the rudder) which is the very left one under the top menu bar.
* Click on the DVR (Direct Volume Rendering) tab and select the QVAPOR variable, which is used to visualize the smoke. This is the tricky part which can be in my opinion hardly 'automated'. One might like to decrease the vertical size of the region in a way described above because there might be a significant amount of vapor present higher in the atmosphere. An example of setting for color and opacity are illustrated by the following picture:
[[File:Vapor-qvapor-window.png|600px]]

Note that the displayed data correspond to the lower 1/3~1/4 (approximately) of the range of values and opacity increases slightly with the values. "Load Installed TF" as '''grayscale.vtf''' and ev. shuffle the color control points if you want the smoke to appear more dark. Also, it might be better to leave the "Refinement" 0 not only because DVR is computationally demanding but also it might provide (surprisingly) better appearance of the fire. Also if one is still looking for the best point of view and is moving the region, it is recommended to uncheck the "Instance: 1" for the moment until the final point of view on the region is found. If the ultimate goal is a video sequence it is better to watch the full sequence using the controls in the "Animation" tab before the final decision about the (color and opacity) settings in the DVR tab for the QVAPOR variable are made.
* To capture a single jpg image, click "Capture" in the top menu bar and "Capture a single image in visualizer 0" and follow the instructions.
* To capture a sequence of jpg images (to be post-processed into a video out of Vapor) click "Capture" in the top menu bar and "Begin image capture sequence in visualizer 0", select directory, then run the movie in the "Animation" tab or using the controls next to the top menu bar, when done click again "Capture" followed by "End image capture sequence". You get the movie frames as a sequence of jpg files. The sequence of images can be processed into an avi in Virtual Dub under windows or using
ffmpeg -f image2 -r 1 -i fireflux_small_%04d.jpg -r 25 -s 512x512 movie.avi

under linux/Mac. The first '-r 1' means the frame rate of the input, so 1 means each picture is displayed for 1 second, 10 means 1/10 of a second, and so on. Use this to adjust the speed of playback. The '-s 512x512' means the resolution of the output in pixels (width x height). While ffmpeg will let you put any numbers here, you should make sure that the width and height are both divisible by 16 otherwise some movie players will not be able to play it.

It looks for input images starting at fireflux_small_0001.jpg and continues until a file doesn't exist. This means if the output starts at 0000, then the first frame will not be in the movie. I don't believe there is a way to configure this aspect of ffmpeg.

This command will create the movie and compress it using a common video codec. It will you use the highest quality setting by default, which is overboard for this kind of movie. So if the files still end up larger than we want, we can always add a couple of more flags to limit the bitrate of the output.

* Use other VAPOR features for a more advanced visualization as desired.

==Works with==
* WRF-Fire {{WRF-Fire-commit|1e710fc81479ea71ed74dd9903da9917fc9dcd93|May 26 2010}} and hopefully later
* VAPOR 1.5.2 and hopefully later
* Tested on MacBook Pro 4GB OS X 10.6 GeForce 8600M GT 512MB

[[Category:Howtos|Visualize WRF-Fire output in VAPOR]]
[[Category:WRF-Fire]]
[[Category:Visualization]]

How to visualize WRF-Fire output in VAPOR

2016-05-04T19:13:00Z

Adamko: /* Prerequistes */

{{users guide}}
==Prerequistes==

* [[How to run WRF-Fire|A working installation]] of [[WRF-Fire]], possibly on a remote supercomputer or a cluster.
* A visualization computer with a [http://www.vapor.ucar.edu/docs/install/index.php?id=depbin decent graphics card and drivers] (hardware accelerated [[wikipedia:OpenGL|OpenGL]] required), 3 button mouse.
* [http://www.vapor.ucar.edu Download] and install [[VAPOR]] ('''for idealized cases we recommend using Vapor version 2.0.0''' as newer versions have problems with processing wrfoutput data without valid latitude and longitude provided in degrees)
** Read [http://www.vapor.ucar.edu/start Getting started with VAPOR] first.
** On a Mac, run the installation package, then add to your path '''/Applications/VAPOR.app/Contents/MacOS'''
** Do the exercises in the first few pages of the [http://www.vapor.ucar.edu/docs/tutorial VAPOR quick start guide] to learn the basics of the controls.
** VAPOR can be [http://www.cisl.ucar.edu/hss/dasg/userinfo/remotevis.shtml used remotely] over a version of [[wikipedia:VNC|VNC]] with OpenGL support, to avoid transferring huge datasets to your visualization computer.

==Directions==
* [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#Nml Change in '''namelist.input'''] the line with '''history_interval''' to the desired frame interval in seconds, for example '''history_interval_s=1'''. Make sure '''frames_per_outfile''' is large enough so that only one '''wrfout''' file is produced.
* [[How to run WRF-Fire|Run WRF-Fire]]. The pictures below are from the "hill" ideal run in WRF-Fire.
* If the visualization computer is different from the computer where you run WRF-Fire, transfer the '''wrfout''' file to the visualization computer
* Convert the '''wrfout''' file for use with VAPOR: run from the command line
** '''wrfvdfcreate yourwrfoutfile yourwdffile.vdf'''
** '''wrf2vdf yourwdffile.vdf yourwrfoutfile'''
* Start VAPOR by clicking on its icon or '''vaporgui''' from the command line
* In the GUI, click "Data" on the top menu bar, then "load dataset in the current session", and navigate to the '''yourwdffile.vdf''' you have just created. In the black right panel, you should see an empty wireframe box from the top.
* Click the "Flow" tab, check the box "Instance 1", click "OK" on a warning about flow lines below zero. Select "Refinement" 2. You should see a picture like this (the starting points of the flow lines are picked randomly so they are different in every session):
[[File:Vapor-flowlines-window.png|600px]]
* Click the "Animation" tab and move the "Frame position" slider to the middle (in the ideal "hill" example), or to a time when you know that the fire has already well developed. The flowlines should move a little.
* Click the "2D" tab, check "Instance 1", select "Refinement" 2, and 2D variable '''GRNHFX''', check "Apply color and opacity to terrain surface", and push the "Fit data" button at the bottom.
* Rotate the image with a mouse to see something like this:
[[File:Vapor-fire-window.png|600px]]
* Click on the "Animation" tab, click on the rewind and play VCR controls, and watch the movie. If the movie is too slow, go back to the "Flow" tab and reduce the "Refinement" value.
* To capture the movie, use "Capture", "Begin image capture sequence in visualizer 0", select directory, then run the movie, when done "Capture" "End image capture sequence". You get the movie frames as jpg files.
* Use the DVR tab and other VAPOR features for a more advanced visualization as desired.

==More advanced visualization==

* Optional: If you plan to work with large files (over 2GB), you must have WRF compiled with large file support. This requires a netcdf
library with large file support as well. To compile netcdf with large file support, follow the instructions at [[How to run WRF-Fire]], but add the flag
<code>--enable-largefile</code> to the configure command, and set the environment variable
<code>WRFIO_NCD_LARGE_FILE_SUPPORT=1</code> prior to compiling WRF.

If you are running on a Mac, you can install nco with large file support using [http://www.macports.org/ macports],
sudo port install nco
and see its [http://nco.sourceforge.net/nco.html user's guide] if you wish. On some linux distributions, the binaries that come with the package manager do not support large files. You will need to recompile nco manually from the [http://nco.sourceforge.net/src/nco-4.0.3.tar.gz source package] with the following environment variables set to the location of you netcdf library.
export NETCDF_LIB=${NETCDF}/lib
export NETCDF_INC=${NETCDF}/include

* If the wrfout file contains all WRF variables, which is way more than we need at this point, it is convenient to select only the desired variables: U,V,W for wind streamlines, GRNHFX for fire, QVAPOR for smoke and AVG_FUEL_FRAC for the burned area.
The selection of variables can be done in two ways:
* create new NetCDF file with these variables by ("-O" switch overrides the file and if some variable is not available, it will simply skip it)
ncks -v U,V,W,QVAPOR,P,T,GRNHFX,AVG_FUEL_FRAC,PH,PHB,ROS,UF,VF,HGT,ZSF,Times wrfout -O file
wrfvdfcreate file file.vdf
wrf2vdf file.vdf file
The wrfvdfcreate command creates a vdf metafile with a description of the data for Vapor and wrf2vdf created a directory file_data with the actual data.
* the other option is to specify the variables in the wrfvdfcreate call, i.e., run something like
wrfvdfcreate -vars3d U:V:W:QVAPOR -vars2d GRNHFX:AVG_FUEL_FRAC wrfout file.vdf
wrf2vdf file.vdf wrfout
This would create a directory wrfout_data with the same content as the directory file_data above.

* Start VAPOR by clicking on its icon or vaporgui from the command line.
* If you are provided a "Vapor saved session file" *.vss click "File" in the top menu bar and load this file by "Open session" dialogue. In either case, click "Data" in the top menu bar, then "load dataset in the current session", and navigate to the file.vdf (you might have just created). In the black right panel, you should see an empty wireframe box.
* To label the axes with coordinate values click "Edit" in the top main menu, then "Edit Visualizer Features" and check "Show X, Y, Z (R,G,B) Arrows". You can also add "Enable axis annotation", "Time annotation", etc. In case you do not have a terrain image and you will not be able to acquire one using the steps described below, you might check "Display Terrain Surface" and pick (a constant) "Color" you like. If you have an image, do not import it here, but use the "Image tab" discussed below.
* If you do not have an image of the terrain, but your wrfout file contains the geo-coordinates of the domain you can acquire the image from the internet. If you already have an image or you don't know the coordinates then skip this step. We will use Vapor's bash-shell script [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/getWMSImage getWMSImage.sh] for retrieving maps and imagery from a Web Mapping Server (WMS). The call of the script has a general form
getWMSImage.sh [options] minLon minLat maxLon maxLat
where we will use the following options to specify: map type -m landsat (the other option to consider is BMNG, but it seems to give worse quality images), the output file -o filename.tiff and the pixel resolution -r xres yres (the default is 1024x768). Assuming that minLon minLat maxLon maxLat are given as -95.03 29.3 -95.01 29.4, an example call of getWMSImage.sh can be
getWMSImage.sh -m landsat -o fireflux_terrain_geo.tiff -r 1180 1580 -95.03 29.3 -95.01 29.4
Such an image will be automatically geo-referenced, i.e. it will include the longitude/latitude information.
If you have a tiff image which is not geo-referenced, e.g., an image obtained from the Google Earth screenshot, you can use [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/tiff2geotiff tiff2geotiff] to convert it to a geo-referenced terrain image as
tiff2geotiff -4 "+proj=longlat" -n "-95.03 29.3 -95.01 29.4" fireflux_terrain.tiff fireflux_terrain_geo.tiff
* If you have a tiff image of the terrain click on the "Image" tab. In VAPOR 1.5.0 you are allowed to use only tiff images without any compression. If your image is a tiff but not a geotiff (or you are not sure) uncheck "Georeference", then "Select Image File" and navigate to your file. Finally check "Apply image to terrain" and "Instance: 1". After the image is displayed you may also check "Crop to bounds" if needed.
* Click the "Animation" tab and move the "Frame position" slider to a time when you know that the fire has already well developed.
* Click the "2D" tab, select variable GRNHFX, check "Refinement" 2, and "Apply color and opacity to terrain surface", If you do not have *.vtf file, set at the bottom of the tab the colormap and opacity as, e.g., in the following picture (the opacity is sharply cut off near zeros values and set full elsewhere, so that the areas not on fire are fully transparent):
[[File:Vapor-fire-colormap-window.png|600px]]

If there is a *.vtf file available for the colormap and opacity, click "Load TF" and navigate to the file. Finally, check "Instance: 1". You should see the fire area on the terrain. One might also check that the "Z-center" coordinate has a slightly higher value in the "2D" tab than in the "Image" tab, i.e., that the fire will be displayed 'on top of the terrain'.
* On top of the "2D" tab under "Renderer Control" click "New" push "Instance: 2" and select the AVG_FUEL_FRAC variable, check "Refinement" 2, and "Apply color and opacity to terrain surface". Scroll down to "Transfer Function Editor", click "Load Installed TF" and select '''grayscale.vtf'''. The settings for opacity are illustrated by the picture below (the opacity is high and color is dark for regions with little fuel remaining):
[[File:Vapor-avg_fuel_frac-window.png|600px]]

One might also like to make sure that the z-coordinate for AVG_FUEL_FRAC is a bit below the GRNHFX z-coordinate and a bit above the z-coordinate for the terrain image.
Note that the AVG_FUEL_FRAC variable might not be convenient if there are areas that do not contain any fuel a-priori.
* Click the "Flow" tab, make sure that the "steady field" variables are U, V, W and select "Refinement" 2. Scroll down to "Flow Seeding Parameters", select "Nonrandom Rake" and "seed count ... By dimension" to ,e.g., 3, 3, 1. In the "Shape parameters" area set "shape" to arrows, decrease "Diameter" to e.g., 0.5 and in "Color/Opacity mapping" area set "Color" to "Position along flow". Check the box "Instance: 1". If there is a warning about flow lines below zero click "OK", but follow the instructions: in "Edit" top menu select "Edit Visualizer Features" and in the "Variable values outside grid" uncheck for U,V and W the "Extend, down" box so that the "Below" appears in white with 0 value in the box. Hit "Apply" and "OK". One might also like to position the flow streamlines in the vertical direction. This can be done in two ways: either by sliding the "Rake center/sizes" slides in the "Flow Seeding Parameters" portion of the tab, or by clicking the "Region Select Mode" which is the second icon (the box) from the left under the top menu bar. This will display a box with handles in the visualizer window (see the image below) which can be resized by clicking and dragging with the right-button on the mouse. After the region is set, click the"Navigation Mode" icon (the rudder) which is the very left one under the top menu bar.
* Click on the DVR (Direct Volume Rendering) tab and select the QVAPOR variable, which is used to visualize the smoke. This is the tricky part which can be in my opinion hardly 'automated'. One might like to decrease the vertical size of the region in a way described above because there might be a significant amount of vapor present higher in the atmosphere. An example of setting for color and opacity are illustrated by the following picture:
[[File:Vapor-qvapor-window.png|600px]]

Note that the displayed data correspond to the lower 1/3~1/4 (approximately) of the range of values and opacity increases slightly with the values. "Load Installed TF" as '''grayscale.vtf''' and ev. shuffle the color control points if you want the smoke to appear more dark. Also, it might be better to leave the "Refinement" 0 not only because DVR is computationally demanding but also it might provide (surprisingly) better appearance of the fire. Also if one is still looking for the best point of view and is moving the region, it is recommended to uncheck the "Instance: 1" for the moment until the final point of view on the region is found. If the ultimate goal is a video sequence it is better to watch the full sequence using the controls in the "Animation" tab before the final decision about the (color and opacity) settings in the DVR tab for the QVAPOR variable are made.
* To capture a single jpg image, click "Capture" in the top menu bar and "Capture a single image in visualizer 0" and follow the instructions.
* To capture a sequence of jpg images (to be post-processed into a video out of Vapor) click "Capture" in the top menu bar and "Begin image capture sequence in visualizer 0", select directory, then run the movie in the "Animation" tab or using the controls next to the top menu bar, when done click again "Capture" followed by "End image capture sequence". You get the movie frames as a sequence of jpg files. The sequence of images can be processed into an avi in Virtual Dub under windows or using
ffmpeg -f image2 -r 1 -i fireflux_small_%04d.jpg -r 25 -s 512x512 movie.avi

under linux/Mac. The first '-r 1' means the frame rate of the input, so 1 means each picture is displayed for 1 second, 10 means 1/10 of a second, and so on. Use this to adjust the speed of playback. The '-s 512x512' means the resolution of the output in pixels (width x height). While ffmpeg will let you put any numbers here, you should make sure that the width and height are both divisible by 16 otherwise some movie players will not be able to play it.

It looks for input images starting at fireflux_small_0001.jpg and continues until a file doesn't exist. This means if the output starts at 0000, then the first frame will not be in the movie. I don't believe there is a way to configure this aspect of ffmpeg.

This command will create the movie and compress it using a common video codec. It will you use the highest quality setting by default, which is overboard for this kind of movie. So if the files still end up larger than we want, we can always add a couple of more flags to limit the bitrate of the output.

* Use other VAPOR features for a more advanced visualization as desired.

==Works with==
* WRF-Fire {{WRF-Fire-commit|1e710fc81479ea71ed74dd9903da9917fc9dcd93|May 26 2010}} and hopefully later
* VAPOR 1.5.2 and hopefully later
* Tested on MacBook Pro 4GB OS X 10.6 GeForce 8600M GT 512MB

[[Category:Howtos|Visualize WRF-Fire output in VAPOR]]
[[Category:WRF-Fire]]
[[Category:Visualization]]

How to visualize WRF-Fire output in VAPOR

2016-05-04T19:06:07Z

Adamko: /* Prerequistes */

{{users guide}}
==Prerequistes==

* [[How to run WRF-Fire|A working installation]] of [[WRF-Fire]], possibly on a remote supercomputer or a cluster.
* A visualization computer with a [http://www.vapor.ucar.edu/docs/install/index.php?id=depbin decent graphics card and drivers] (hardware accelerated [[wikipedia:OpenGL|OpenGL]] required), 3 button mouse.
* [http://www.vapor.ucar.edu Download] and install [[VAPOR]] ('''for idealized cases we recommend using Vapor version 2.0.0 or earlier''' as newer versions have problems with processing wrfoutput data without valid latitude and longitude provided in degrees)
** Read [http://www.vapor.ucar.edu/start Getting started with VAPOR] first.
** On a Mac, run the installation package, then add to your path '''/Applications/VAPOR.app/Contents/MacOS'''
** Do the exercises in the first few pages of the [http://www.vapor.ucar.edu/docs/tutorial VAPOR quick start guide] to learn the basics of the controls.
** VAPOR can be [http://www.cisl.ucar.edu/hss/dasg/userinfo/remotevis.shtml used remotely] over a version of [[wikipedia:VNC|VNC]] with OpenGL support, to avoid transferring huge datasets to your visualization computer.

==Directions==
* [http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#Nml Change in '''namelist.input'''] the line with '''history_interval''' to the desired frame interval in seconds, for example '''history_interval_s=1'''. Make sure '''frames_per_outfile''' is large enough so that only one '''wrfout''' file is produced.
* [[How to run WRF-Fire|Run WRF-Fire]]. The pictures below are from the "hill" ideal run in WRF-Fire.
* If the visualization computer is different from the computer where you run WRF-Fire, transfer the '''wrfout''' file to the visualization computer
* Convert the '''wrfout''' file for use with VAPOR: run from the command line
** '''wrfvdfcreate yourwrfoutfile yourwdffile.vdf'''
** '''wrf2vdf yourwdffile.vdf yourwrfoutfile'''
* Start VAPOR by clicking on its icon or '''vaporgui''' from the command line
* In the GUI, click "Data" on the top menu bar, then "load dataset in the current session", and navigate to the '''yourwdffile.vdf''' you have just created. In the black right panel, you should see an empty wireframe box from the top.
* Click the "Flow" tab, check the box "Instance 1", click "OK" on a warning about flow lines below zero. Select "Refinement" 2. You should see a picture like this (the starting points of the flow lines are picked randomly so they are different in every session):
[[File:Vapor-flowlines-window.png|600px]]
* Click the "Animation" tab and move the "Frame position" slider to the middle (in the ideal "hill" example), or to a time when you know that the fire has already well developed. The flowlines should move a little.
* Click the "2D" tab, check "Instance 1", select "Refinement" 2, and 2D variable '''GRNHFX''', check "Apply color and opacity to terrain surface", and push the "Fit data" button at the bottom.
* Rotate the image with a mouse to see something like this:
[[File:Vapor-fire-window.png|600px]]
* Click on the "Animation" tab, click on the rewind and play VCR controls, and watch the movie. If the movie is too slow, go back to the "Flow" tab and reduce the "Refinement" value.
* To capture the movie, use "Capture", "Begin image capture sequence in visualizer 0", select directory, then run the movie, when done "Capture" "End image capture sequence". You get the movie frames as jpg files.
* Use the DVR tab and other VAPOR features for a more advanced visualization as desired.

==More advanced visualization==

* Optional: If you plan to work with large files (over 2GB), you must have WRF compiled with large file support. This requires a netcdf
library with large file support as well. To compile netcdf with large file support, follow the instructions at [[How to run WRF-Fire]], but add the flag
<code>--enable-largefile</code> to the configure command, and set the environment variable
<code>WRFIO_NCD_LARGE_FILE_SUPPORT=1</code> prior to compiling WRF.

If you are running on a Mac, you can install nco with large file support using [http://www.macports.org/ macports],
sudo port install nco
and see its [http://nco.sourceforge.net/nco.html user's guide] if you wish. On some linux distributions, the binaries that come with the package manager do not support large files. You will need to recompile nco manually from the [http://nco.sourceforge.net/src/nco-4.0.3.tar.gz source package] with the following environment variables set to the location of you netcdf library.
export NETCDF_LIB=${NETCDF}/lib
export NETCDF_INC=${NETCDF}/include

* If the wrfout file contains all WRF variables, which is way more than we need at this point, it is convenient to select only the desired variables: U,V,W for wind streamlines, GRNHFX for fire, QVAPOR for smoke and AVG_FUEL_FRAC for the burned area.
The selection of variables can be done in two ways:
* create new NetCDF file with these variables by ("-O" switch overrides the file and if some variable is not available, it will simply skip it)
ncks -v U,V,W,QVAPOR,P,T,GRNHFX,AVG_FUEL_FRAC,PH,PHB,ROS,UF,VF,HGT,ZSF,Times wrfout -O file
wrfvdfcreate file file.vdf
wrf2vdf file.vdf file
The wrfvdfcreate command creates a vdf metafile with a description of the data for Vapor and wrf2vdf created a directory file_data with the actual data.
* the other option is to specify the variables in the wrfvdfcreate call, i.e., run something like
wrfvdfcreate -vars3d U:V:W:QVAPOR -vars2d GRNHFX:AVG_FUEL_FRAC wrfout file.vdf
wrf2vdf file.vdf wrfout
This would create a directory wrfout_data with the same content as the directory file_data above.

* Start VAPOR by clicking on its icon or vaporgui from the command line.
* If you are provided a "Vapor saved session file" *.vss click "File" in the top menu bar and load this file by "Open session" dialogue. In either case, click "Data" in the top menu bar, then "load dataset in the current session", and navigate to the file.vdf (you might have just created). In the black right panel, you should see an empty wireframe box.
* To label the axes with coordinate values click "Edit" in the top main menu, then "Edit Visualizer Features" and check "Show X, Y, Z (R,G,B) Arrows". You can also add "Enable axis annotation", "Time annotation", etc. In case you do not have a terrain image and you will not be able to acquire one using the steps described below, you might check "Display Terrain Surface" and pick (a constant) "Color" you like. If you have an image, do not import it here, but use the "Image tab" discussed below.
* If you do not have an image of the terrain, but your wrfout file contains the geo-coordinates of the domain you can acquire the image from the internet. If you already have an image or you don't know the coordinates then skip this step. We will use Vapor's bash-shell script [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/getWMSImage getWMSImage.sh] for retrieving maps and imagery from a Web Mapping Server (WMS). The call of the script has a general form
getWMSImage.sh [options] minLon minLat maxLon maxLat
where we will use the following options to specify: map type -m landsat (the other option to consider is BMNG, but it seems to give worse quality images), the output file -o filename.tiff and the pixel resolution -r xres yres (the default is 1024x768). Assuming that minLon minLat maxLon maxLat are given as -95.03 29.3 -95.01 29.4, an example call of getWMSImage.sh can be
getWMSImage.sh -m landsat -o fireflux_terrain_geo.tiff -r 1180 1580 -95.03 29.3 -95.01 29.4
Such an image will be automatically geo-referenced, i.e. it will include the longitude/latitude information.
If you have a tiff image which is not geo-referenced, e.g., an image obtained from the Google Earth screenshot, you can use [http://www.vapor.ucar.edu/docs/reference/index.php?id=man/tiff2geotiff tiff2geotiff] to convert it to a geo-referenced terrain image as
tiff2geotiff -4 "+proj=longlat" -n "-95.03 29.3 -95.01 29.4" fireflux_terrain.tiff fireflux_terrain_geo.tiff
* If you have a tiff image of the terrain click on the "Image" tab. In VAPOR 1.5.0 you are allowed to use only tiff images without any compression. If your image is a tiff but not a geotiff (or you are not sure) uncheck "Georeference", then "Select Image File" and navigate to your file. Finally check "Apply image to terrain" and "Instance: 1". After the image is displayed you may also check "Crop to bounds" if needed.
* Click the "Animation" tab and move the "Frame position" slider to a time when you know that the fire has already well developed.
* Click the "2D" tab, select variable GRNHFX, check "Refinement" 2, and "Apply color and opacity to terrain surface", If you do not have *.vtf file, set at the bottom of the tab the colormap and opacity as, e.g., in the following picture (the opacity is sharply cut off near zeros values and set full elsewhere, so that the areas not on fire are fully transparent):
[[File:Vapor-fire-colormap-window.png|600px]]

If there is a *.vtf file available for the colormap and opacity, click "Load TF" and navigate to the file. Finally, check "Instance: 1". You should see the fire area on the terrain. One might also check that the "Z-center" coordinate has a slightly higher value in the "2D" tab than in the "Image" tab, i.e., that the fire will be displayed 'on top of the terrain'.
* On top of the "2D" tab under "Renderer Control" click "New" push "Instance: 2" and select the AVG_FUEL_FRAC variable, check "Refinement" 2, and "Apply color and opacity to terrain surface". Scroll down to "Transfer Function Editor", click "Load Installed TF" and select '''grayscale.vtf'''. The settings for opacity are illustrated by the picture below (the opacity is high and color is dark for regions with little fuel remaining):
[[File:Vapor-avg_fuel_frac-window.png|600px]]

One might also like to make sure that the z-coordinate for AVG_FUEL_FRAC is a bit below the GRNHFX z-coordinate and a bit above the z-coordinate for the terrain image.
Note that the AVG_FUEL_FRAC variable might not be convenient if there are areas that do not contain any fuel a-priori.
* Click the "Flow" tab, make sure that the "steady field" variables are U, V, W and select "Refinement" 2. Scroll down to "Flow Seeding Parameters", select "Nonrandom Rake" and "seed count ... By dimension" to ,e.g., 3, 3, 1. In the "Shape parameters" area set "shape" to arrows, decrease "Diameter" to e.g., 0.5 and in "Color/Opacity mapping" area set "Color" to "Position along flow". Check the box "Instance: 1". If there is a warning about flow lines below zero click "OK", but follow the instructions: in "Edit" top menu select "Edit Visualizer Features" and in the "Variable values outside grid" uncheck for U,V and W the "Extend, down" box so that the "Below" appears in white with 0 value in the box. Hit "Apply" and "OK". One might also like to position the flow streamlines in the vertical direction. This can be done in two ways: either by sliding the "Rake center/sizes" slides in the "Flow Seeding Parameters" portion of the tab, or by clicking the "Region Select Mode" which is the second icon (the box) from the left under the top menu bar. This will display a box with handles in the visualizer window (see the image below) which can be resized by clicking and dragging with the right-button on the mouse. After the region is set, click the"Navigation Mode" icon (the rudder) which is the very left one under the top menu bar.
* Click on the DVR (Direct Volume Rendering) tab and select the QVAPOR variable, which is used to visualize the smoke. This is the tricky part which can be in my opinion hardly 'automated'. One might like to decrease the vertical size of the region in a way described above because there might be a significant amount of vapor present higher in the atmosphere. An example of setting for color and opacity are illustrated by the following picture:
[[File:Vapor-qvapor-window.png|600px]]

Note that the displayed data correspond to the lower 1/3~1/4 (approximately) of the range of values and opacity increases slightly with the values. "Load Installed TF" as '''grayscale.vtf''' and ev. shuffle the color control points if you want the smoke to appear more dark. Also, it might be better to leave the "Refinement" 0 not only because DVR is computationally demanding but also it might provide (surprisingly) better appearance of the fire. Also if one is still looking for the best point of view and is moving the region, it is recommended to uncheck the "Instance: 1" for the moment until the final point of view on the region is found. If the ultimate goal is a video sequence it is better to watch the full sequence using the controls in the "Animation" tab before the final decision about the (color and opacity) settings in the DVR tab for the QVAPOR variable are made.
* To capture a single jpg image, click "Capture" in the top menu bar and "Capture a single image in visualizer 0" and follow the instructions.
* To capture a sequence of jpg images (to be post-processed into a video out of Vapor) click "Capture" in the top menu bar and "Begin image capture sequence in visualizer 0", select directory, then run the movie in the "Animation" tab or using the controls next to the top menu bar, when done click again "Capture" followed by "End image capture sequence". You get the movie frames as a sequence of jpg files. The sequence of images can be processed into an avi in Virtual Dub under windows or using
ffmpeg -f image2 -r 1 -i fireflux_small_%04d.jpg -r 25 -s 512x512 movie.avi

under linux/Mac. The first '-r 1' means the frame rate of the input, so 1 means each picture is displayed for 1 second, 10 means 1/10 of a second, and so on. Use this to adjust the speed of playback. The '-s 512x512' means the resolution of the output in pixels (width x height). While ffmpeg will let you put any numbers here, you should make sure that the width and height are both divisible by 16 otherwise some movie players will not be able to play it.

It looks for input images starting at fireflux_small_0001.jpg and continues until a file doesn't exist. This means if the output starts at 0000, then the first frame will not be in the movie. I don't believe there is a way to configure this aspect of ffmpeg.

This command will create the movie and compress it using a common video codec. It will you use the highest quality setting by default, which is overboard for this kind of movie. So if the files still end up larger than we want, we can always add a couple of more flags to limit the bitrate of the output.

* Use other VAPOR features for a more advanced visualization as desired.

==Works with==
* WRF-Fire {{WRF-Fire-commit|1e710fc81479ea71ed74dd9903da9917fc9dcd93|May 26 2010}} and hopefully later
* VAPOR 1.5.2 and hopefully later
* Tested on MacBook Pro 4GB OS X 10.6 GeForce 8600M GT 512MB

[[Category:Howtos|Visualize WRF-Fire output in VAPOR]]
[[Category:WRF-Fire]]
[[Category:Visualization]]

WPS with GeoTIFF support

2016-05-04T19:01:31Z

Adamko: /* Installing GeoTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here] or directly from [http://download.osgeo.org/libtiff/tiff-4.0.6.zip here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here] or directly from [https://github.com/OSGeo/proj.4/archive/master.zip here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here] or directly from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/libgeotiff-1.4.1.zip here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you remeber to clean it firts:
./clean -a
Then configure it again
./configure
and compile
./compile

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T19:00:00Z

Adamko: /* Installing libTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here] or directly from [http://download.osgeo.org/libtiff/tiff-4.0.6.zip here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here] or directly from [https://github.com/OSGeo/proj.4/archive/master.zip here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you remeber to clean it firts:
./clean -a
Then configure it again
./configure
and compile
./compile

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:58:54Z

Adamko: /* Installing GeoTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here] or directly from [https://github.com/OSGeo/proj.4/archive/master.zip here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you remeber to clean it firts:
./clean -a
Then configure it again
./configure
and compile
./compile

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:57:26Z

Adamko: /* Setting up the environment */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you remeber to clean it firts:
./clean -a
Then configure it again
./configure
and compile
./compile

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:56:24Z

Adamko: /* Installing GeoTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:56:03Z

Adamko: /* Setting up the environment */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you will need to clean it:
./clean -a
Then configure it again
./configure
and compile
./compile

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script.
export LIBTIFF=~/wpslibs
export GEOTIFF=~/wpslibs

You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:53:16Z

Adamko: /* Installing GeoTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

GeoTIFF may complain about using relative paths, so if that is the case provide the full path to your wpslibs directory. For instance:
./configure --with-libtiff=/home/your_user_name/wpslibs --with-proj=/home/your_user_name/wpslibs --prefix=/home/your_user_name/
make
make install

After this step you are ready to compile WPS (WRF must be already compiled). If you have an old WPS version compiled before you will need to clean it:
./clean -a
Then configure it again
./configure
and compile
./compile

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script. You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:41:18Z

Adamko: /* Installing GeoTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./autogen.sh (skip if configure script is already there)
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script. You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

WPS with GeoTIFF support

2016-05-04T18:38:06Z

Adamko: /* Installing libTIFF from source */

{{users guide}}
As of {{WRF-Fire-commit|d5746414a0bee94c1a18435cd7be9b2b311e338f|April 6, 2011}}, WRF-Fire's version of WPS supports reading of [http://trac.osgeo.org/geotiff/ geotiff] files directly without [[How to convert data for Geogrid|converting]] to geogrid's binary format. This feature has been added to make it easier to incorporate high resolution data for real WRF-Fire simulations. WPS must be linked with GeoTIFF support in order to use this feature. To maintain compatibility, GeoTIFF support is not compiled in unless the necessary libraries are installed.

=Prerequisite libraries=
In order to use this feature, the user must have both the [http://trac.osgeo.org/geotiff/ GeoTIFF] and [http://www.libtiff.org/ TIFF] libraries installed. For many linux distributions, it is possible to install these libraries using its package manager. Using Ubuntu,
sudo apt-get install geotiff-bin
or Fedora,
sudo yum install libgeotiff-devel
will install everything required. For other distributions, search the package manager for geotiff; you will need the development libraries if they are packaged separately. Users of Mac OSX can install [http://www.macports.org/install.php macports] and use the command
sudo port install libgeotiff
to install all necessary libraries.

==Installing libTIFF from source==

The current stable version of libTIFF is 3.9.4; however, we recommend you use the latest development release of version 4.0. Version 4.0 of libTIFF adds support for what is called BigTIFF, which are images larger than 2^32 bytes. BigTIFF files are often seen in large GeoTIFF datasets that you may want to use with WRF-Fire. To install, get the latest source package from [http://download.osgeo.org/libtiff/ here], extract it, and go to the extracted directory in your terminal. You will want to choose a place to install the new libraries, such as <code>~/wpslibs</code> and create this directory by mkdir ~/wpslibs . Run the configure script telling it where you want the library installed, then build and install.
./configure --prefix ~/wpslibs
make
make install

==Installing GeoTIFF from source==

In order to make use of GeoTIFF images containing projected data, you must compile GeoTIFF with PROJ.4 support. Download the source code for PROJ.4 [http://trac.osgeo.org/proj/ here], then extract and install it into your library installation path.
./configure --prefix ~/wpslibs
make
make install
Now, you can download GeoTIFF from [ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/ here]. Extract the archive and compile with PROJ.4 support.
./configure --with-libtiff=~/wpslibs --with-proj=~/wpslibs --prefix=~/wpslibs
make
make install

=Setting up the environment=

Before compiling WPS, you must set environment variables informing the configure script where to find the GeoTIFF libraries. The convention for these environment variables is the same as for the netCDF libraries; you must set <code>LIBTIFF</code> and <code>GEOTIFF</code> to the prefix path of TIFF and GeoTIFF, respectively. If you installed the libraries using the package manager on Linux, the prefix path for each will be <code>/usr</code>, as follows.
export LIBTIFF=/usr
export GEOTIFF=/usr
If you installed GeoTIFF with macports, the prefix is <code>/opt/local</code>.
export LIBTIFF=/opt/local
export GEOTIFF=/opt/local
If you installed from source, then the prefix is the path given to the configure script. You may also need to configure the shared library search path, especially if you installed from source. This can be done with the following command.
export LD_LIBRARY_PATH=$GEOTIFF/lib
You may want to add these environment variables to your startup (such as <code>~/.bash_profile</code>) file to avoid having to type them in every time you log in or open a new terminal window.

=Using GeoTIFF with WPS=

With the environment properly set up, you can compile [[How to compile WRF-Fire|WRF]] and [[How to run WRF-Fire with real data#Compiling WPS|WPS]] in the normal way.

==Specifying a GeoTIFF dataset for geogrid==

The procedure for using a dataset in geogrid involves adding a field specification to the file <code>geogrid/GEOGRID.TBL</code>. The field specification provides paths to one or more datasets that can be used to initial the field. These paths must each contain a text file named <code>index</code>, which details the storage format of the data contained in that directory. The specification of GeoTIFF files follows this convention; however, the <code>index</code> file must (at the least) contain a line such as <code>geotiff=XXXX.tif</code> giving the name of the GeoTIFF file residing in the same directory.

For example, if you have a GeoTIFF file named <code>topo.tif</code> containing
topographical data that you want to use for the field <code>ZSF</code>, you would edit the <code>ZSF</code> section of <code>geogrid/GEOGRID.TBL</code> with the line <code>abs_path=./ned_data</code>. Then create a directory under <code>WPS</code> called <code>ned_data</code>, and copy <code>topo.tif</code> to this directory. Finally, you would add a text file called <code>index</code> inside <code>ned_data</code> containing the line:
geotiff=topo.tif
This would tell geogrid that the file <code>ned_data/topo.gif</code> contains a GeoTIFF file that should be used to fill the field <code>ZSF</code>. The new extension to WPS will provide geogrid with the cartographic projection and storage details that are normally provided in the index. Geogrid requires a bit more information about categorical fields than is actually provided by GeoTIFF. For these fields, you must also specify values for <code>type</code>, <code>category_min</code>, and <code>category_max</code>.

While for a continuous field such as <code>ZSF</code> this is the only line that absolutely must be in the index, you may wish to provide more information that cannot be determined from the GeoTIFF metadata. All parameters supported by standard geogrid index files are allowed in GeoTIFF index files as well. If a setting is present in the index file, it will override anything read from the GeoTIFF metadata. This is useful in case the GeoTIFF extension or the GeoTIFF file itself provides incorrect information; the user can easily fix it by providing the correct value in the index. To assist in debugging, geogrid creates a log file called <code>geogrid.log</code>; this log contains source data parameters that were actually used. Check this file for anything incorrect.

For importing high resolution data from GeoTIFF files for WRF-Fire, we recommend the following index files:
#ned_data/index
geotiff = ned_data.tif
description = "Topography height"
type = continuous
units = "meters"
description = "National Elevation Dataset"
tile_bdr = 3

#landfire_data/index
geotiff = lf_data.tif
type = categorical
category_min = 1
category_max = 14
tile_bdr = 3
units = "category"
missing_value = 14

File:Corsica Numerical Wildfires 2013 4Web.pdf

2013-09-09T18:23:01Z

Adamko: Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Martin Vejmelka, Forecasting of smoke and wildfire emissions using WRF-Sfire, Numerical Wildfires, Cargese, Corsica, 17th May 2013.

Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Martin Vejmelka, Forecasting of smoke and wildfire emissions using WRF-Sfire, Numerical Wildfires, Cargese, Corsica, 17th May 2013.

Publications

2013-09-09T18:17:59Z

Adamko: /* Conference papers */

{{users guide}}

==WRF-Fire description==

: ''The [[WRF-Fire]] code is described in these papers.''

===Journal papers===

* Jan Mandel, Jonathan D. Beezley, and Adam K. Kochanski, [http://www.geosci-model-dev.net/4/591/2011/gmd-4-591-2011.html '''Coupled atmosphere-wildland fire modeling with WRF 3.3 and SFIRE 2011'''], [http://www.geoscientific-model-development.net Geoscientific Model Development (GMD)] 4, 591-610, 2011. {{doi|10.5194/gmd-4-591-2011}}

* Jan Mandel, Jonathan D. Beezley, Janice L. Coen, and Minjeong Kim, '''Data Assimilation for Wildland Fires: Ensemble Kalman filters in coupled atmosphere-surface models''', IEEE Control Systems Magazine 29, Issue 3, June 2009, 47-65. {{doi|10.1109/MCS.2009.932224}}. Preprint available as {{arXiv|0712.3965}}.

* Coen, J., M. Cameron, J. Michalakes, E. Patton, P. Riggan, and K. Yedinak, 2013: WRF-Fire: '''Coupled Weather-Wildland Fire Modeling with the Weather Research and Forecasting Model'''. J. Appl. Meteor. Climatol. 52, 16-38, {{doi|10.1175/JAMC-D-12-023.1}}.

===Conference papers===
* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Martin Vejmelka, Forecasting of smoke and wildfire emissions using WRF-Sfire, Numerical Wildfires, Cargese, Corsica, 17th May 2013. [http://www.openwfm.org/wiki/File:Corsica_Numerical_Wildfires_2013_4Web.pdf presentation]
* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Craig B. Clements, '''Air pollution forecasting by coupled atmosphere-fire model WRF and SFIRE with WRF-Chem''', [http://www.iawfonline.org/2013FuelsConference/index.php 4th Fire Behavior and Fuels Conference Raleigh, North Carolina, USA February 18 - 22, 2013], [http://www.openwfm.org/wiki/File:WRF-Chemcouplingabstract.pdf abstract] [http://www.openwfm.org/wiki/File:FAFB_conference_2013_final.pdf presentation] {{arXiv|1304.7703}}

* Martin Vejmelka, Adam K. Kochanski, and Jan Mandel, [http://math.ucdenver.edu/~jmandel/papers/Vejmelka-2013-DAF.pdf '''Data assimilation of fuel moisture in WRF-SFIRE'''], [http://www.iawfonline.org/2013FuelsConference/index.php 4th Fire Behavior and Fuels Conference Raleigh, North Carolina, USA February 18 - 22, 2013]

*Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Craig B. Clements, [https://ams.confex.com/ams/93Annual/webprogram/Paper221879.html '''Wildland fire emission forecasting by coupled atmosphere-fire model WRF-SFIRE and WRF-Chem'''] [http://annual.ametsoc.org/2013 93rd AMS Annual Meeting, 6-10 January 2013, Austin, TX]

* Jonathan Beezley, Mavin Martin, Paul Rosen, Jan Mandel, Adam K. Kochanski, '''Data management and analysis with WRF and SFIRE''', IEEE Geoscience and Remote Sensing Symposium (IGARSS) 2012, 5274-5277, 2012 {{doi|10.1109/IGARSS.2012.6352419}} {{arXiv|1208.1061}} [http://www.igarss12.org/papers/ViewPapers_MS.asp?PaperNum=4033 abstract]

* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, and Minjeong Kim, '''WRF fire simulation coupled with a fuel moisture model and smoke transport by WRF-Chem''', [http://www.mmm.ucar.edu/events/2012_wrfusers/ 2012 WRF Users Workshop], [http://www.openwfm.org/wiki/File:WRF_workshop_2012_poster.pdf Poster 51] [http://www.mmm.ucar.edu/events/2012_wrfusers/abstracts/p51.htm abstract] [https://www.regonline.com/AttendeeDocuments/1077122/43365086/wrf2012.pdf paper] {{arXiv|1208.1059}}

* Jonathan D. Beezley, A. Kochanski, V. Y. Kondratenko, and J. Mandel, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192276.html '''Integrating high-resolution static data into WRF for real fire simulations'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* P. Mates, E. Santos, J. Freire and C. Silva. [http://www.springerlink.com/content/v1w10731107216t3/ '''CrowdLabs: Social Analysis and Visualization for the Sciences'''] In proceedings of the 23rd International Conference on Scientific and Statistical Database Management (SSDBM), LNCS 6809/2011, pp. 555-564, 2011.

* Jan Mandel, University of Colorado, Denver, CO; and J. D. Beezley, A. Kochanski, V. Y. Kondratenko, L. Zhang, E. Anderson, J. Daniels II, C. T. Silva, and C. Johnson, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192277.html '''A wildland fire modeling and visualization environment'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011 [[media:9fire_2011_jm.pdf|pdf]]

* Jonathan D. Beezley, '''Importing high-resolution datasets into Geogrid''', 12th Annual WRF User's Workshop, Boulder, CO, June 2011. [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Extended%20Abstracts%202011/P2_Beezley_ExtendedAbstract_11.pdf pdf] [http://www.openwfm.org/wiki/File:Wrf2011jb.pdf local copy] [http://www.openwfm.org/wiki/File:Wrf2011jb-Poster.pdf poster]

===Users' guides===

* Current: [[Coupled WRF and SFIRE model user's guide]] on [[Main_Page|this wiki]]

* For the [[Fire_code_in_WRF_release#WRF_3.3|earlier version]] included in WRF release: Wang, W., Bruyere, C., Duda, M., Dudhia, J., Gill, D., Lin, H.C., Michalakes, J., Rizvi, S., Zhang, X., Beezley, J.D., Coen, J.L., Mandel, J. '''[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/ARWUsersGuideV3.pdf ARW version 3 modeling system user’s guide]'''. Mesoscale & Miscroscale Meteorology Division, National Center for Atmospheric Research (July 2010, last updated January 2012)

==Other WRF-Fire publications, applications, case studies==

: ''These publications deal with various aspects related to WRF-Fire, or report on its use and specific simulations.''

===Journal papers===

* Colin C. Simpson, Jason J. Sharples, Jason P. Evans, and Matthew F. McCabe, '''Large eddy simulation of atypical wildland fire spread on leeward slopes''', International Journal of Wildland Fire '''22''', 599-614, 2013 {{doi|10.1071/WF12072}}

* Adam K. Kochanski, Mary Ann Jenkins, Steven K. Krueger, Jan Mandel, Jonathan D. Beezley, '''Real time simulation of 2007 Santa Ana fires''', Forest Ecology and Management '''15''', 136-149, 2013 {{doi|10.1016/j.foreco.2012.12.014}} {{arXiv|1202.3209}}

* Adam K. Kochanski, Mary Ann Jenkins, Jan Mandel, Jonathan D. Beezley, Craig B. Clements, Steven Krueger, [http://www.geosci-model-dev.net/6/1109/2013/gmd-6-1109-2013.html '''Evaluation of WRF-Sfire Performance with Field Observations from the FireFlux experiment'''], Geoscientific Model Development '''6''', 1109-1126, 2013 {{doi|10.5194/gmd-6-1109-2013}}

===Theses===

* Nina Dobrinkova, '''Information systems for simulating the behavior of forest and field fires''', PhD Thesis, Bulgarian Academy of Sciences, 2012

* Minjeong Kim, [http://www.ucdenver.edu/academics/colleges/CLAS/Departments/math/students/alumni/Documents/Student%20Theses/Kim-Minjeong-PhdThesis.pdf '''Reaction diffusion equations and numerical wildland fire models'''], PhD thesis, University of Colorado Denver, 2011

* Jonathan D. Beezley, [http://www.ucdenver.edu/academics/colleges/CLAS/Departments/math/students/alumni/Documents/Student%20Theses/Beezley_PhDThesis.pdf '''High-Dimensional Data Assimilation and Morphing Ensemble Kalman Filters with Applications in Wildfire Modeling'''], PhD thesis, University of Colorado Denver, 2009

=== Conference papers ===
* Nina Dobrinkova, Stefka Fidanova, Ivan Dimov, Krasimir Atanasov, and Jan Mandel, '''Game-Method Model And WRF-Fire Model Working Together''', in Monte Carlo Methods and Applications, A. Sabelfeld and I. Dimov, eds., De Gruyter, Berlin, 2012, pp. 79--86, {{doi|10.1515/9783110293586.79}}

* Jan Mandel, J.D. Beezley, A. K. Kochanski, V. Y. Kondratenko, and M. Kim, '''Assimilation of Perimeter Data and Coupling with Fuel Moisture in a Wildland Fire - Atmosphere DDDAS''', ICCS 2012, [http://dx.doi.org/10.1016/j.procs.2012.04.119 Procedia Computer Science 9, 2012, 1100-1109] {{doi|10.1016/j.procs.2012.04.119}}

* Mary Ann Jenkins, A. K. Kochanski and S. K. Krueger, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192313.html '''The fluid dynamics of steady-state fireline propagation'''], [http://ams.confex.com/ams/9FIRE/webprogram/9FIRE.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* Mika Peace, T. Mattner and G. Mills, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192200.html '''The Kangaroo Island bushfires of 2007 A meteorological case study and WRF-fire simulation'''], [http://ams.confex.com/ams/9FIRE/webprogram/9FIRE.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011 (Adelaide University/Bureau of Meteorology, Adelaide, SA, Australia)

* Adam Kochanski, M. A. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, and C. B. Clements, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192314.html '''Coupled atmosphere-fire simulations of the FireFlux experiment: Impacts of model resolution on its performance'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* Georgi Jordanov, Jonathan D. Beezley, Nina Dobrinkova, Adam K. Kochanski, Jan Mandel, Bedr(ich Sousedík, '''Simulation of the 2009 Harmanli fire (Bulgaria)''', [http://dx.doi.org/10.1007/978-3-642-29843-1_33 Lecture Notes in Computer Science 7116, 291-298, 2012] [http://parallel.bas.bg/Conferences/SciCom11.html 8th International Conference on Large-Scale Scientific Computations], June 6-10, 2011, Sozopol, Bulgaria. {{arXiv|1106.4736}}

* Kondratenko, Volodymyr Y., Jonathan D. Beezley, Adam K. Kochanski, and Jan Mandel, '''Ignition from a Fire Perimeter in a WRF Wildland Fire Model''', 12th Annual WRF User's Workshop, Boulder, CO, June 2011. [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Extended%20Abstracts%202011/9_6_Kondratenko_ExtendedAbstract_11.pdf pdf] {{arXiv|1107.2675}} [http://www.openwfm.org/wiki/File:Wrf2011_VK-slides.pdf presentation]

* Jan Mandel, Jonathan Beezley, and Adam Kochanski, [http://ams.confex.com/ams/91Annual/webprogram/Paper185887.html '''An overview of the coupled atmosphere-wildland fire model WRF-Fire'''], [http://ams.confex.com/ams/91Annual/webprogram/start.html 91st American Meteorological Society Annual Meeting], Seattle, WA, January 25, 2011.

* Nina Dobrinkova, Georgi Jordanov, and Jan Mandel, '''WRF-Fire Applied in Bulgaria''', Numerical Methods and Applications, I. Dimov, S. Dimova, and N. Kolkovska, eds., Lecture Notes in Computer Science 6046, Springer, Berlin/Heidelberg, 2011, pp. 133-140. Proceedings of 7th International Conference on Numerical Methods and Applications - NM&A'10, August 20 - 24, 2010, Borovets, Bulgaria. {{doi|10.1007/978-3-642-18466-6_15}}. Preprint {{arXiv|1007.5347}}, July 2010.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

*Jan Mandel, Jonathan D. Beezley, and Volodymyr Y. Kondratenko, '''Fast Fourier Transform Ensemble Kalman Filter with Application to a Coupled Atmosphere-Wildland Fire Model'''. Anna M. Gil-Lafuente, Jose M. Merigo (Eds.) [http://www.worldscibooks.com/compsci/7925.html Computational Intelligence in Business and Economics] (Proceedings of the [http://www.amse-modeling.com/ms10/ MS'10 International Conference], Barcelona, Spain, 15-17 July 2010), World Scientific, pp. 777-784. {{doi|10.1142/9789814324441_0089}}. Preprint available at {{arXiv|1001.1588}}.

===Posters===
* Volodymyr Y. Kondratenko, J. D. Beezley, J. Mandel, and A. Kochanski, [https://ams.confex.com/ams/93Annual/webprogram/Paper221752.html Assimilation of fire perimeter data into the fire spread model SFIRE coupled with the WRF model], 93 AMS Annual Meeting, Austin, TX, January 5-10, 2013

* Adam K. Kochanski, S. K. Krueger , M. A. Jenkins, J. Mandel and J. D. Beezley, '''Real time simulation of 2007 Santa Ana fires''', [http://www.megafirereality.com/ Exploring the Mega-fire Reality] 2011.

* M. Jenkins, A. Kochanski, S. K. Krueger, W. Mell, R. McDermott, [http://adsabs.harvard.edu/abs/2010AGUFMNH34A..08J '''The Fluid Dynamical Forces Involved in Grass Fire Propagation'''], AGU Fall Meeting, 2010 [[media:AGU.2010.poster.jenkins.etal.pdf|pdf]]

* J. D. Beezley, A. Kochanski, V. Y. Kondratenko, J. Mandel, B. Sousedik, [[media:agu10_jb.pdf|'''Simulation of the Meadow Creek fire using WRF-Fire''']], AGU Fall Meeting, 2010

* Jan Mandel, Jonathan D. Beezley, Adam K. Kochanski, Volodymyr Y. Kondratenko, Bedrich Sousedik, Erik Anderson, and Joel Daniels, [[media:agu10_jm.pdf|'''Wildland fire simulation by WRF-Fire''']], AGU Fall Meeting, 2010

* Kara Yedinak, Brian Lamb, Janice Coen, '''[http://adsabs.harvard.edu/abs/2009AGUFM.A43C0246Y Sensitivity Analysis and Application of WRF-Fire]''', AGU Fall Meeting, 2009.

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analyses of Ignition Area and Fire-Atmosphere Dynamics using WRF-FIRE''', 8th Symposium on Fire & Forest Meteorology, American Meteorological Society, Kalispell. Oct 13-15, 2009.

* Kara Yedinak, J. L. Coen, and B. Lamb, '''WRF-Fire: A fire-atmosphere dynamics module for air quality modeling''', [http://ams.confex.com/ams/89annual/techprogram/MEETING.HTM The 89th American Meteorological Society Annual Meeting (Phoenix, AZ)], [http://ams.confex.com/ams/89annual/techprogram/program_532.htm 11th Conference on Atmospheric Chemistry], [http://ams.confex.com/ams/89annual/techprogram/paper_150173.htm Poster JP 1.10], January 2009.

=== Presentations ===

* Colin Simpson, Andrew Sturman and Peyman Zawar- Reza [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Power%20Points%202011/9_5_Simpson_WRFWorkshop_11.pdf '''Numerical Modeling of Wildland Fire Behaviour under Foehn Winds in New Zealand'''], [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/WorkshopPapers.php 12th Annual WRF Users' Workshop], 2011 (University of Canterbury, New Zealand)
* Simpson, C.; Sturman, A.; Zawar-Reza, P., [http://adsabs.harvard.edu/abs/2010AGUFMNH34A..07S '''Numerical Modelling of Fire-Atmosphere Interactions and the 2003 Canberra Bushfires'''], American Geophysical Union, Fall Meeting 2010, abstract #NH34A-07, 2010
* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Evaluation of The Fire Plume Dynamics Simulated by WRF-Fire''', AGU Fall Meeting, 2010 [[media:AGU.2010.kochanski.key.pdf|pdf]] [[media:AGU.2010.kochanski.key.gz|key]]
* J. Mandel, [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/abstracts.html#10318 '''Coupled atmosphere-wildland fire simulation by WRF-Fire'''], Invited lecture at [http://www.ima.umn.edu/ IMA] Workshop [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/ Numerical Solutions of Partial Differential Equations: Fast Solution Techniques], December 2, 2010. [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/activities/Mandel-Jan/ima10.key.pdf pdf] {{daseminar|slides/ima10/ima10.key.zip|key}} [http://www.ima.umn.edu/videos/?id=1507 video]
* Janice Coen, '''Computational Modeling of Wildland Fire Behavior and Weather for Research and Forecasting''', keynote lecture at ICCS 2009 [http://www.science.uva.nl/sites/iccs-meeting/iccs2009/abs-Coen.html abstract]

==Other publications from this project==

: ''Here are publications and presentations, not dealing directly with the WRF-Fire code.''

* N. Andrysco, P. Rosen, V. Popescu, B. Benes, and K.R. Gurney. [http://www.springerlink.com/content/j80q8736t460p785/ '''Experiences in disseminating educational visualizations''']. In Lecture Notes in Computer Science (7th International Symposium on Visual Computing), volume 2, pages 239–248, September 2011.

* Jonathan D. Beezley, Jan Mandel, and Loren Cobb, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6072819 '''Wavelet Ensemble Kalman Filters'''], Proceedings of the 6th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS'2011), Prague, September 15-17, 2011, 514-518, 2011

* A.N.M.I. Choudhury, B. Wang, P. Rosen, V. Pascucci. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6183557 '''Topological analysis and visualization of cyclical behavior in memory reference traces''']. IEEE Pacific Visualization Symposium (PacificVis), pp. 9-16, 2012.

* A.N.M. I. Choudhury and P. Rosen. '''Cache ensemble analysis for understanding algorithmic memory performance'''. In submission to IEEE Computer, 2012.

* A.N.M. Imroz Choudhury and P. Rosen. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6069452 '''Abstract visualization of runtime memory behavior''']. In 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2011), pages 22–29, 2011.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

* Jan Mandel and Jonathan D. Beezley, [http://dx.doi.org/10.1007/978-3-642-01973-9_53 '''An Ensemble Kalman-Particle Predictor-Corrector Filter for Non-Gaussian Data Assimilation'''], Proceedings ICCS 2009, Lecture Notes in Computer Science 5545, Springer, 2009, pp. 470-478. Also available at {{arXiv|0812.2290}}.

* Janice Coen, '''Some new basics of fire behavior''', Fire Management Today, In Press. [http://www.mmm.ucar.edu/people/coen/files/Coen_FMT_complete.pdf pdf]

* Janice Coen, 2010: '''Dry lightning'''. Southern California Fire Journal, Spring 2010, 18-23.

* Zhen Wang, Janice Coen, Anthony Vodacek, 2009, [http://www.mmm.ucar.edu/people/coen/files/Wang_18_302-309.pdf '''Generation of synthetic infrared remote sensing scenes of wildland fire''']. Intl. J. Wildland Fire, 18, 302-319.

* Craig J. Johns and Jan Mandel, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/cjjm-fires-revised.pdf '''A two-stage Ensemble Kalman Filter for Smooth Data Assimilation'''], Environmental and Ecological Statistics 15, 101-110, 2008

* Janice Coen, 2008: Deadly fingers of flame. Southern California Fire Journal. 1(1):5-6.

* Jonathan D. Beezley and Jan Mandel, '''Morphing Ensemble Kalman Filters''', Tellus 60A, 131-140, 2008 [http://arxiv.org/abs/0705.3693 arXiv:0705.3693]

* Jan Mandel, Lynn S. Bennethum, Jonathan D. Beezley, Janice L. Coen, Craig C. Douglas, Minjeong Kim, and Anthony Vodacek, [http://www-math.cudenver.edu/ccm/reports/rep233.pdf '''A wildland fire model with data assimilation'''], Mathematics and Computers in Simulation 79, 584-606, 2008, [http://dx.doi.org/10.1016/j.matcom.2008.03.015 article], [http://math.ucdenver.edu/%7Ejmandel/papers/rep233.pdf CCM Report 233 June 2006 revised January 2008]

* K. Potter, R.M. Kirby, D. Xiu, C.R. Johnson. [http://www.dl.begellhouse.com/journals/52034eb04b657aea,43e225911b944538,47df428f4bae4afa.html'''Interactive visualization of probability and cumulative density functions,'''] In International Journal of Uncertainty Quantification, pp. (to appear). 2012.

* K. Potter, P. Rosen, C. Johnson, [http://www.springerlink.com/content/l2307671664n2237/ '''From Quantification to Visualization: A Taxonomy of Uncertainty Visualization Approaches''']. IFIP Advances in Information and Communication Technology, vol. 377, pp. 226-249, 2012.

* Paul Rosen. [http://dl.acm.org/citation.cfm?id=2159641 '''Rectilinear texture warping for fast adaptive shadow mapping''']. In Proceedings of the ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D '12), pp. 151-158, 2012.

* P. Rosen and V. Popescu. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6060816 '''Simplification of node position data for interactive visualization of dynamic datasets''']. IEEE Transactions on Visualization and Computer Graphics, pp. 1537-1548, 2012.

* P. Rosen, V. Popescu, K. Hayward, and C. Wyman. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5733331 '''Non-pinhole approximations for interactive rendering''']. IEEE Computer Graphics and Applications, 31(6), November/December 2011.

* E. Santos, Lins, L Ahrens, J.P., Freire, J, and Silva, C. T., [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5290771 '''VisMashup: Streamlining the Creation of Custom Visualization Applications'''], IEEE Transactions on Visualizatiuon and Computer Graphics 15 (6) 1539-1546, 2009

* P.C. Wong, H.-W. Shen, C.R. Johnson, C. Chen, R.B. Ross. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6265057 '''The Top 10 Challenges in Extreme-Scale Visual Analytics,'''] In IEEE Computer Graphics and Applications, Visualization Viewpoints, Edited by Theresa-Marie Rhyne, pp. 63--67. July-August, 2012.

* C. Yang, I. Jensen, P. Rosen. '''A Multiscale Approach to Network Event Identification using Geolocated Twitter Data'''. In submission to IMC Workshop on Internet Visualization, 2012.

==Earlier publications (before 2008)==

: ''Here are some related publications and presentations from our previous work.''

* Janice Coen, [http://www.cise.nsf.gov/cns/darema/dd_das/coen/ '''Coupled Atmosphere-Wildfire Modeling'''], NSF Workshop, April 25, 2000

* Jan Mandel [http://math.ucdenver.edu/%7Ejmandel/papers/rep231.pdf '''Efficient Implementation of the Ensemble Kalman Filter'''], CCM Report 231, May 2006.

* Jan Mandel and Jonathan D. Beezley, [http://math.ucdenver.edu/~jmandel/papers/ametsoc07.pdf '''Predictor-Corrector and Morphing Ensemble Filters for the Assimilation of Sparse Data into High-Dimensional Nonlinear Systems'''], 11th Symposium on Integrated Observing and Assimilation Systems for the Atmosphere, Oceans, and Land Surface (IOAS-AOLS), CD-ROM, [http://ams.confex.com/ams/87ANNUAL/techprogram/paper_119633.htm Paper 4.12], 87th American Meterological Society Annual Meeting, San Antonio, TX, January 2007 [http://math.ucdenver.edu/~jmandel/slides/ametsoc07-jm.pdf presentation], [http://www-math.cudenver.edu/ccm/reports/rep239.pdf CCM Report 239, November 2006]

* Jan Mandel, Jonathan D. Beezley, Lynn S. Bennethum, Soham Chakraborty, Janice L. Coen, Craig C. Douglas, Jay Hatcher, Minjeong Kim, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-paper.pdf '''A Dynamic Data Driven Wildland Fire Model'''], ICCS 2007, Part I, Yong Shi, G. D. van Albada, P. M. A. Sloot and J. J. Dongarra (Eds), Lecture Notes in Computer Science 4487, 1042--1049, Springer, 2007. [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-slides.pdf Presentation]

* Jan Mandel, Lynn S. Bennethum, Mingshi Chen, Janice L. Coen, Craig C. Douglas, Leopoldo P. Franca, Craig J. Johns, Minjeong Kim, Andrew V. Knyazev, Robert Kremens, Vaibhav Kulkarni, Guan Qin, Anthony Vodacek, Jianjia Wu, Wei Zhao, and Adam Zornes, [http://math.ucdenver.edu/~jmandel/papers/fires-iccs05.pdf '''Towards a Dynamic Data Driven Application System for Wildfire Simulation'''] V.S. Sunderam et al. (Eds.): Computational Science - Proceedings ICCS'2005, Lecture Notes in Computer Science 3515, pp. 632-639, 2005.

* Craig C. Douglas, Jonathan D. Beezley, Janice Coen, Deng Li, Wei Li, Alan K. Mandel, Jan Mandel, Guan Qin, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/wf-demo.pdf '''Demonstrating the Validity of Wildfire DDDAS'''], Computational Science - ICCS 2006: 6th International Conference, Reading, UK, May 28-31, 2006, Proceedings, Part III, Vassil N. Alexandrov, Dick van Albada, Dick Geert and Peter M. A. Sloot and Jack Dongarra (Eds.), Lecture Notes in Computer Science 3993, Springer 2006, pp. 522-529.

* J. Mandel, M. Chen, L.P. Franca, C. Johns, A. Puhalskii, J.L. Coen, C.C. Douglas, R. Kremens, A. Vodacek, W. Zhao, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/fires_krakow.pdf '''A Note on Dynamic Data Driven Wildfire Modeling'''], Computational Science - Proceedings ICCS'2004, vol. III, edited by Marian Bubak, G.Dick van Albada, Peter M.A. Sloot, Jack J. Dongarra, Lecture Notes in Computer Science 3038, Springer, pp. 725-731. Copyright Springer 2004. [http://dx.doi.org/10.1007/b97989 book], [http://math.ucdenver.edu/%7Ejmandel/papers/fires_krakow.pdf PDF 150K]

* Edward G. Patton and Janice L. Coen, [http://www.mmm.ucar.edu/mm5/workshop/ws04/Session9/Patton_Edward.pdf WRF-Fire: A Coupled Atmosphere-Fire Module for WRF], Preprints of Joint MM5/Weather Research and Forecasting Model Users' Workshop, Boulder, CO, June 22-25, 2004, pp. 221-223, NCAR.

==See also==
* {{ccm|Spatial_epidemiology_project#Publications|Spatial epidemiology publications}}
* {{ccm|Data_assimilation_seminar_publications|Data assimilation seminar publications}}
[[Category:WRF-Fire|Publications]]
[[Category:Contents]]

File:Corscia Numerical Wildfires 2013 4Web.pdf

2013-09-09T18:14:40Z

Adamko: Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Martin Vejmelka, Forecasting of smoke and wildfire emissions using WRF-Sfire, Numerical Wildfires, Cargese, Corsica, 17th May 2013.

Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Martin Vejmelka, Forecasting of smoke and wildfire emissions using WRF-Sfire, Numerical Wildfires, Cargese, Corsica, 17th May 2013.

Publications

2013-03-15T17:42:14Z

Adamko: /* Conference papers */

{{users guide}}

==WRF-Fire description==

: ''The [[WRF-Fire]] code is described in these papers.''

===Journal papers===

* Jan Mandel, Jonathan D. Beezley, and Adam K. Kochanski, [http://www.geosci-model-dev.net/4/591/2011/gmd-4-591-2011.html '''Coupled atmosphere-wildland fire modeling with WRF 3.3 and SFIRE 2011'''], [http://www.geoscientific-model-development.net Geoscientific Model Development (GMD)] 4, 591-610, 2011. {{doi|10.5194/gmd-4-591-2011}}

* Jan Mandel, Jonathan D. Beezley, Janice L. Coen, and Minjeong Kim, '''Data Assimilation for Wildland Fires: Ensemble Kalman filters in coupled atmosphere-surface models''', IEEE Control Systems Magazine 29, Issue 3, June 2009, 47-65. {{doi|10.1109/MCS.2009.932224}}. Preprint available as {{arXiv|0712.3965}}.

* Coen, J., M. Cameron, J. Michalakes, E. Patton, P. Riggan, and K. Yedinak, 2012: WRF-Fire: '''Coupled Weather-Wildland Fire Modeling with the Weather Research and Forecasting Model'''. J. Appl. Meteor. Climatol. {{doi|10.1175/JAMC-D-12-023.1}}, in press.

===Conference papers===
*Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Craig B. Clements,"'''Air pollution forecasting by coupled atmosphere-fire model WRF and SFIRE with WRF-Chem'''", [http://www.iawfonline.org/2013FuelsConference/index.php 4th Fire Behavior and Fuels Conference Raleigh, North Carolina, USA February 18 - 22, 2013], [http://www.openwfm.org/wiki/File:WRF-Chemcouplingabstract.pdf abstract] [http://www.openwfm.org/wiki/File:FAFB_conference_2013_final.pdf presentation]

*Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, Craig B. Clements, [https://ams.confex.com/ams/93Annual/webprogram/Paper221879.html '"'''Wildland fire emission forecasting by coupled atmosphere-fire model WRF-SFIRE and WRF-Chem'''"'] [http://annual.ametsoc.org/2013 93rd AMS Annual Meeting, 6-10 January 2013, Austin, TX]

* Jonathan Beezley, Mavin Martin, Paul Rosen, Jan Mandel, Adam K. Kochanski, '''Data management and analysis with WRF and SFIRE''', Geoscience and Remote Sensing Symposium (IGARSS) 2012, 5274-5277, 2012 {{doi|10.1109/IGARSS.2012.6352419}} {{arXiv|1208.1061}} [http://www.igarss12.org/papers/ViewPapers_MS.asp?PaperNum=4033 abstract]

* Adam K. Kochanski, Jonathan D. Beezley, Jan Mandel, and Minjeong Kim, '''WRF fire simulation coupled with a fuel moisture model and smoke transport by WRF-Chem''', [http://www.mmm.ucar.edu/events/2012_wrfusers/ 2012 WRF Users Workshop], [http://www.openwfm.org/wiki/File:WRF_workshop_2012_poster.pdf Poster 51] [http://www.mmm.ucar.edu/events/2012_wrfusers/abstracts/p51.htm abstract] [https://www.regonline.com/AttendeeDocuments/1077122/43365086/wrf2012.pdf paper] {{arXiv|1208.1059}}

* Jonathan D. Beezley, A. Kochanski, V. Y. Kondratenko, and J. Mandel, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192276.html '''Integrating high-resolution static data into WRF for real fire simulations'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* P. Mates, E. Santos, J. Freire and C. Silva. [http://www.springerlink.com/content/v1w10731107216t3/ '''CrowdLabs: Social Analysis and Visualization for the Sciences'''] In proceedings of the 23rd International Conference on Scientific and Statistical Database Management (SSDBM), LNCS 6809/2011, pp. 555-564, 2011.

* Jan Mandel, University of Colorado, Denver, CO; and J. D. Beezley, A. Kochanski, V. Y. Kondratenko, L. Zhang, E. Anderson, J. Daniels II, C. T. Silva, and C. Johnson, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192277.html '''A wildland fire modeling and visualization environment'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011 [[media:9fire_2011_jm.pdf|pdf]]

* Jonathan D. Beezley, '''Importing high-resolution datasets into Geogrid''', 12th Annual WRF User's Workshop, Boulder, CO, June 2011. [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Extended%20Abstracts%202011/P2_Beezley_ExtendedAbstract_11.pdf pdf] [http://www.openwfm.org/wiki/File:Wrf2011jb.pdf local copy] [http://www.openwfm.org/wiki/File:Wrf2011jb-Poster.pdf poster]

===Users' guides===

* Current: [[Coupled WRF and SFIRE model user's guide]] on [[Main_Page|this wiki]]

* For the [[Fire_code_in_WRF_release#WRF_3.3|earlier version]] included in WRF release: Wang, W., Bruyere, C., Duda, M., Dudhia, J., Gill, D., Lin, H.C., Michalakes, J., Rizvi, S., Zhang, X., Beezley, J.D., Coen, J.L., Mandel, J. '''[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/ARWUsersGuideV3.pdf ARW version 3 modeling system user’s guide]'''. Mesoscale & Miscroscale Meteorology Division, National Center for Atmospheric Research (July 2010, last updated January 2012)

==Other WRF-Fire publications, applications, case studies==

: ''These publications deal with various aspects related to WRF-Fire, or report on its use and specific simulations.''

===Journal papers===

* Adam K. Kochanski, Mary Ann Jenkins, Steven K. Krueger, Jan Mandel, Jonathan D. Beezley, '''Real time simulation of 2007 Santa Ana fires''', Forest Ecology and Management, in print. {{arXiv|1202.3209}}, 2012

* Adam K. Kochanski, Mary Ann Jenkins, Jan Mandel, Jonathan D. Beezley, Craig B. Clements, Steven Krueger, [http://www.geosci-model-dev-discuss.net/6/121/2013/gmdd-6-121-2013.html '''Evaluation of WRF-Sfire Performance with Field Observations from the FireFlux experiment'''], Geosci. Model Dev. Discuss., 6, 121-169, 2013 {{doi|10.5194/gmdd-6-121-2013}} {{arXiv|1206.3345}}

===Theses===

* Nina Dobrinkova, '''Information systems for simulating the behavior of forest and field fires''', PhD Thesis, Bulgarian Academy of Sciences, 2012

* Minjeong Kim, [http://www.ucdenver.edu/academics/colleges/CLAS/Departments/math/students/alumni/Documents/Student%20Theses/Kim-Minjeong-PhdThesis.pdf '''Reaction diffusion equations and numerical wildland fire models'''], PhD thesis, University of Colorado Denver, 2011

* Jonathan D. Beezley, [http://www.ucdenver.edu/academics/colleges/CLAS/Departments/math/students/alumni/Documents/Student%20Theses/Beezley_PhDThesis.pdf '''High-Dimensional Data Assimilation and Morphing Ensemble Kalman Filters with Applications in Wildfire Modeling'''], PhD thesis, University of Colorado Denver, 2009

=== Conference papers ===
* Nina Dobrinkova, Stefka Fidanova, Ivan Dimov, Krasimir Atanasov, and Jan Mandel, '''Game-Method Model And WRF-Fire Model Working Together''', in Monte Carlo Methods and Applications, A. Sabelfeld and I. Dimov, eds., De Gruyter, Berlin, in print.

* Jan Mandel, J.D. Beezley, A. K. Kochanski, V. Y. Kondratenko, and M. Kim, '''Assimilation of Perimeter Data and Coupling with Fuel Moisture in a Wildland Fire - Atmosphere DDDAS''', ICCS 2012, [http://dx.doi.org/10.1016/j.procs.2012.04.119 Procedia Computer Science 9, 2012, 1100-1109]

* Mary Ann Jenkins, A. K. Kochanski and S. K. Krueger, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192313.html '''The fluid dynamics of steady-state fireline propagation'''], [http://ams.confex.com/ams/9FIRE/webprogram/9FIRE.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* Mika Peace, T. Mattner and G. Mills, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192200.html '''The Kangaroo Island bushfires of 2007 A meteorological case study and WRF-fire simulation'''], [http://ams.confex.com/ams/9FIRE/webprogram/9FIRE.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011 (Adelaide University/Bureau of Meteorology, Adelaide, SA, Australia)

* Adam Kochanski, M. A. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, and C. B. Clements, [http://ams.confex.com/ams/9FIRE/webprogram/Paper192314.html '''Coupled atmosphere-fire simulations of the FireFlux experiment: Impacts of model resolution on its performance'''], [http://www.ametsoc.org/meet/fainst/20119fireforest.html Ninth Symposium on Fire and Forest Meteorology], Palm Springs, CA, October 18-20, 2011

* Georgi Jordanov, Jonathan D. Beezley, Nina Dobrinkova, Adam K. Kochanski, Jan Mandel, Bedr(ich Sousedík, '''Simulation of the 2009 Harmanli fire (Bulgaria)''', [http://dx.doi.org/10.1007/978-3-642-29843-1_33 Lecture Notes in Computer Science 7116, 291-298, 2012] [http://parallel.bas.bg/Conferences/SciCom11.html 8th International Conference on Large-Scale Scientific Computations], June 6-10, 2011, Sozopol, Bulgaria. {{arXiv|1106.4736}}

* Kondratenko, Volodymyr Y., Jonathan D. Beezley, Adam K. Kochanski, and Jan Mandel, '''Ignition from a Fire Perimeter in a WRF Wildland Fire Model''', 12th Annual WRF User's Workshop, Boulder, CO, June 2011. [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Extended%20Abstracts%202011/9_6_Kondratenko_ExtendedAbstract_11.pdf pdf] {{arXiv|1107.2675}} [http://www.openwfm.org/wiki/File:Wrf2011_VK-slides.pdf presentation]

* Jan Mandel, Jonathan Beezley, and Adam Kochanski, [http://ams.confex.com/ams/91Annual/webprogram/Paper185887.html '''An overview of the coupled atmosphere-wildland fire model WRF-Fire'''], [http://ams.confex.com/ams/91Annual/webprogram/start.html 91st American Meteorological Society Annual Meeting], Seattle, WA, January 25, 2011.

* Nina Dobrinkova, Georgi Jordanov, and Jan Mandel, '''WRF-Fire Applied in Bulgaria''', Numerical Methods and Applications, I. Dimov, S. Dimova, and N. Kolkovska, eds., Lecture Notes in Computer Science 6046, Springer, Berlin/Heidelberg, 2011, pp. 133-140. Proceedings of 7th International Conference on Numerical Methods and Applications - NM&A'10, August 20 - 24, 2010, Borovets, Bulgaria. {{doi|10.1007/978-3-642-18466-6_15}}. Preprint {{arXiv|1007.5347}}, July 2010.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

*Jan Mandel, Jonathan D. Beezley, and Volodymyr Y. Kondratenko, '''Fast Fourier Transform Ensemble Kalman Filter with Application to a Coupled Atmosphere-Wildland Fire Model'''. Anna M. Gil-Lafuente, Jose M. Merigo (Eds.) [http://www.worldscibooks.com/compsci/7925.html Computational Intelligence in Business and Economics] (Proceedings of the [http://www.amse-modeling.com/ms10/ MS'10 International Conference], Barcelona, Spain, 15-17 July 2010), World Scientific, pp. 777-784. {{doi|10.1142/9789814324441_0089}}. Preprint available at {{arXiv|1001.1588}}.

===Posters===

* Adam K. Kochanski, S. K. Krueger , M. A. Jenkins, J. Mandel and J. D. Beezley, '''Real time simulation of 2007 Santa Ana fires''', [http://www.megafirereality.com/ Exploring the Mega-fire Reality] 2011.

* M. Jenkins, A. Kochanski, S. K. Krueger, W. Mell, R. McDermott, [http://adsabs.harvard.edu/abs/2010AGUFMNH34A..08J '''The Fluid Dynamical Forces Involved in Grass Fire Propagation'''], AGU Fall Meeting, 2010 [[media:AGU.2010.poster.jenkins.etal.pdf|pdf]]

* J. D. Beezley, A. Kochanski, V. Y. Kondratenko, J. Mandel, B. Sousedik, [[media:agu10_jb.pdf|'''Simulation of the Meadow Creek fire using WRF-Fire''']], AGU Fall Meeting, 2010

* Jan Mandel, Jonathan D. Beezley, Adam K. Kochanski, Volodymyr Y. Kondratenko, Bedrich Sousedik, Erik Anderson, and Joel Daniels, [[media:agu10_jm.pdf|'''Wildland fire simulation by WRF-Fire''']], AGU Fall Meeting, 2010

* Kara Yedinak, Brian Lamb, Janice Coen, '''[http://adsabs.harvard.edu/abs/2009AGUFM.A43C0246Y Sensitivity Analysis and Application of WRF-Fire]''', AGU Fall Meeting, 2009.

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analyses of Ignition Area and Fire-Atmosphere Dynamics using WRF-FIRE''', 8th Symposium on Fire & Forest Meteorology, American Meteorological Society, Kalispell. Oct 13-15, 2009.

* Kara Yedinak, J. L. Coen, and B. Lamb, '''WRF-Fire: A fire-atmosphere dynamics module for air quality modeling''', [http://ams.confex.com/ams/89annual/techprogram/MEETING.HTM The 89th American Meteorological Society Annual Meeting (Phoenix, AZ)], [http://ams.confex.com/ams/89annual/techprogram/program_532.htm 11th Conference on Atmospheric Chemistry], [http://ams.confex.com/ams/89annual/techprogram/paper_150173.htm Poster JP 1.10], January 2009.

=== Presentations ===

* Colin Simpson, Andrew Sturman and Peyman Zawar- Reza [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/Power%20Points%202011/9_5_Simpson_WRFWorkshop_11.pdf '''Numerical Modeling of Wildland Fire Behaviour under Foehn Winds in New Zealand'''], [http://www.mmm.ucar.edu/wrf/users/workshops/WS2011/WorkshopPapers.php 12th Annual WRF Users' Workshop], 2011 (University of Canterbury, New Zealand)
* Simpson, C.; Sturman, A.; Zawar-Reza, P., [http://adsabs.harvard.edu/abs/2010AGUFMNH34A..07S '''Numerical Modelling of Fire-Atmosphere Interactions and the 2003 Canberra Bushfires'''], American Geophysical Union, Fall Meeting 2010, abstract #NH34A-07, 2010
* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Evaluation of The Fire Plume Dynamics Simulated by WRF-Fire''', AGU Fall Meeting, 2010 [[media:AGU.2010.kochanski.key.pdf|pdf]] [[media:AGU.2010.kochanski.key.gz|key]]
* J. Mandel, [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/abstracts.html#10318 '''Coupled atmosphere-wildland fire simulation by WRF-Fire'''], Invited lecture at [http://www.ima.umn.edu/ IMA] Workshop [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/ Numerical Solutions of Partial Differential Equations: Fast Solution Techniques], December 2, 2010. [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/activities/Mandel-Jan/ima10.key.pdf pdf] {{daseminar|slides/ima10/ima10.key.zip|key}} [http://www.ima.umn.edu/videos/?id=1507 video]
* Janice Coen, '''Computational Modeling of Wildland Fire Behavior and Weather for Research and Forecasting''', keynote lecture at ICCS 2009 [http://www.science.uva.nl/sites/iccs-meeting/iccs2009/abs-Coen.html abstract]

==Other publications from this project==

: ''Here are publications and presentations, not dealing directly with the WRF-Fire code.''

* N. Andrysco, P. Rosen, V. Popescu, B. Benes, and K.R. Gurney. [http://www.springerlink.com/content/j80q8736t460p785/ '''Experiences in disseminating educational visualizations''']. In Lecture Notes in Computer Science (7th International Symposium on Visual Computing), volume 2, pages 239–248, September 2011.

* Jonathan D. Beezley, Jan Mandel, and Loren Cobb, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6072819 '''Wavelet Ensemble Kalman Filters'''], Proceedings of the 6th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS'2011), Prague, September 15-17, 2011, 514-518, 2011

* A.N.M.I. Choudhury, B. Wang, P. Rosen, V. Pascucci. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6183557 '''Topological analysis and visualization of cyclical behavior in memory reference traces''']. IEEE Pacific Visualization Symposium (PacificVis), pp. 9-16, 2012.

* A.N.M. I. Choudhury and P. Rosen. '''Cache ensemble analysis for understanding algorithmic memory performance'''. In submission to IEEE Computer, 2012.

* A.N.M. Imroz Choudhury and P. Rosen. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6069452 '''Abstract visualization of runtime memory behavior''']. In 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2011), pages 22–29, 2011.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

* Jan Mandel and Jonathan D. Beezley, [http://dx.doi.org/10.1007/978-3-642-01973-9_53 '''An Ensemble Kalman-Particle Predictor-Corrector Filter for Non-Gaussian Data Assimilation'''], Proceedings ICCS 2009, Lecture Notes in Computer Science 5545, Springer, 2009, pp. 470-478. Also available at {{arXiv|0812.2290}}.

* Janice Coen, '''Some new basics of fire behavior''', Fire Management Today, In Press. [http://www.mmm.ucar.edu/people/coen/files/Coen_FMT_complete.pdf pdf]

* Janice Coen, 2010: '''Dry lightning'''. Southern California Fire Journal, Spring 2010, 18-23.

* Zhen Wang, Janice Coen, Anthony Vodacek, 2009, [http://www.mmm.ucar.edu/people/coen/files/Wang_18_302-309.pdf '''Generation of synthetic infrared remote sensing scenes of wildland fire''']. Intl. J. Wildland Fire, 18, 302-319.

* Craig J. Johns and Jan Mandel, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/cjjm-fires-revised.pdf '''A two-stage Ensemble Kalman Filter for Smooth Data Assimilation'''], Environmental and Ecological Statistics 15, 101-110, 2008

* Janice Coen, 2008: Deadly fingers of flame. Southern California Fire Journal. 1(1):5-6.

* Jonathan D. Beezley and Jan Mandel, '''Morphing Ensemble Kalman Filters''', Tellus 60A, 131-140, 2008 [http://arxiv.org/abs/0705.3693 arXiv:0705.3693]

* Jan Mandel, Lynn S. Bennethum, Jonathan D. Beezley, Janice L. Coen, Craig C. Douglas, Minjeong Kim, and Anthony Vodacek, [http://www-math.cudenver.edu/ccm/reports/rep233.pdf '''A wildland fire model with data assimilation'''], Mathematics and Computers in Simulation 79, 584-606, 2008, [http://dx.doi.org/10.1016/j.matcom.2008.03.015 article], [http://math.ucdenver.edu/%7Ejmandel/papers/rep233.pdf CCM Report 233 June 2006 revised January 2008]

* K. Potter, R.M. Kirby, D. Xiu, C.R. Johnson. [http://www.dl.begellhouse.com/journals/52034eb04b657aea,43e225911b944538,47df428f4bae4afa.html'''Interactive visualization of probability and cumulative density functions,'''] In International Journal of Uncertainty Quantification, pp. (to appear). 2012.

* K. Potter, P. Rosen, C. Johnson, [http://www.springerlink.com/content/l2307671664n2237/ '''From Quantification to Visualization: A Taxonomy of Uncertainty Visualization Approaches''']. IFIP Advances in Information and Communication Technology, vol. 377, pp. 226-249, 2012.

* Paul Rosen. [http://dl.acm.org/citation.cfm?id=2159641 '''Rectilinear texture warping for fast adaptive shadow mapping''']. In Proceedings of the ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D '12), pp. 151-158, 2012.

* P. Rosen and V. Popescu. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6060816 '''Simplification of node position data for interactive visualization of dynamic datasets''']. IEEE Transactions on Visualization and Computer Graphics, pp. 1537-1548, 2012.

* P. Rosen, V. Popescu, K. Hayward, and C. Wyman. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5733331 '''Non-pinhole approximations for interactive rendering''']. IEEE Computer Graphics and Applications, 31(6), November/December 2011.

* E. Santos, Lins, L Ahrens, J.P., Freire, J, and Silva, C. T., [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5290771 '''VisMashup: Streamlining the Creation of Custom Visualization Applications'''], IEEE Transactions on Visualizatiuon and Computer Graphics 15 (6) 1539-1546, 2009

* P.C. Wong, H.-W. Shen, C.R. Johnson, C. Chen, R.B. Ross. [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6265057 '''The Top 10 Challenges in Extreme-Scale Visual Analytics,'''] In IEEE Computer Graphics and Applications, Visualization Viewpoints, Edited by Theresa-Marie Rhyne, pp. 63--67. July-August, 2012.

* C. Yang, I. Jensen, P. Rosen. '''A Multiscale Approach to Network Event Identification using Geolocated Twitter Data'''. In submission to IMC Workshop on Internet Visualization, 2012.

==Earlier publications (before 2008)==

: ''Here are some related publications and presentations from our previous work.''

* Janice Coen, [http://www.cise.nsf.gov/cns/darema/dd_das/coen/ '''Coupled Atmosphere-Wildfire Modeling'''], NSF Workshop, April 25, 2000

* Jan Mandel [http://math.ucdenver.edu/%7Ejmandel/papers/rep231.pdf '''Efficient Implementation of the Ensemble Kalman Filter'''], CCM Report 231, May 2006.

* Jan Mandel and Jonathan D. Beezley, [http://math.ucdenver.edu/~jmandel/papers/ametsoc07.pdf '''Predictor-Corrector and Morphing Ensemble Filters for the Assimilation of Sparse Data into High-Dimensional Nonlinear Systems'''], 11th Symposium on Integrated Observing and Assimilation Systems for the Atmosphere, Oceans, and Land Surface (IOAS-AOLS), CD-ROM, [http://ams.confex.com/ams/87ANNUAL/techprogram/paper_119633.htm Paper 4.12], 87th American Meterological Society Annual Meeting, San Antonio, TX, January 2007 [http://math.ucdenver.edu/~jmandel/slides/ametsoc07-jm.pdf presentation], [http://www-math.cudenver.edu/ccm/reports/rep239.pdf CCM Report 239, November 2006]

* Jan Mandel, Jonathan D. Beezley, Lynn S. Bennethum, Soham Chakraborty, Janice L. Coen, Craig C. Douglas, Jay Hatcher, Minjeong Kim, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-paper.pdf '''A Dynamic Data Driven Wildland Fire Model'''], ICCS 2007, Part I, Yong Shi, G. D. van Albada, P. M. A. Sloot and J. J. Dongarra (Eds), Lecture Notes in Computer Science 4487, 1042--1049, Springer, 2007. [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-slides.pdf Presentation]

* Jan Mandel, Lynn S. Bennethum, Mingshi Chen, Janice L. Coen, Craig C. Douglas, Leopoldo P. Franca, Craig J. Johns, Minjeong Kim, Andrew V. Knyazev, Robert Kremens, Vaibhav Kulkarni, Guan Qin, Anthony Vodacek, Jianjia Wu, Wei Zhao, and Adam Zornes, [http://math.ucdenver.edu/~jmandel/papers/fires-iccs05.pdf '''Towards a Dynamic Data Driven Application System for Wildfire Simulation'''] V.S. Sunderam et al. (Eds.): Computational Science - Proceedings ICCS'2005, Lecture Notes in Computer Science 3515, pp. 632-639, 2005.

* Craig C. Douglas, Jonathan D. Beezley, Janice Coen, Deng Li, Wei Li, Alan K. Mandel, Jan Mandel, Guan Qin, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/wf-demo.pdf '''Demonstrating the Validity of Wildfire DDDAS'''], Computational Science - ICCS 2006: 6th International Conference, Reading, UK, May 28-31, 2006, Proceedings, Part III, Vassil N. Alexandrov, Dick van Albada, Dick Geert and Peter M. A. Sloot and Jack Dongarra (Eds.), Lecture Notes in Computer Science 3993, Springer 2006, pp. 522-529.

* J. Mandel, M. Chen, L.P. Franca, C. Johns, A. Puhalskii, J.L. Coen, C.C. Douglas, R. Kremens, A. Vodacek, W. Zhao, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/fires_krakow.pdf '''A Note on Dynamic Data Driven Wildfire Modeling'''], Computational Science - Proceedings ICCS'2004, vol. III, edited by Marian Bubak, G.Dick van Albada, Peter M.A. Sloot, Jack J. Dongarra, Lecture Notes in Computer Science 3038, Springer, pp. 725-731. Copyright Springer 2004. [http://dx.doi.org/10.1007/b97989 book], [http://math.ucdenver.edu/%7Ejmandel/papers/fires_krakow.pdf PDF 150K]

* Edward G. Patton and Janice L. Coen, [http://www.mmm.ucar.edu/mm5/workshop/ws04/Session9/Patton_Edward.pdf WRF-Fire: A Coupled Atmosphere-Fire Module for WRF], Preprints of Joint MM5/Weather Research and Forecasting Model Users' Workshop, Boulder, CO, June 22-25, 2004, pp. 221-223, NCAR.

==See also==
* {{ccm|Spatial_epidemiology_project#Publications|Spatial epidemiology publications}}
* {{ccm|Data_assimilation_seminar_publications|Data assimilation seminar publications}}
[[Category:WRF-Fire|Publications]]
[[Category:Contents]]

File:FAFB conference 2013 final.pdf

2013-03-15T17:40:32Z

Adamko: 4th Fire Behavior and Fuels Conference presentation.

4th Fire Behavior and Fuels Conference presentation.

File:WRF-Chemcouplingabstract.pdf

2013-03-15T17:25:53Z

Adamko: 4th Fire Behavior and Fuels Conference abstract: Air pollution forecasting by coupled atmosphere-fire model WRF and SFIRE with WRF-Chem

4th Fire Behavior and Fuels Conference abstract: Air pollution forecasting by coupled atmosphere-fire model WRF and SFIRE with WRF-Chem

Publications

2011-12-05T17:52:38Z

Adamko: /* Posters */

== Journal articles ==
* Jan Mandel, Jonathan D. Beezley, and Adam K. Kochanski, [http://www.geosci-model-dev-discuss.net/4/497/2011/gmdd-4-497-2011.html '''Coupled atmosphere-wildland fire modeling with WRF-Fire version 3.3'''], [http://www.geoscientific-model-development.net Geoscientific Model Development Discussions (GMDD)] 4, 497-545, 2011

* Janice Coen, '''Some new basics of fire behavior''', Fire Management Today, In Press. [http://www.mmm.ucar.edu/people/coen/files/Coen_FMT_complete.pdf pdf]

* Janice Coen, 2010: '''Dry lightning'''. Southern California Fire Journal, Spring 2010, 18-23.

* Jan Mandel, Jonathan D. Beezley, Janice L. Coen, and Minjeong Kim, '''Data Assimilation for Wildland Fires: Ensemble Kalman filters in coupled atmosphere-surface models''', [http://dx.doi.org/10.1109/MCS.2009.932224 IEEE Control Systems Magazine 29, Issue 3, June 2009, 47-65] Also available as {{arXiv|0712.3965}}.

* Zhen Wang, Janice Coen, Anthony Vodacek, 2009, [http://www.mmm.ucar.edu/people/coen/files/Wang_18_302-309.pdf '''Generation of synthetic infrared remote sensing scenes of wildland fire''']. Intl. J. Wildland Fire, 18, 302-319.

* Jan Mandel and Craig W. Johns, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/cjjm-fires-revised.pdf '''A two-stage Ensemble Kalman Filter for Smooth Data Assimilation'''], Environmental and Ecological Statistics 15, 101-110, 2008

* Janice Coen, 2008: Deadly fingers of flame. Southern California Fire Journal. 1(1):5-6.

* Jonathan D. Beezley and Jan Mandel, '''Morphing Ensemble Kalman Filters''', Tellus 60A, 131-140, 2008 [http://arxiv.org/abs/0705.3693 arXiv:0705.3693]

* Jan Mandel, Lynn S. Bennethum, Jonathan D. Beezley, Janice L. Coen, Craig C. Douglas, Minjeong Kim, and Anthony Vodacek, [http://www-math.cudenver.edu/ccm/reports/rep233.pdf '''A wildland fire model with data assimilation'''], Mathematics and Computers in Simulation 79, 584-606, 2008, [http://dx.doi.org/10.1016/j.matcom.2008.03.015 article], [http://math.ucdenver.edu/%7Ejmandel/papers/rep233.pdf CCM Report 233 June 2006 revised January 2008]

== Conference proceedings ==

* Nina Dobrinkova, Georgi Jordanov, and Jan Mandel, '''WRF-Fire Applied in Bulgaria''', Numerical Methods and Applications, I. Dimov, S. Dimova, and N. Kolkovska, eds., Lecture Notes in Computer Science 6046, Springer, Berlin/Heidelberg, 2011, pp. 133-140. Proceedings of 7th International Conference on Numerical Methods and Applications - NM&A'10, August 20 - 24, 2010, Borovets, Bulgaria. {{doi|10.1007/978-3-642-18466-6_15}}. Preprint {{arXiv|1007.5347}}, July 2010.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

* Jan Mandel and Jonathan D. Beezley, [http://dx.doi.org/10.1007/978-3-642-01973-9_53 '''An Ensemble Kalman-Particle Predictor-Corrector Filter for Non-Gaussian Data Assimilation'''], Proceedings ICCS 2009, Lecture Notes in Computer Science 5545, Springer, 2009, pp. 470-478. Also available at {{arXiv|0812.2290}}.

*Jan Mandel, Jonathan D. Beezley, and Volodymyr Y. Kondratenko, '''Fast Fourier Transform Ensemble Kalman Filter with Application to a Coupled Atmosphere-Wildland Fire Model'''. Anna M. Gil-Lafuente, Jose M. Merigo (Eds.) [http://www.worldscibooks.com/compsci/7925.html Computational Intelligence in Business and Economics] (Proceedings of the [http://www.amse-modeling.com/ms10/ MS'10 International Conference], Barcelona, Spain, 15-17 July 2010), World Scientific, pp. 777-784. Also available at {{arXiv|1001.1588}}.

==Posters==
* Adam K. Kochanski, S. K. Krueger , M. A. Jenkins, J. Mandel and J. D. Beezley, '''Real time simulation of 2007 Santa Ana fires''', Exploring the Mega-fire Reality 2011.

* M. Jenkins, A. Kochanski, S. K. Krueger, W. Mell, R. McDermott, [[media:AGU.2010.poster.jenkins.etal.pdf|'''The Fluid Dynamical Forces Involved in Grass Fire Propagation''']], AGU Fall Meeting, 2010

* J. D. Beezley, A. Kochanski, V. Y. Kondratenko, J. Mandel, B. Sousedik, [[media:agu10_jb.pdf|'''Simulation of the Meadow Creek ﬁre using WRF-Fire''']], AGU Fall Meeting, 2010

* Jan Mandel, Jonathan D. Beezley, Adam K. Kochanski, Volodymyr Y. Kondratenko, Bedrich Sousedik, Erik Anderson, and Joel Daniels, [[media:agu10_jm.pdf|'''Wildland fire simulation by WRF-Fire''']], AGU Fall Meeting, 2010

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analysis and Application of WRF-Fire''', AGU Fall Meeting, 2009.

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analyses of Ignition Area and Fire-Atmosphere Dynamics using WRF-FIRE''', 8th Symposium on Fire & Forest Meteorology, American Meteorological Society, Kalispell. Oct 13-15, 2009.

* Kara Yedinak, J. L. Coen, and B. Lamb, '''WRF-Fire: A fire-atmosphere dynamics module for air quality modeling''', [http://ams.confex.com/ams/89annual/techprogram/MEETING.HTM The 89th American Meteorological Society Annual Meeting (Phoenix, AZ)], [http://ams.confex.com/ams/89annual/techprogram/program_532.htm 11th Conference on Atmospheric Chemistry], [http://ams.confex.com/ams/89annual/techprogram/paper_150173.htm Poster JP 1.10], January 2009.

== Presentations ==
* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Coupled atmosphere-fire simulations of the FireFlux experiment: Impacts of model resolution on its performance''', AMS Ninth Symposium on Fire and Forest Meteorology, Palm Springs, Nov. 2011. [http://ams.confex.com/ams/9FIRE/webprogram/Manuscript/Paper192314/AMS_2011_Extended_abstract_final.pdf extended abstract]

* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Evaluation of The Fire Plume Dynamics Simulated by WRF-Fire''', AGU Fall Meeting, 2010 [[media:AGU.2010.kochanski.key.pdf|pdf]] [[media:AGU.2010.kochanski.key.gz|key]]
* J. Mandel, '''Coupled atmosphere-wildland fire simulation by WRF-Fire''', Invited lecture at [http://www.ima.umn.edu/ IMA] Workshop [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/ Numerical Solutions of Partial Differential Equations: Fast Solution Techniques], December 2, 2010. [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/abstracts.html#10318 abstract] [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/activities/Mandel-Jan/ima10.key.pdf pdf] {{daseminar|slides/ima10/ima10.key.zip|key}} [http://www.ima.umn.edu/videos/?id=1507 video]
* Janice Coen, '''Computational Modeling of Wildland Fire Behavior and Weather for Research and Forecasting''', keynote lecture at ICCS 2009 [http://www.science.uva.nl/sites/iccs-meeting/iccs2009/abs-Coen.html abstract]

==Other==

* Wang, W., Bruyere, C., Duda, M., Dudhia, J., Gill, D., Lin, H.C., Michalakes, J., Rizvi, S., Zhang, X., Beezley, J.D., Coen, J.L., Mandel, J.: '''[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/ARWUsersGuideV3.pdf ARW version 3 modeling system user’s guide]'''. Mesoscale & Miscroscale Meteorology Division, National Center for Atmospheric Research (July 2010)

== Earlier publications and presentations (before 2008)==

: ''Here are some related publications and presentations from our previous work.''

* Janice Coen, [http://www.cise.nsf.gov/cns/darema/dd_das/coen/ '''Coupled Atmosphere-Wildfire Modeling'''], NSF Workshop, April 25, 2000

* Jan Mandel [http://math.ucdenver.edu/%7Ejmandel/papers/rep231.pdf '''Efficient Implementation of the Ensemble Kalman Filter'''], CCM Report 231, May 2006.

* Jan Mandel and Jonathan D. Beezley, [http://math.ucdenver.edu/~jmandel/papers/ametsoc07.pdf '''Predictor-Corrector and Morphing Ensemble Filters for the Assimilation of Sparse Data into High-Dimensional Nonlinear Systems'''], 11th Symposium on Integrated Observing and Assimilation Systems for the Atmosphere, Oceans, and Land Surface (IOAS-AOLS), CD-ROM, [http://ams.confex.com/ams/87ANNUAL/techprogram/paper_119633.htm Paper 4.12], 87th American Meterological Society Annual Meeting, San Antonio, TX, January 2007 [http://math.ucdenver.edu/~jmandel/slides/ametsoc07-jm.pdf presentation], [http://www-math.cudenver.edu/ccm/reports/rep239.pdf CCM Report 239, November 2006]

* Jan Mandel, Jonathan D. Beezley, Lynn S. Bennethum, Soham Chakraborty, Janice L. Coen, Craig C. Douglas, Jay Hatcher, Minjeong Kim, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-paper.pdf '''A Dynamic Data Driven Wildland Fire Model'''], ICCS 2007, Part I, Yong Shi, G. D. van Albada, P. M. A. Sloot and J. J. Dongarra (Eds), Lecture Notes in Computer Science 4487, 1042--1049, Springer, 2007. [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-slides.pdf Presentation]

* Jan Mandel, Lynn S. Bennethum, Mingshi Chen, Janice L. Coen, Craig C. Douglas, Leopoldo P. Franca, Craig J. Johns, Minjeong Kim, Andrew V. Knyazev, Robert Kremens, Vaibhav Kulkarni, Guan Qin, Anthony Vodacek, Jianjia Wu, Wei Zhao, and Adam Zornes, [http://math.ucdenver.edu/~jmandel/papers/fires-iccs05.pdf '''Towards a Dynamic Data Driven Application System for Wildfire Simulation'''] V.S. Sunderam et al. (Eds.): Computational Science - Proceedings ICCS'2005, Lecture Notes in Computer Science 3515, pp. 632-639, 2005.

* Craig C. Douglas, Jonathan D. Beezley, Janice Coen, Deng Li, Wei Li, Alan K. Mandel, Jan Mandel, Guan Qin, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/wf-demo.pdf '''Demonstrating the Validity of Wildfire DDDAS'''], Computational Science - ICCS 2006: 6th International Conference, Reading, UK, May 28-31, 2006, Proceedings, Part III, Vassil N. Alexandrov, Dick van Albada, Dick Geert and Peter M. A. Sloot and Jack Dongarra (Eds.), Lecture Notes in Computer Science 3993, Springer 2006, pp. 522-529.

* J. Mandel, M. Chen, L.P. Franca, C. Johns, A. Puhalskii, J.L. Coen, C.C. Douglas, R. Kremens, A. Vodacek, W. Zhao, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/fires_krakow.pdf '''A Note on Dynamic Data Driven Wildfire Modeling'''], Computational Science - Proceedings ICCS'2004, vol. III, edited by Marian Bubak, G.Dick van Albada, Peter M.A. Sloot, Jack J. Dongarra, Lecture Notes in Computer Science 3038, Springer, pp. 725-731. Copyright Springer 2004. [http://dx.doi.org/10.1007/b97989 book], [http://math.ucdenver.edu/%7Ejmandel/papers/fires_krakow.pdf PDF 150K]

* Edward G. Patton and Janice L. Coen, [http://www.mmm.ucar.edu/mm5/workshop/ws04/Session9/Patton_Edward.pdf WRF-Fire: A Coupled Atmosphere-Fire Module for WRF], Preprints of Joint MM5/Weather Research and Forecasting Model Users' Workshop, Boulder, CO, June 22-25, 2004, pp. 221-223, NCAR.

[[Category:Contents]]

Publications

2011-12-05T17:47:05Z

Adamko: /* Presentations */

== Journal articles ==
* Jan Mandel, Jonathan D. Beezley, and Adam K. Kochanski, [http://www.geosci-model-dev-discuss.net/4/497/2011/gmdd-4-497-2011.html '''Coupled atmosphere-wildland fire modeling with WRF-Fire version 3.3'''], [http://www.geoscientific-model-development.net Geoscientific Model Development Discussions (GMDD)] 4, 497-545, 2011

* Janice Coen, '''Some new basics of fire behavior''', Fire Management Today, In Press. [http://www.mmm.ucar.edu/people/coen/files/Coen_FMT_complete.pdf pdf]

* Janice Coen, 2010: '''Dry lightning'''. Southern California Fire Journal, Spring 2010, 18-23.

* Jan Mandel, Jonathan D. Beezley, Janice L. Coen, and Minjeong Kim, '''Data Assimilation for Wildland Fires: Ensemble Kalman filters in coupled atmosphere-surface models''', [http://dx.doi.org/10.1109/MCS.2009.932224 IEEE Control Systems Magazine 29, Issue 3, June 2009, 47-65] Also available as {{arXiv|0712.3965}}.

* Zhen Wang, Janice Coen, Anthony Vodacek, 2009, [http://www.mmm.ucar.edu/people/coen/files/Wang_18_302-309.pdf '''Generation of synthetic infrared remote sensing scenes of wildland fire''']. Intl. J. Wildland Fire, 18, 302-319.

* Jan Mandel and Craig W. Johns, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/cjjm-fires-revised.pdf '''A two-stage Ensemble Kalman Filter for Smooth Data Assimilation'''], Environmental and Ecological Statistics 15, 101-110, 2008

* Janice Coen, 2008: Deadly fingers of flame. Southern California Fire Journal. 1(1):5-6.

* Jonathan D. Beezley and Jan Mandel, '''Morphing Ensemble Kalman Filters''', Tellus 60A, 131-140, 2008 [http://arxiv.org/abs/0705.3693 arXiv:0705.3693]

* Jan Mandel, Lynn S. Bennethum, Jonathan D. Beezley, Janice L. Coen, Craig C. Douglas, Minjeong Kim, and Anthony Vodacek, [http://www-math.cudenver.edu/ccm/reports/rep233.pdf '''A wildland fire model with data assimilation'''], Mathematics and Computers in Simulation 79, 584-606, 2008, [http://dx.doi.org/10.1016/j.matcom.2008.03.015 article], [http://math.ucdenver.edu/%7Ejmandel/papers/rep233.pdf CCM Report 233 June 2006 revised January 2008]

== Conference proceedings ==

* Nina Dobrinkova, Georgi Jordanov, and Jan Mandel, '''WRF-Fire Applied in Bulgaria''', Numerical Methods and Applications, I. Dimov, S. Dimova, and N. Kolkovska, eds., Lecture Notes in Computer Science 6046, Springer, Berlin/Heidelberg, 2011, pp. 133-140. Proceedings of 7th International Conference on Numerical Methods and Applications - NM&A'10, August 20 - 24, 2010, Borovets, Bulgaria. {{doi|10.1007/978-3-642-18466-6_15}}. Preprint {{arXiv|1007.5347}}, July 2010.

* Janice L. Coen and Craig C. Douglas, '''Computational Modeling of Large Wildfires: A Roadmap.''', 9th International Symposium on Distributed Computing and Applications to Business, Engineering & Science. Accepted. [http://www.mmm.ucar.edu/people/coen/files/Coen_Douglas_final.pdf preprint]

* Jan Mandel and Jonathan D. Beezley, [http://dx.doi.org/10.1007/978-3-642-01973-9_53 '''An Ensemble Kalman-Particle Predictor-Corrector Filter for Non-Gaussian Data Assimilation'''], Proceedings ICCS 2009, Lecture Notes in Computer Science 5545, Springer, 2009, pp. 470-478. Also available at {{arXiv|0812.2290}}.

*Jan Mandel, Jonathan D. Beezley, and Volodymyr Y. Kondratenko, '''Fast Fourier Transform Ensemble Kalman Filter with Application to a Coupled Atmosphere-Wildland Fire Model'''. Anna M. Gil-Lafuente, Jose M. Merigo (Eds.) [http://www.worldscibooks.com/compsci/7925.html Computational Intelligence in Business and Economics] (Proceedings of the [http://www.amse-modeling.com/ms10/ MS'10 International Conference], Barcelona, Spain, 15-17 July 2010), World Scientific, pp. 777-784. Also available at {{arXiv|1001.1588}}.

==Posters==

* M. Jenkins, A. Kochanski, S. K. Krueger, W. Mell, R. McDermott, [[media:AGU.2010.poster.jenkins.etal.pdf|'''The Fluid Dynamical Forces Involved in Grass Fire Propagation''']], AGU Fall Meeting, 2010

* J. D. Beezley, A. Kochanski, V. Y. Kondratenko, J. Mandel, B. Sousedik, [[media:agu10_jb.pdf|'''Simulation of the Meadow Creek ﬁre using WRF-Fire''']], AGU Fall Meeting, 2010

* Jan Mandel, Jonathan D. Beezley, Adam K. Kochanski, Volodymyr Y. Kondratenko, Bedrich Sousedik, Erik Anderson, and Joel Daniels, [[media:agu10_jm.pdf|'''Wildland fire simulation by WRF-Fire''']], AGU Fall Meeting, 2010

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analysis and Application of WRF-Fire''', AGU Fall Meeting, 2009.

* Kara Yedinak, Brian Lamb, Janice Coen, '''Sensitivity Analyses of Ignition Area and Fire-Atmosphere Dynamics using WRF-FIRE''', 8th Symposium on Fire & Forest Meteorology, American Meteorological Society, Kalispell. Oct 13-15, 2009.

* Kara Yedinak, J. L. Coen, and B. Lamb, '''WRF-Fire: A fire-atmosphere dynamics module for air quality modeling''', [http://ams.confex.com/ams/89annual/techprogram/MEETING.HTM The 89th American Meteorological Society Annual Meeting (Phoenix, AZ)], [http://ams.confex.com/ams/89annual/techprogram/program_532.htm 11th Conference on Atmospheric Chemistry], [http://ams.confex.com/ams/89annual/techprogram/paper_150173.htm Poster JP 1.10], January 2009.

== Presentations ==
* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Coupled atmosphere-fire simulations of the FireFlux experiment: Impacts of model resolution on its performance''', AMS Ninth Symposium on Fire and Forest Meteorology, Palm Springs, Nov. 2011. [http://ams.confex.com/ams/9FIRE/webprogram/Manuscript/Paper192314/AMS_2011_Extended_abstract_final.pdf extended abstract]

* A. Kochanski, M. Jenkins, S. K. Krueger, J. Mandel, J. D. Beezley, C. B. Clements, '''Evaluation of The Fire Plume Dynamics Simulated by WRF-Fire''', AGU Fall Meeting, 2010 [[media:AGU.2010.kochanski.key.pdf|pdf]] [[media:AGU.2010.kochanski.key.gz|key]]
* J. Mandel, '''Coupled atmosphere-wildland fire simulation by WRF-Fire''', Invited lecture at [http://www.ima.umn.edu/ IMA] Workshop [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/ Numerical Solutions of Partial Differential Equations: Fast Solution Techniques], December 2, 2010. [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/abstracts.html#10318 abstract] [http://www.ima.umn.edu/2010-2011/W11.29-12.3.10/activities/Mandel-Jan/ima10.key.pdf pdf] {{daseminar|slides/ima10/ima10.key.zip|key}} [http://www.ima.umn.edu/videos/?id=1507 video]
* Janice Coen, '''Computational Modeling of Wildland Fire Behavior and Weather for Research and Forecasting''', keynote lecture at ICCS 2009 [http://www.science.uva.nl/sites/iccs-meeting/iccs2009/abs-Coen.html abstract]

==Other==

* Wang, W., Bruyere, C., Duda, M., Dudhia, J., Gill, D., Lin, H.C., Michalakes, J., Rizvi, S., Zhang, X., Beezley, J.D., Coen, J.L., Mandel, J.: '''[http://www.mmm.ucar.edu/wrf/users/docs/user_guide_V3/ARWUsersGuideV3.pdf ARW version 3 modeling system user’s guide]'''. Mesoscale & Miscroscale Meteorology Division, National Center for Atmospheric Research (July 2010)

== Earlier publications and presentations (before 2008)==

: ''Here are some related publications and presentations from our previous work.''

* Janice Coen, [http://www.cise.nsf.gov/cns/darema/dd_das/coen/ '''Coupled Atmosphere-Wildfire Modeling'''], NSF Workshop, April 25, 2000

* Jan Mandel [http://math.ucdenver.edu/%7Ejmandel/papers/rep231.pdf '''Efficient Implementation of the Ensemble Kalman Filter'''], CCM Report 231, May 2006.

* Jan Mandel and Jonathan D. Beezley, [http://math.ucdenver.edu/~jmandel/papers/ametsoc07.pdf '''Predictor-Corrector and Morphing Ensemble Filters for the Assimilation of Sparse Data into High-Dimensional Nonlinear Systems'''], 11th Symposium on Integrated Observing and Assimilation Systems for the Atmosphere, Oceans, and Land Surface (IOAS-AOLS), CD-ROM, [http://ams.confex.com/ams/87ANNUAL/techprogram/paper_119633.htm Paper 4.12], 87th American Meterological Society Annual Meeting, San Antonio, TX, January 2007 [http://math.ucdenver.edu/~jmandel/slides/ametsoc07-jm.pdf presentation], [http://www-math.cudenver.edu/ccm/reports/rep239.pdf CCM Report 239, November 2006]

* Jan Mandel, Jonathan D. Beezley, Lynn S. Bennethum, Soham Chakraborty, Janice L. Coen, Craig C. Douglas, Jay Hatcher, Minjeong Kim, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-paper.pdf '''A Dynamic Data Driven Wildland Fire Model'''], ICCS 2007, Part I, Yong Shi, G. D. van Albada, P. M. A. Sloot and J. J. Dongarra (Eds), Lecture Notes in Computer Science 4487, 1042--1049, Springer, 2007. [http://math.ucdenver.edu/%7Ejmandel/fires/papers/iccs07-slides.pdf Presentation]

* Jan Mandel, Lynn S. Bennethum, Mingshi Chen, Janice L. Coen, Craig C. Douglas, Leopoldo P. Franca, Craig J. Johns, Minjeong Kim, Andrew V. Knyazev, Robert Kremens, Vaibhav Kulkarni, Guan Qin, Anthony Vodacek, Jianjia Wu, Wei Zhao, and Adam Zornes, [http://math.ucdenver.edu/~jmandel/papers/fires-iccs05.pdf '''Towards a Dynamic Data Driven Application System for Wildfire Simulation'''] V.S. Sunderam et al. (Eds.): Computational Science - Proceedings ICCS'2005, Lecture Notes in Computer Science 3515, pp. 632-639, 2005.

* Craig C. Douglas, Jonathan D. Beezley, Janice Coen, Deng Li, Wei Li, Alan K. Mandel, Jan Mandel, Guan Qin, and Anthony Vodacek, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/wf-demo.pdf '''Demonstrating the Validity of Wildfire DDDAS'''], Computational Science - ICCS 2006: 6th International Conference, Reading, UK, May 28-31, 2006, Proceedings, Part III, Vassil N. Alexandrov, Dick van Albada, Dick Geert and Peter M. A. Sloot and Jack Dongarra (Eds.), Lecture Notes in Computer Science 3993, Springer 2006, pp. 522-529.

* J. Mandel, M. Chen, L.P. Franca, C. Johns, A. Puhalskii, J.L. Coen, C.C. Douglas, R. Kremens, A. Vodacek, W. Zhao, [http://math.ucdenver.edu/%7Ejmandel/fires/papers/fires_krakow.pdf '''A Note on Dynamic Data Driven Wildfire Modeling'''], Computational Science - Proceedings ICCS'2004, vol. III, edited by Marian Bubak, G.Dick van Albada, Peter M.A. Sloot, Jack J. Dongarra, Lecture Notes in Computer Science 3038, Springer, pp. 725-731. Copyright Springer 2004. [http://dx.doi.org/10.1007/b97989 book], [http://math.ucdenver.edu/%7Ejmandel/papers/fires_krakow.pdf PDF 150K]

* Edward G. Patton and Janice L. Coen, [http://www.mmm.ucar.edu/mm5/workshop/ws04/Session9/Patton_Edward.pdf WRF-Fire: A Coupled Atmosphere-Fire Module for WRF], Preprints of Joint MM5/Weather Research and Forecasting Model Users' Workshop, Boulder, CO, June 22-25, 2004, pp. 221-223, NCAR.

[[Category:Contents]]