openwfm - User contributions [en]

SFIRE variables

2026-02-11T02:43:26Z

Jmandel: /* List of variables */ fix static data link

{{users guide}}
{{Hangon}}

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

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

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

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

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

Variables on the fire mesh are located at the centers of the fire mesh cells of a 2D fire mesh.

==List of variables==
The authoritative information can be always found in {{WRF-Fire-file|wrfv2_fire/Registry/registry.fire|the Registry}}.

{| border="1"
|+ Fire variables on fire grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | NFUEL_CAT
|fuel data
|
|-
| scope="row" | ZSF
|height of surface above sea level
|m
|-
| scope="row" | DZDXF
|surface gradient x
|1
|-
| scope="row" | DZDYF
|surface gradient y
|1
|}

{| border="1"
|+Fire variables on atm grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | RTHFRTEN
|temperature tendency
|K/s
|-
| scope="row" | RQVFRTEN
|humidity tendency
|
|}

{| border="1"
|+Diagnostics
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | AVG_FUEL_FRAC
|fuel remaining averaged to atmospheric grid
|1
|-
| scope="row" | GRNHFX
|heat flux from ground fire
|W/m2
|-
| scope="row" | GRNQFX
|moisture flux from ground fire
|W/m2
|-
| scope="row" | CANHFX
|heat flux from crown fire
|W/m2
|-
| scope="row" | CANQFX
|moisture flux from crown fire
|W/m2
|-
| scope="row" | UAH
|wind at fire_wind_heigh
|m/s
|-
| scope="row" | VAH
|wind at fire_wind_heigh
|m/s
|}

{| border="1"
|+Sfire variables on fire grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | TIGN_G
|ignition time on ground
|s
|-
| scope="row" | LFN
|level function
|1
|-
| scope="row" | FUEL_FRAC
|fuel remaining
|1
|-
| scope="row" | FMC_G
|fuel moisture contents
|1
|-
| scope="row" | FIRE_AREA
|fraction of cell area on fire
|1
|-
| scope="row" | UF
|fire wind
|m/s
|-
| scope="row" | VF
|fire wind
|m/s
|-
| scope="row" | FGRNHFX
|heat flux from ground fire
|W/m2
|-
| scope="row" | FGRNQFX
|moisture flux from ground fire
|W/m2
|-
| scope="row" | FCANHFX
|heat flux from crown fire
|W/m2
|-
| scope="row" | FCANQFX
|moisture flux from crown fire
|W/m2
|}

{| border="1"
|+Diagnostics for the actual modeled fire
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | ROS
|rate of spread in the normal direction to the fireline
|m/s
|-
| scope="row" | FLINEINT
|fireline intensity
|W/m
|-
| scope="row" | FLINEINT2
|alternative fireline intensity
|J/m/s2
|}

{| border="1"
|+Diagnostics for fire risk rating - independent on any actual fire going on
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | F_ROS0
|base rate of spread in all directions
|m/s
|-
| scope="row" | F_ROSX
|X component of the spread vector driven by wind and slope
|m/s
|-
| scope="row" | F_ROSY
|Y component of the spread vector driven by wind and slope
|m/s
|-
| scope="row" | F_ROS
|max spread rate in any direction
|m/s
|-
| scope="row" | F_INT
|fire reaction intensity for risk rating, without fire
|J/m2/s
|-
| scope="row" | F_LINEINT
|Byram fireline intensity for risk rating, without fire
|J/m/s
|-
| scope="row" | F_LINEINT2
|alternative fireline intensity for risk rating, without fire"
|J/m/s2
|}

{| border="1"
|+Constant data arrays
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | FXLONG
|longitude of midpoints of fire cells
|degrees
|-
| scope="row" |FXLAT
|latitude of midpoints of fire cells
|degrees
|-
| scope="row" |FUEL_TIME
|fuel
|
|-
| scope="row" |BBB
|fuel
|
|-
| scope="row" |PHISC
|fuel
|
|-
| scope="row" |PHIWC
|fuel
|
|-
| scope="row" |R_0
|fuel
|
|-
| scope="row" |FGIP
|fuel
|
|-
| scope="row" |FZ0
|fuel roughness height
|
|-
| scope="row" |FWH
|fuel fire wind height
|
|-
| scope="row" |ISCHAP
|fuel
|
|}

Note: The fuel variables are automatically filled from the fuel category (NFUEL_CAT) at initialization, which is contained in [[Running WRF-SFIRE with real data in the WRFx system#Get fire static data|static data]]; they are normally not set by the user directly.

== Fire intensities ==
We introduce three fire intensities:

1. Reaction : The heat release rate per unit area of the front.

2. Byram : The heat produced per unit length of the fireline in unit time (J/m/s) in the so-called flaming zone behind the fireline.

3. Fireline, new : The amount of heat generated by the advancing fireline from the newly burning fuel only, in the unit of time.

Definitions and implementations of fire intensities include variables :

* HF : Heat contents of the fuel (J/kg)

* RS : Fire spread rate (m/s)

* F : Fuel remaining at time t (kg/m2)

* F0 : Initial fuel load (kg/m2)

* Fn : Fuel load when reaction ends (kg/m2)

* Fr : Fuel fraction burnt in the flaming (or reaction) zone (1)

* Tf : fuel burn time (1-1/e 63% of the fuel burned) (s)

* <var>τ</var>R : Reaction time (s)

{| border="1"
|+
| scope="col" | Intensity
| scope="col" | Definition
| scope="col" | Implementation
| scope="col" | Unit
| scope="col" | Depends on rates spread RS
| scope="col" | Depends on rates burn 1/Tf
|-
| scope="row" | Reaction
|IR = HF(F0-Fn)/<var>τ</var>R
|IR = HFF0Fr/(-Tfln(1-Fr)
| J/m2/s
| no
| yes
|-
| scope="row" | Byram
| I = HFRSF
| I = HFRSF0Fr
| J/m/s
| yes
| no
|-
| scope="row" | Fireline, new
| J(<var>Δ</var>t2) ≈ HFRSF0 ∫a<var>Δ</var>t<var>τ</var>R/Tf d<var>τ</var>
| J = HFRSF0/2Tf
| J/m/s2
| yes
| yes
|}

==See also==

* [[How to interpret WRF variables]]

SFIRE variables

2026-02-11T02:40:04Z

Jmandel: /* List of variables */ link fuel variables

{{users guide}}
{{Hangon}}

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

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

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

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

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

Variables on the fire mesh are located at the centers of the fire mesh cells of a 2D fire mesh.

==List of variables==
The authoritative information can be always found in {{WRF-Fire-file|wrfv2_fire/Registry/registry.fire|the Registry}}.

{| border="1"
|+ Fire variables on fire grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | NFUEL_CAT
|fuel data
|
|-
| scope="row" | ZSF
|height of surface above sea level
|m
|-
| scope="row" | DZDXF
|surface gradient x
|1
|-
| scope="row" | DZDYF
|surface gradient y
|1
|}

{| border="1"
|+Fire variables on atm grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | RTHFRTEN
|temperature tendency
|K/s
|-
| scope="row" | RQVFRTEN
|humidity tendency
|
|}

{| border="1"
|+Diagnostics
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | AVG_FUEL_FRAC
|fuel remaining averaged to atmospheric grid
|1
|-
| scope="row" | GRNHFX
|heat flux from ground fire
|W/m2
|-
| scope="row" | GRNQFX
|moisture flux from ground fire
|W/m2
|-
| scope="row" | CANHFX
|heat flux from crown fire
|W/m2
|-
| scope="row" | CANQFX
|moisture flux from crown fire
|W/m2
|-
| scope="row" | UAH
|wind at fire_wind_heigh
|m/s
|-
| scope="row" | VAH
|wind at fire_wind_heigh
|m/s
|}

{| border="1"
|+Sfire variables on fire grid
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | TIGN_G
|ignition time on ground
|s
|-
| scope="row" | LFN
|level function
|1
|-
| scope="row" | FUEL_FRAC
|fuel remaining
|1
|-
| scope="row" | FMC_G
|fuel moisture contents
|1
|-
| scope="row" | FIRE_AREA
|fraction of cell area on fire
|1
|-
| scope="row" | UF
|fire wind
|m/s
|-
| scope="row" | VF
|fire wind
|m/s
|-
| scope="row" | FGRNHFX
|heat flux from ground fire
|W/m2
|-
| scope="row" | FGRNQFX
|moisture flux from ground fire
|W/m2
|-
| scope="row" | FCANHFX
|heat flux from crown fire
|W/m2
|-
| scope="row" | FCANQFX
|moisture flux from crown fire
|W/m2
|}

{| border="1"
|+Diagnostics for the actual modeled fire
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | ROS
|rate of spread in the normal direction to the fireline
|m/s
|-
| scope="row" | FLINEINT
|fireline intensity
|W/m
|-
| scope="row" | FLINEINT2
|alternative fireline intensity
|J/m/s2
|}

{| border="1"
|+Diagnostics for fire risk rating - independent on any actual fire going on
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | F_ROS0
|base rate of spread in all directions
|m/s
|-
| scope="row" | F_ROSX
|X component of the spread vector driven by wind and slope
|m/s
|-
| scope="row" | F_ROSY
|Y component of the spread vector driven by wind and slope
|m/s
|-
| scope="row" | F_ROS
|max spread rate in any direction
|m/s
|-
| scope="row" | F_INT
|fire reaction intensity for risk rating, without fire
|J/m2/s
|-
| scope="row" | F_LINEINT
|Byram fireline intensity for risk rating, without fire
|J/m/s
|-
| scope="row" | F_LINEINT2
|alternative fireline intensity for risk rating, without fire"
|J/m/s2
|}

{| border="1"
|+Constant data arrays
| scope="col" | Variable name
| scope="col" | Description
| scope="col" | Unit
|-
| scope="row" | FXLONG
|longitude of midpoints of fire cells
|degrees
|-
| scope="row" |FXLAT
|latitude of midpoints of fire cells
|degrees
|-
| scope="row" |FUEL_TIME
|fuel
|
|-
| scope="row" |BBB
|fuel
|
|-
| scope="row" |PHISC
|fuel
|
|-
| scope="row" |PHIWC
|fuel
|
|-
| scope="row" |R_0
|fuel
|
|-
| scope="row" |FGIP
|fuel
|
|-
| scope="row" |FZ0
|fuel roughness height
|
|-
| scope="row" |FWH
|fuel fire wind height
|
|-
| scope="row" |ISCHAP
|fuel
|
|}

Note: The fuel variables are automatically filled from the fuel category (NFUEL_CAT) at initialization, which is contained in [Running WRF-SFIRE with real data in the WRFx system#Get fire static data|static data]; they are normally not set by the user directly.

== Fire intensities ==
We introduce three fire intensities:

1. Reaction : The heat release rate per unit area of the front.

2. Byram : The heat produced per unit length of the fireline in unit time (J/m/s) in the so-called flaming zone behind the fireline.

3. Fireline, new : The amount of heat generated by the advancing fireline from the newly burning fuel only, in the unit of time.

Definitions and implementations of fire intensities include variables :

* HF : Heat contents of the fuel (J/kg)

* RS : Fire spread rate (m/s)

* F : Fuel remaining at time t (kg/m2)

* F0 : Initial fuel load (kg/m2)

* Fn : Fuel load when reaction ends (kg/m2)

* Fr : Fuel fraction burnt in the flaming (or reaction) zone (1)

* Tf : fuel burn time (1-1/e 63% of the fuel burned) (s)

* <var>τ</var>R : Reaction time (s)

{| border="1"
|+
| scope="col" | Intensity
| scope="col" | Definition
| scope="col" | Implementation
| scope="col" | Unit
| scope="col" | Depends on rates spread RS
| scope="col" | Depends on rates burn 1/Tf
|-
| scope="row" | Reaction
|IR = HF(F0-Fn)/<var>τ</var>R
|IR = HFF0Fr/(-Tfln(1-Fr)
| J/m2/s
| no
| yes
|-
| scope="row" | Byram
| I = HFRSF
| I = HFRSF0Fr
| J/m/s
| yes
| no
|-
| scope="row" | Fireline, new
| J(<var>Δ</var>t2) ≈ HFRSF0 ∫a<var>Δ</var>t<var>τ</var>R/Tf d<var>τ</var>
| J = HFRSF0/2Tf
| J/m/s2
| yes
| yes
|}

==See also==

* [[How to interpret WRF variables]]

How to run the standalone fire model in WRF-SFIRE

2026-01-27T07:29:08Z

Jmandel: For building the current version, please follow https://github.com/openwfm/WRF-SFIRE/issues/3

{{users guide}}

===Important note===
The standalone is being updated for current WRF-SFIRE.
For building the current version, please follow https://github.com/openwfm/WRF-SFIRE/issues/3

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build WRF-SFIRE software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link the created '''wrfout''' file to '''fire_input.nc''': '''ln -s wrfout... fire_iput.nc'''

* Wait for wrf.exe to finish.

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-SFIRE-branch|develop-3}} {{WRF-SFIRE-commit|e944a4bf430a0ca8f28dce5c08ff2de11dc94d5|Oct 22 2025}}
* Tested with GNU Fortran (GCC) 9.2.1 on Centos 8.3, libnetcdf 15.0.1, libnetcdff 7.0.0

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

WRF-SFIRE

2026-01-03T10:44:03Z

Jmandel: /* Web-based run system WRFX */

{{users guide}}
[[Category:WRF-SFIRE]]
The fire code in WRF-SFIRE is called SFIRE (for Spread FIRE model). It is based on the [[wikipedia:Level set method|level set method]]. Since June 2011, we call the fire code SFIRE because of [[changes in WRF-Fire 3.3 release]]. The coupled code is called [[WRF]]-[[SFIRE]], and we reserve the designation [[WRF-Fire]] for the code in the WRF release.

==Standalone code==

SFIRE can be used independently without WRF for testing. To make comparison easier, it can run from the same inputs as WRF-Fire.

* See [[How to run the standalone fire model in WRF-Fire]].
* The build process in '''standalone''' uses the generated source code from the WRF file tree, namely the files '''phys/module_fr_sfire_*.f90''' except '''phys/module_fr_sfire_driver_wrf.f90'''. There is no code duplication. Instead of WRF, the fire code is linked with the '''*.F''' files in the '''standalone''' directory, which provide I/O and substitute the required subset of WRF functionality.

==Interface between WRF and SFIRE==

* The defined interface to SFIRE is between '''WRFV3/phys/module_fr_sfire_driver_wrf.F''' and subroutine '''sfire_driver_em''' in '''WRFV3/phys/module_fr_sfire_driver.F'''
* WRF calls '''sfire_driver_em''' once at initialization, and then (with slightly different arguments) in every time step.
* The arguments of '''sfire_driver_em''' consist of two structures (called derived types in Fortran), '''grid''', which contains all state, input, and output variables, and '''config_flags''', with all variables read from from file '''namelist.input''', and some array dimensions.
** The standalone code defines its own '''grid''' derived type with only the subset of the fields needed. All fields in '''grid''' are set in the standalone driver main file, '''standalone/model_test_main.F''', and nothing is hidden elsewhere.
** The standalone code replicates '''config_flags''' from WRF using include files named '''*.inc''' in the '''standalone''' directory. These include files are copies of the files generated by the WRF build process in '''WRFV3/inc'''. They are not soft links so that one can build the standalone code without building WRF. The '''inc''' files may need to be updated when the description of the configuration flags in the WRF registry changes.

==SFIRE architecture==

* SFIRE is compliant with [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions].
* WRF divides the horizontal domain into ''patches'' and divides the patches into ''tiles''. Each patch executes in one MPI process. Each tile is updated by one OpenMP thread.
* The SFIRE code is capable of parallel execution in shared memory. Division into tiles is controlled by fields in '''grid'''. There is only one OpenMP parallel loop over the tiles, in '''WRFV3/phys/module_fr_sfire_driver.F'''. The rest of the SFIRE code executes on a single tile, starting from '''WRFV3/phys/module_fr_sfire_model.F''' Because the tiles need to access values from neighboring tiles at several points in the computation, within a single invocation of SFIRE, the parallel loop is executed several times to synchronize the data in memory at the exit from the loop. Each execution of the parallel loop performs a different stage of the computation.
* When SFIRE runs in distributed memory, the communication between the patches is done in includes in '''WRFV3/phys/module_fr_sfire_driver.F''' (search for HALO). This has no effect in the standalone code; in WRF, the includes are provided by the WRF parallel infrastructure, RSL-Lite. If you want to run SFIRE in MPI, you need to provide equivalent HALO includes yourself.
* SFIRE does not keep any state except scalar flags and fixed-size tables, set at initialization. All adjustable-sized arrays preserved beween calls are in '''grid'''.

==Required testing==

If you change anything in the files '''phys/module_fr_sfire_*.F''', you must test that the changes do not break WRF-Fire, otherwise your changes will not be maintainable.

* Build WRF-SFIRE with SM+DM parallelism with debugging, and test all 4 versions (serial, SM, DM, SM+DM) with the examples provided in '''test/em_fire''' and various numbers of processors. The results (the numerical values in the arrays the '''wrfrst''' files, not the files themselves) should be bit-identical to each other and identical to what they were before your changes. You can compare the files using the '''diffwrf''' utility, which is built as a part of the WRF compilation process, or start Matlab in '''test/em_fire''' (to set the path) and use the command '''ncdiff''' in Matlab.
* Build WRF-Fire with optimization and test on several platforms (at least gfortran).

==Web-based run system WRFx==
This system is available at http://github.com/openwfm. It consists of the following parts:
* [http://github.com/openwfm/wrfxpy wrfxpy] - Initiate and manage WRF-SFIRE simulations on a cluster. Automates data download, queuing and monitoring jobs, and postprocessing outputs into geolocated images. (Python). Intended to run on a head node of the cluster.
* [http://github.com/openwfm/wrfxctrl wrfxctrl] - Map-based web interface to wrfxpy (Python and Javascript). Intended to run on a head node of the cluster. Runs its own web server.
* [http://github.com/openwfm/wrfxweb wrfxweb] - Map-based visualization server running on a remote server. The visualizations are also available as Google Earth KML files. (Browser-based Javascript, Python utilities) Designed to run on a small cloud machine.
See [[Running WRF-SFIRE with real data in the WRFx system]].

==Works with==

* WRF-SFIRE master branch

[[Category:WRF-Fire]]
[[Category:Software]]

Widlund prize

2025-12-10T06:07:35Z

Jmandel:

{{Short description|Award in numerical analysis}}
{{Use dmy dates|date=December 2025}}

The '''Olof B. Widlund Prize''' (formally, the '''Olof B. Widlund Prize for Excellence in Domain Decomposition Methods''') is an award in numerical analysis given in the ''Domain Decomposition Methods'' (DDM) community. According to ddm.org, it is a prize for an established scientist recognizing contributions to domain decomposition methods (including theory, algorithms, scalable implementation, applications, and community service). The awardee gives a plenary lecture at the next ddm.org conference and receives a certificate and a cash award of €2500.<ref name="ddmPrize" />

The prize is named in honor of mathematician [[Olof B. Widlund]].<ref name="ddmPrize" />

== History ==
According to ddm.org, the prize was established by the Scientific Committee of ddm.org at DD26 (2020) and awarded for the first time at DD27 (Prague, 2022).<ref name="ddmPrize" />

== Recipients ==
* '''2022''': Maksymilian Dryja (University of Warsaw).<ref name="dd27GanderNataf">{{cite book
|last1=Gander |first1=Martin J.
|last2=Nataf |first2=Frédéric
|chapter=Substructuring of Arbitrary Domain Decomposition Methods
|editor-last1=Dostál |editor-first1=Zdeněk
|editor-last2=Kozubek |editor-first2=Tomáš
|editor-last3=Klawonn |editor-first3=Axel
|editor-last4=Langer |editor-first4=Ulrich
|editor-last5=Pavarino |editor-first5=Luca F.
|editor-last6=Šístek |editor-first6=Jakub
|editor-last7=Widlund |editor-first7=Olof B.
|title=Domain Decomposition Methods in Science and Engineering XXVII
|publisher=Springer Nature Switzerland
|location=Cham
|year=2024
|isbn=978-3-031-50769-4
|pages=223–230
|at=p. 225
}}</ref>
* '''2024''': Charbel Farhat (Stanford University).<ref name="ddmPrize" />
* '''2025''': Jan Mandel (University of Colorado).<ref name="ddmPrize" />

== References ==
{{reflist}}

== External links ==
* [https://ddm.org/widlund_prize.php The Olof B. Widlund Prize] (ddm.org)


<references>
<ref name="ddmPrize">{{cite web
|title=The Olof B. Widlund Prize
|url=https://ddm.org/widlund_prize.php
|website=ddm.org
|access-date=9 December 2025
}}</ref>
</references>

Widlund prize

2025-12-10T06:06:09Z

Jmandel: v2

{{Short description|Award in numerical analysis}}
{{Use dmy dates|date=December 2025}}

The '''Olof B. Widlund Prize''' (formally, the '''Olof B. Widlund Prize for Excellence in Domain Decomposition Methods''') is an award in numerical analysis given in the ''Domain Decomposition Methods'' (DDM) community. According to ddm.org, it is a prize for an established scientist recognizing contributions to the theory, algorithms, implementation, applications, and community service related to domain decomposition methods. The awardee gives a plenary lecture at the next ddm.org conference and receives a certificate and a cash award of €2500.{{refn|name=ddmPrize}}

The prize is named in honor of mathematician [[Olof B. Widlund]].{{refn|name=ddmPrize}}

== History ==
According to ddm.org, the prize was established by the Scientific Committee of ddm.org at DD26 (2020) and awarded for the first time at DD27 (Prague, 2022).{{refn|name=ddmPrize}}

== Recipients ==
* '''2022''': Maksymilian Dryja (University of Warsaw).<ref name="dd27Chapter225">{{cite book
|last1=Gander |first1=Martin J.
|last2=Nataf |first2=Frédéric
|title=Substructuring of Arbitrary Domain Decomposition Methods
|editor-last1=Dostál |editor-first1=Zdeněk
|editor-last2=Kozubek |editor-first2=Tomáš
|editor-last3=Klawonn |editor-first3=Axel
|editor-last4=Langer |editor-first4=Ulrich
|editor-last5=Pavarino |editor-first5=Luca F.
|editor-last6=Šístek |editor-first6=Jakub
|editor-last7=Widlund |editor-first7=Olof B.
|book-title=Domain Decomposition Methods in Science and Engineering XXVII
|publisher=Springer Nature Switzerland
|location=Cham
|year=2024
|isbn=978-3-031-50769-4
|pages=225
}}</ref>
* '''2024''': Charbel Farhat (Stanford University).{{refn|name=ddmPrize}}
* '''2025''': Jan Mandel (University of Colorado).{{refn|name=ddmPrize}}

== References ==
{{reflist}}

== External links ==
* [https://ddm.org/widlund_prize.php The Olof B. Widlund Prize] (ddm.org)


<references>
<ref name="ddmPrize">{{cite web
|title=The Olof B. Widlund Prize
|url=https://ddm.org/widlund_prize.php
|website=ddm.org
|access-date=9 December 2025
}}</ref>
</references>

Widlund prize

2025-12-10T05:37:30Z

Jmandel: Created page with "The Olof B. Widlund Prize for Excellence in Domain Decomposition Methods was established by the Scientific Committee of [ddm.org|https://ddm.org] at DD26 in 2020, and was awarded for the first time at DD27 in Prague in 2022. The naming of the prize honors a great pioneer of the theory, algorithms, and applications of domain decomposition, a mentor of numerous productive contributors to the field -- both at his own institution and internationally, and a builder of..."

The [[Olof B. Widlund Prize]] for Excellence in [[Domain Decomposition Methods]] was established by the Scientific Committee of [ddm.org|https://ddm.org] at DD26 in 2020, and was awarded for the first time at DD27 in Prague in 2022. The naming of the prize honors a great pioneer of the theory, algorithms, and applications of domain decomposition, a mentor of numerous productive contributors to the field -- both at his own institution and internationally, and a builder of bridges between theorists and practitioners in academic, industry, and government labs on multiple continents.

Category:WRF-SFIRE users guide

2025-11-22T19:06:24Z

Jmandel: Category:Software

This is an automated index of all pages in the [[WRF-SFIRE users guide]].
[[Category:WRF-Fire]]
[[Category:WRF-SFIRE]]
[[Category:Software]]

Category:WRF-SFIRE

2025-11-22T19:05:14Z

Jmandel: Category:Software

List of pages on [[WRF-SFIRE]].
[[Category:Software]]

How to interpret WRF variables

2025-11-22T18:07:03Z

Jmandel: /* Storage order */ rm one more ref to fortran

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Storage order==

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

The value of the time at the step '''t''' is stored in character array '''Times(:,t)'''.

Arrays in WRF NETCDF files, like the WRFOUT files, are written with the indexing as '''(t, z, y, x)''', where '''t''' is the time index, which varies the slowest. This is how the variables appear when read e.g. in Python or C/C++. To read the surface values of such 3D arrays at time step '''t''' and indices '''(x,y)''', use in Python or C/C++ the indexing '''(t, 0, y, x)''' .

WRF 3D arrays in memory are indexed as '''(i,k,j)''' (in FORTRAN) following [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. There is no time index for the time step in arrays in memory, because WRF works with only one time step at a time. In 2D arrays, there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

How to interpret WRF variables

2025-11-22T18:05:46Z

Jmandel: /* Storage order */ rm fortran ordering in files

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Storage order==

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

The value of the time at the step '''t''' is stored in character array '''Times(:,t)'''.

Arrays in WRF NETCDF files, like the WRFOUT files, are written with the indexing as '''(t, z, y, x)''', where '''t''' is the time index, which varies the slowest. This is how the variables appear when read e.g. in Python. However, when read in FORTRAN, the same arrays appear in the FORTRAN column major odering '''(x, y, z, t)'''.

To read the surface values of such 3D arrays at time step '''t''' and indices '''(x,y)''', use in Python or C/C++ the indexing '''(t, 0, y, x)''' .

WRF 3D arrays in memory are indexed as '''(i,k,j)''' (in FORTRAN) following [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. There is no time index for the time step in arrays in memory, because WRF works with only one time step at a time. In 2D arrays, there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

How to interpret WRF variables

2025-11-22T06:01:39Z

Jmandel: /* Storage order */

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Storage order==

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

The value of the time at the step '''t''' is stored in character array '''Times(:,t)'''.

Arrays in WRF NETCDF files, like the WRFOUT files, are written with the indexing as '''(t, z, y, x)''', where '''t''' is the time index, which varies the slowest. The is how the variables appear when read e.g. in Python. However, when read in FORTRAN, the same arrays appear in the FORTRAN column major odering '''(x, y, z, t)'''.

To read the surface values of such 3D arrays at the indices '''(x,y)''', use the indexing '''(t, 0, y, x)''' in Python, and '''(x, y, 1, t)''' in FORTRAN.

Arrays in memory are indexed as '''(i,k,j)''' (in FORTRAN) following [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. There is no time index for the time step in arrays in memory, because WRF works with only one time step at a time. In 2D arrays, there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

Visualizations links

2025-11-22T05:59:18Z

Jmandel: rm dead NCAR links

==YouTube==
*[http://www.youtube.com/user/Wildfireproject Jan's YouTube channel]
*[http://www.youtube.com/user/openwfm OpenWFM YouTube channel]
* [http://www.youtube.com/user/adamk00 Adam's YouTube channel]

[[Category:Visualization]]

Smoke and coupling with WRF-Chem

2025-11-22T05:56:37Z

Jmandel: spelling

{{users guide}}

[[File:Sfire smoke.png|thumb|WRF-SFIRE smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . The coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are computer proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions''' and added to the lowest layer of the active tracer variables.

There are small differences between the propagation of the different tracers, and also between the propagation when the code is build with or without WRF-Chem.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' or '''tracer_opt = 2''' with a code compiled with WRF-Chem. The resulting passive tracers may then be advected by code in WRF-Chem instead of WRF itself.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T05:55:45Z

Jmandel: /* Coupling with WRF-Chem */

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . The coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are computer proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions''' and added to the lowest layer of the active tracer variables.

There are small differences between the propagation of the different tracers, and also between the propagation when the code is build with or without WRF-Chem.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' or '''tracer_opt = 2''' with a code compiled with WRF-Chem. The resulting passive tracers may then be advected by code in WRF-Chem instead of WRF itself.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T05:53:19Z

Jmandel: /* Passive smoke tracers */

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . The coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are computer proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions''' and added to the lowest layer of the active tracer variables.

There are small differences between the propagation of the different tracers, and also between the propagation when the code is build with or without WRF-Chem.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T05:52:44Z

Jmandel: /* Passive smoke tracers */

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . The coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are computer proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions''' and added to the lowest layer of the active tracer variables.

There are small differences between the propagation of the different tracers, and also between the propagation when the code is build with or without WRF-CHEM.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

How to interpret WRF variables

2025-11-22T03:43:55Z

Jmandel: /* Arrays and Storage Order */ -> Storage order

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Storage order==

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

The value of the time at the step '''t''' is stored in character array '''Times(:,t)'''.

Arrays in WRF NETCDF files, like the WRFOUT files, are written with the indexing as '''(t, z, y, x)''', where '''t''' is the time index, which varies the slowest. The is how the variables appear when read e.g. in Python. However, when read in FORTRAN, the same arrays appear in the FORTRAN column major odering '''(x, y, z, t)'''.

To read the surface values of a 3D array, use the indexing '''(t, z, 0, x)''' in Python, and '''(x, y, 1, t)''' in FORTRAN.

Arrays in memory are indexed as '''(i,k,j)''' (in FORTRAN) following [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. There is no time index for the time step in arrays in memory, because WRF works with only one time step at a time. In 2D arrays, there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

How to interpret WRF variables

2025-11-22T03:42:12Z

Jmandel: indexing

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Arrays and Storage Order==

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

The value of the time at the step '''t''' is stored in character array '''Times(:,t)'''.

Arrays in WRF NETCDF files, like the WRFOUT files, are written with the indexing as '''(t, z, y, x)''', where '''t''' is the time index, which varies the slowest. The is how the variables appear when read e.g. in Python. However, when read in FORTRAN, the same arrays appear in the FORTRAN column major odering '''(x, y, z, t)'''.

To read the surface values of a 3D array, use the indexing '''(t, z, 0, x)''' in Python, and '''(x, y, 1, t)''' in FORTRAN.

Arrays in memory are indexed as '''(i,k,j)''' (in FORTRAN) following [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. There is no time index for the time step in arrays in memory, because WRF works with only one time step at a time. In 2D arrays, there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

How to interpret WRF variables

2025-11-22T03:27:36Z

Jmandel: /* Arrays */ storage order

{{users guide}}

This page describes the interpretation of selected atmospheric variables, which are important for fire visualization. See [http://www.mmm.ucar.edu/wrf/users/pub-doc.html WRF documentation] for further details.

==Grid==

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

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

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

==Arrays and Storage Order==

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

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

Arrays in WRF NETCDF files, like the WRFOUT files, are stored with the indexing as '''(t, z, y, x)''', arrays in memory are indexed as '''(i,k,j)''' by [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions]. Of course, there is no 4th index for the time step in arrays in memory, and in some arrays there is no vertical '''k''' dimension.

==Wind==

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

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

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

==Location==

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

PH and PHB live at the W-points, thus the geopotential height at the lowest level is the same as terrain height
: '''ELEVATION_W(i,j) = PHB(i,j,1)/9.81
up to rounding error. This variable is also part of WRF state as '''z_at_w''' and its output to wrfout or wrfrst files can be enabled in the registry.

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

This variable is also part of WRF state as '''Z''' and its output to wrfout or wrfrst files can be enabled in the [https://github.com/jbeezley/wrf-fire/blob/master/wrfv2_fire/Registry/Registry.EM_COMMON#L306 registry].

==Temperature==

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

==Pressure==

''coming soon''

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

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

Smoke and coupling with WRF-Chem

2025-11-22T03:20:54Z

Jmandel: /* Passive smoke tracers */ typo

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . The coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. The fire smoke emissions added to the tracers are the same. Propagation of tracers '''tr17_1''' to '''tr17_4''' is identical, but the others slightly differ.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T03:20:27Z

Jmandel: /* Passive smoke tracers */

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . Yhe coupling supports the option '''tracer_opt = 1''', which creates a single tracer called '''smoke''',
and the option '''tracer_opt = 2''', which creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. The fire smoke emissions added to the tracers are the same. Propagation of tracers '''tr17_1''' to '''tr17_4''' is identical, but the others slightly differ.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T03:16:37Z

Jmandel: /* Passive smoke tracers */

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . At the moment, the coupling supports '''tracer_opt = 1''', which creates a single tracer called '''smoke'''.
The option '''tracer_opt = 2''' creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. Properties of the tracers '''tr17_1''' to '''tr17_4''' are identical, but the others slightly differ.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T00:23:56Z

Jmandel: /* Coupling with WRF-Chem */ typo

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . At the moment, the coupling supports '''tracer_opt = 1''', which creates a single tracer called '''smoke'''.
The option '''tracer_opt = 2''' creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions \are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. Properties of the tracers '''tr17_1''' to '''tr17_4''' are identical, but the others slightly differ.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt''' in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T00:23:34Z

Jmandel: separated passive tracers and chem

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

The selection of the tracers in WRF is controlled by namelist variable '''tracer_opt''' in the '''&dynamics'''] section . At the moment, the coupling supports '''tracer_opt = 1''', which creates a single tracer called '''smoke'''.
The option '''tracer_opt = 2''' creates passive tracers called '''tr17_1''' to '''tr17_8'''.

Emissions \are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. Properties of the tracers '''tr17_1''' to '''tr17_4''' are identical, but the others slightly differ.

==Coupling with WRF-Chem==
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>

The selection of the tracers in WRF-Chem is controlled by namelist variable '''chem_opt'''in '''&chem''' section of '''namelist.input'''. If '''chem_opt=0''', no chemical tracers are created. The coupling supports subsets of RADM2 ('''chem_opt=2'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

It is also possible to use '''tracer_opt = 1''' and '''tracer_opt = 2''' in a code compiled with WRF-Chem, but the resulting passive tracers are advected by WRF-Chem and behave slightly differently.

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

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

Smoke and coupling with WRF-Chem

2025-11-22T00:09:36Z

Jmandel: redo lead

{{users guide}}

[[File:Sfire smoke.png|thumb|SFire smoke tracer in action. See [[File:Smoke small.avi|animation]].]]

Fire emissions can be modeled a passive smoke tracer advected by the wind field,
or as chemical species tracers, which also undergo chemical reactions by WRF-Chem. WRF-Chem is included in the WRF repository. Tracer variables are 3d fields of concentrations on the atmospheric grid. The variables are present in the wrfout files when activated.

==Passive smoke tracers==

==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'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

The option '''tracer_opt = 2''' does not require WRF-Chem, and it creates passive tracers called '''tr17_1''' to '''tr17_8'''. Emissions \are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. Properties of the tracers '''tr17_1''' to '''tr17_4''' are identical, but the others slightly differ.

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

2025-11-21T23:53:27Z

Jmandel: /* Coupling with fuel moisture and smoke */ Smoke and coupling with WRF-Chem

[[Category:WRF-Fire|User's guide]]
[[Category:WRF-SFIRE users guide]]
:''This guide applies to WRF-SFIRE, available at https://github.com/openwfm/WRF-SFIRE. [[Fire_code_in_WRF_release|WRF-Fire]] from the WRF repository https://github.com/wrf-model/WRF is based on a limited version of this software from 2010, and it has evolved separately since then. This guide changes 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}}.''
==Overview==
# [[WRF-SFIRE]]

==Getting started==
# [[How to get WRF-Fire|Downloading the software]]
# [[How to run WRF-Fire|Building the software and running an ideal case]]
# [[How to set up the WRFx system|Setting up the automated simulation system WRFx]]

==Configuration==
# [[namelist.input]]
# [[namelist.fire]]
# [[Vertical wind interpolation]]
# [[WRF-Fire ignition|Ignition]]

==Running a real case==
#[[Running WRF-SFIRE with real data in the WRFx system]]
#[[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]]
# [[Smoke and 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-SFIRE|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 including ATM-0835579, DMS-1216481, and ICER-1664175.

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

Talk:Coupling with WRF-Chem

2025-11-21T23:51:48Z

Jmandel: Jmandel moved page Talk:Coupling with WRF-Chem to Talk:Smoke and coupling with WRF-Chem: Reflect better content of the page

#REDIRECT [[Talk:Smoke and coupling with WRF-Chem]]

Talk:Smoke and coupling with WRF-Chem

2025-11-21T23:51:48Z

Jmandel: Jmandel moved page Talk:Coupling with WRF-Chem to Talk:Smoke and coupling with WRF-Chem: Reflect better content of the page

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

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

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

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

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

From Jon's text April 21 2012. [[User:Jmandel|Jmandel]] 16:34, 23 December 2012 (UTC)

==ch4 and h2 nuked==
Even if we set ch4 and h2 in they get nuked in WRF-Chem in subroutine [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/chem/module_input_chem_data.F#L3540 mozcart_lbc_set] called from [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/chem/chem_driver.F#L885 chem_driver] because [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/chem/chem_driver.F#L799 emiss_inpt_opt>0]. But the [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/Registry/registry.chem#L2393 default] is emiss_inpt_opt=1. This selection also calls emissions_driver, which seems unnecessary because we provide our own emissions. Specify emiss_inp_opt=0 in namelist.input. Not sure about call to [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/chem/module_ltng_cpm.F#L211 adjust_ktop] which no longer gets called.
[[User:Jmandel|Jmandel]] ([[User talk:Jmandel|talk]]) 00:02, 27 April 2014 (UTC)

Call mozcart_lbc_set is in few other places in [https://github.com/jbeezley/wrf-fire/blob/e9051dc5ba0c59e1d7e4d59b47965d891c090142/wrfv2_fire/chem/chem_driver.F chem/chem_driver.F], added mozcart_lbc_set_onoff to the namelist.
[[User:Jmandel|Jmandel]] ([[User talk:Jmandel|talk]]) 03:08, 27 April 2014 (UTC)

Coupling with WRF-Chem

2025-11-21T23:51:48Z

Jmandel: Jmandel moved page Coupling with WRF-Chem to Smoke and coupling with WRF-Chem: Reflect better content of the page

#REDIRECT [[Smoke and coupling with WRF-Chem]]

Smoke and coupling with WRF-Chem

2025-11-21T23:51:47Z

Jmandel: Jmandel moved page Coupling with WRF-Chem to Smoke and coupling with WRF-Chem: Reflect better content of the page

{{users guide}}

As of WRF 4, WRF-Chem is now included in the WRF repository. Fire emissions can 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'''), MOZART ('''chem_opt=112''' or '''119'''), and GOCART ('''chem_opt=300''') variables.

The option '''tracer_opt = 2''' does not require WRF-Chem, and it creates passive tracers called '''tr17_1''' to '''tr17_8'''. Emissions \are inserted proportionally to the fuel burned according to the emission factors in file '''namelist.fire_emissions'''. Properties of the tracers '''tr17_1''' to '''tr17_4''' are identical, but the others slightly differ.

To use the passive tracers in the code built with WRF-Chem, specify '''tracer_opt=2''' and '''chem_opt=0''' in '''namelist.input'''. The tracers work slightly differently in code built with and without WRF-Chem, as described in file '''chem/module_input_tracer.F'''. A sample emission factors table for this usage is available as '''test/em_fire/chem/namelist.fire_emissions.tracers'''. It can be used in ideal as well as real runs. Different rows in the table can be used to track separate species, e.g., pm10 and pm25, with different emission factors.

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.

Several prototype emissions tables are provided in '''test/em_fire/chem'''. You need to copy or link one of the emissions tables to '''namelist.fire_emissions''' in your run directory, such as
<pre>
ln -s namelist.fire_emissions.RADM2 namelist.fire_emissions
</pre>
and set matching '''chem_opt''' in '''namelist.input''', here '''chem_opt=2'''. See the next section for the available emissions tables. Users can also add their own.

==Chemical species==

The chemical model selected by the '''chem_opt''' flag produces concentrations on 3D grids in every '''wrfout''' file produced, for a set of variables defined in the '''Chem scalars''' part of the file [https://github.com/openwfm/WRF-SFIRE/blob/262829290d98e419b6839893ecb1a5d36ed4b969/Registry/registry.chem#L1567 '''Registry/registry.chem''']. The first section of the list contains the chemical species common to all models, later sections list species added for specific models. For more detailed information about the species including dusts and aerosols in specific WRF-Chem models, see the [https://ruc.noaa.gov/wrf/wrf-chem/model_info.htm WRF-Chem model documention] and the links to the individual models at the emissions tables below.

The quantities of the chemical species are in '''ppmv''', i.e., 1e6*mol/mol of dry air.

The frequency of writing the outputs into the wrfout files is specified by the user in the '''history_interval''' flags in the WRF '''namelist.input''' file. It can be as often as once every minute, but usually much less.

SFIRE adds the fire emissions to a subset of the chemical species as specified in the emissions table. It is up to the chemical model to produce other species from them. Note that the parts of the registry.chem file using the word "emissions" are for other emission schemes and not relevant here. SFIRE adds fire emissions directly to the lowest layer of the 3D Chem fiels during the fire simulation.

There are currently three emissions tables available:
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.RADM2 namelist.fire_emissions.RADM2] for the [http://ruc.noaa.gov/wrf/WG11/radm2.htm RADM2] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.MOZART namelist.fire_emissions.MOZART] for the [http://www.acd.ucar.edu/wrf-chem/mozart.shtml MOZART] model
* [https://github.com/openwfm/WRF-SFIRE/blob/master/test/em_fire/chem/namelist.fire_emissions.GOCART namelist.fire_emissions.GOCART] for the [https://tropo.gsfc.nasa.gov/gocart GOCART] model

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

How to run the standalone fire model in WRF-SFIRE

2025-10-22T15:12:41Z

Jmandel: /* Works with */

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build WRF-SFIRE software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link the created '''wrfout''' file to '''fire_input.nc''': '''ln -s wrfout... fire_iput.nc'''

* Wait for wrf.exe to finish.

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-SFIRE-branch|develop-3}} {{WRF-SFIRE-commit|e944a4bf430a0ca8f28dce5c08ff2de11dc94d5|Oct 22 2025}}
* Tested with GNU Fortran (GCC) 9.2.1 on Centos 8.3, libnetcdf 15.0.1, libnetcdff 7.0.0

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

WRF-SFIRE

2025-10-22T15:06:01Z

Jmandel: /* Required testing */ update

{{users guide}}
[[Category:WRF-SFIRE]]
The fire code in WRF-SFIRE is called SFIRE (for Spread FIRE model). It is based on the [[wikipedia:Level set method|level set method]]. Since June 2011, we call the fire code SFIRE because of [[changes in WRF-Fire 3.3 release]]. The coupled code is called [[WRF]]-[[SFIRE]], and we reserve the designation [[WRF-Fire]] for the code in the WRF release.

==Standalone code==

SFIRE can be used independently without WRF for testing. To make comparison easier, it can run from the same inputs as WRF-Fire.

* See [[How to run the standalone fire model in WRF-Fire]].
* The build process in '''standalone''' uses the generated source code from the WRF file tree, namely the files '''phys/module_fr_sfire_*.f90''' except '''phys/module_fr_sfire_driver_wrf.f90'''. There is no code duplication. Instead of WRF, the fire code is linked with the '''*.F''' files in the '''standalone''' directory, which provide I/O and substitute the required subset of WRF functionality.

==Interface between WRF and SFIRE==

* The defined interface to SFIRE is between '''WRFV3/phys/module_fr_sfire_driver_wrf.F''' and subroutine '''sfire_driver_em''' in '''WRFV3/phys/module_fr_sfire_driver.F'''
* WRF calls '''sfire_driver_em''' once at initialization, and then (with slightly different arguments) in every time step.
* The arguments of '''sfire_driver_em''' consist of two structures (called derived types in Fortran), '''grid''', which contains all state, input, and output variables, and '''config_flags''', with all variables read from from file '''namelist.input''', and some array dimensions.
** The standalone code defines its own '''grid''' derived type with only the subset of the fields needed. All fields in '''grid''' are set in the standalone driver main file, '''standalone/model_test_main.F''', and nothing is hidden elsewhere.
** The standalone code replicates '''config_flags''' from WRF using include files named '''*.inc''' in the '''standalone''' directory. These include files are copies of the files generated by the WRF build process in '''WRFV3/inc'''. They are not soft links so that one can build the standalone code without building WRF. The '''inc''' files may need to be updated when the description of the configuration flags in the WRF registry changes.

==SFIRE architecture==

* SFIRE is compliant with [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions].
* WRF divides the horizontal domain into ''patches'' and divides the patches into ''tiles''. Each patch executes in one MPI process. Each tile is updated by one OpenMP thread.
* The SFIRE code is capable of parallel execution in shared memory. Division into tiles is controlled by fields in '''grid'''. There is only one OpenMP parallel loop over the tiles, in '''WRFV3/phys/module_fr_sfire_driver.F'''. The rest of the SFIRE code executes on a single tile, starting from '''WRFV3/phys/module_fr_sfire_model.F''' Because the tiles need to access values from neighboring tiles at several points in the computation, within a single invocation of SFIRE, the parallel loop is executed several times to synchronize the data in memory at the exit from the loop. Each execution of the parallel loop performs a different stage of the computation.
* When SFIRE runs in distributed memory, the communication between the patches is done in includes in '''WRFV3/phys/module_fr_sfire_driver.F''' (search for HALO). This has no effect in the standalone code; in WRF, the includes are provided by the WRF parallel infrastructure, RSL-Lite. If you want to run SFIRE in MPI, you need to provide equivalent HALO includes yourself.
* SFIRE does not keep any state except scalar flags and fixed-size tables, set at initialization. All adjustable-sized arrays preserved beween calls are in '''grid'''.

==Required testing==

If you change anything in the files '''phys/module_fr_sfire_*.F''', you must test that the changes do not break WRF-Fire, otherwise your changes will not be maintainable.

* Build WRF-SFIRE with SM+DM parallelism with debugging, and test all 4 versions (serial, SM, DM, SM+DM) with the examples provided in '''test/em_fire''' and various numbers of processors. The results (the numerical values in the arrays the '''wrfrst''' files, not the files themselves) should be bit-identical to each other and identical to what they were before your changes. You can compare the files using the '''diffwrf''' utility, which is built as a part of the WRF compilation process, or start Matlab in '''test/em_fire''' (to set the path) and use the command '''ncdiff''' in Matlab.
* Build WRF-Fire with optimization and test on several platforms (at least gfortran).

==Web-based run system WRFX==
This system is available at http://github.com/openwfm. It consists of the following parts:
* [http://github.com/openwfm/wrfxpy wrfxpy] - Initiate and manage WRF-SFIRE simulations on a cluster. Automates data download, queuing and monitoring jobs, and postprocessing outputs into geolocated images. (Python). Intended to run on a head node of the cluster. Documentation is available at http://wrfxpy.readthedocs.io
* [http://github.com/openwfm/wrfxctrl wrfxctrl] - Map-based web interface to wrfxpy (Python and Javascript). Intended to run on a head node of the cluster. Runs its own web server.
* [http://github.com/openwfm/wrfxweb wrfxweb] - Map-based visualization server running on a remote server. The visualizations are also available as Google Earth KML files. (Browser-based Javascript, Python utilities) Designed to run on a small cloud machine.

==Works with==

* WRF-SFIRE master branch

[[Category:WRF-Fire]]
[[Category:Software]]

WRF-SFIRE

2025-10-22T15:03:17Z

Jmandel: /* Standalone code */ updated

{{users guide}}
[[Category:WRF-SFIRE]]
The fire code in WRF-SFIRE is called SFIRE (for Spread FIRE model). It is based on the [[wikipedia:Level set method|level set method]]. Since June 2011, we call the fire code SFIRE because of [[changes in WRF-Fire 3.3 release]]. The coupled code is called [[WRF]]-[[SFIRE]], and we reserve the designation [[WRF-Fire]] for the code in the WRF release.

==Standalone code==

SFIRE can be used independently without WRF for testing. To make comparison easier, it can run from the same inputs as WRF-Fire.

* See [[How to run the standalone fire model in WRF-Fire]].
* The build process in '''standalone''' uses the generated source code from the WRF file tree, namely the files '''phys/module_fr_sfire_*.f90''' except '''phys/module_fr_sfire_driver_wrf.f90'''. There is no code duplication. Instead of WRF, the fire code is linked with the '''*.F''' files in the '''standalone''' directory, which provide I/O and substitute the required subset of WRF functionality.

==Interface between WRF and SFIRE==

* The defined interface to SFIRE is between '''WRFV3/phys/module_fr_sfire_driver_wrf.F''' and subroutine '''sfire_driver_em''' in '''WRFV3/phys/module_fr_sfire_driver.F'''
* WRF calls '''sfire_driver_em''' once at initialization, and then (with slightly different arguments) in every time step.
* The arguments of '''sfire_driver_em''' consist of two structures (called derived types in Fortran), '''grid''', which contains all state, input, and output variables, and '''config_flags''', with all variables read from from file '''namelist.input''', and some array dimensions.
** The standalone code defines its own '''grid''' derived type with only the subset of the fields needed. All fields in '''grid''' are set in the standalone driver main file, '''standalone/model_test_main.F''', and nothing is hidden elsewhere.
** The standalone code replicates '''config_flags''' from WRF using include files named '''*.inc''' in the '''standalone''' directory. These include files are copies of the files generated by the WRF build process in '''WRFV3/inc'''. They are not soft links so that one can build the standalone code without building WRF. The '''inc''' files may need to be updated when the description of the configuration flags in the WRF registry changes.

==SFIRE architecture==

* SFIRE is compliant with [http://www.mmm.ucar.edu/wrf/WG2/WRF_conventions.html WRF coding conventions].
* WRF divides the horizontal domain into ''patches'' and divides the patches into ''tiles''. Each patch executes in one MPI process. Each tile is updated by one OpenMP thread.
* The SFIRE code is capable of parallel execution in shared memory. Division into tiles is controlled by fields in '''grid'''. There is only one OpenMP parallel loop over the tiles, in '''WRFV3/phys/module_fr_sfire_driver.F'''. The rest of the SFIRE code executes on a single tile, starting from '''WRFV3/phys/module_fr_sfire_model.F''' Because the tiles need to access values from neighboring tiles at several points in the computation, within a single invocation of SFIRE, the parallel loop is executed several times to synchronize the data in memory at the exit from the loop. Each execution of the parallel loop performs a different stage of the computation.
* When SFIRE runs in distributed memory, the communication between the patches is done in includes in '''WRFV3/phys/module_fr_sfire_driver.F''' (search for HALO). This has no effect in the standalone code; in WRF, the includes are provided by the WRF parallel infrastructure, RSL-Lite. If you want to run SFIRE in MPI, you need to provide equivalent HALO includes yourself.
* SFIRE does not keep any state except scalar flags and fixed-size tables, set at initialization. All adjustable-sized arrays preserved beween calls are in '''grid'''.

==Required testing==

If you change anything in the files '''WRFV3/phys/module_fr_sfire_*.F''', you must test that the changes do not break WRF-Fire, otherwise your changes will not be maintainable.

* Build WRF-Fire with SM+DM parallelism with debugging, and test all 4 versions (serial, SM, DM, SM+DM) with the examples provided in '''WRFV3/test/em_fire''' and various numbers of processors. The results (the numerical values in the arrays the '''wrfrst''' files, not the files themselves) must be bit-identical to each other and identical to what they were before your changes. You can compare the files using the '''diffwrf''' utility, which is built as a part of the WRF compilation process, or start Matlab in '''WRFV3/test/em_fire''' (to set the path) and use the command '''ncdiff''' in Matlab.
* Build WRF-Fire with optimization and test on several platforms (at least gfortran and PGI).

==Web-based run system WRFX==
This system is available at http://github.com/openwfm. It consists of the following parts:
* [http://github.com/openwfm/wrfxpy wrfxpy] - Initiate and manage WRF-SFIRE simulations on a cluster. Automates data download, queuing and monitoring jobs, and postprocessing outputs into geolocated images. (Python). Intended to run on a head node of the cluster. Documentation is available at http://wrfxpy.readthedocs.io
* [http://github.com/openwfm/wrfxctrl wrfxctrl] - Map-based web interface to wrfxpy (Python and Javascript). Intended to run on a head node of the cluster. Runs its own web server.
* [http://github.com/openwfm/wrfxweb wrfxweb] - Map-based visualization server running on a remote server. The visualizations are also available as Google Earth KML files. (Browser-based Javascript, Python utilities) Designed to run on a small cloud machine.

==Works with==

* WRF-SFIRE master branch

[[Category:WRF-Fire]]
[[Category:Software]]

Template:WRF-SFIRE-commit

2025-10-22T14:56:58Z

Jmandel: Created page with "[http://github.com/openwfm/WRF-SFIRE/commit/{{{1}}} commit {{{1}}}]"

[http://github.com/openwfm/WRF-SFIRE/commit/{{{1}}} commit {{{1}}}]

Template:WRF-SFIRE-branch

2025-10-22T14:49:40Z

Jmandel:

[http://github.com/openwfm/WRF-SFIRE/commits/{{{1}}} WRF-SFIRE branch {{{1}}}]

How to run the standalone fire model in WRF-SFIRE

2025-10-22T14:48:17Z

Jmandel: /* Works with */ update to Centos 8

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build WRF-SFIRE software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link the created '''wrfout''' file to '''fire_input.nc''': '''ln -s wrfout... fire_iput.nc'''

* Wait for wrf.exe to finish.

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-SFIRE-branch|develop-3}} {{WRF-SFIRE-commit|f66267250bdedbf2d866dbd132d7cae8897f9e7c|Oct 22 2025}}
* Tested with GNU Fortran (GCC) 9.2.1 on Centos 8.3, libnetcdf 15.0.1, libnetcdff 7.0.0

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

Template:WRF-SFIRE-branch

2025-10-22T14:40:37Z

Jmandel: Created page with "[http://github.com/openwfm/WRF-SFIRE/commits/{{{1}}} branch {{{1}}}]"

[http://github.com/openwfm/WRF-SFIRE/commits/{{{1}}} branch {{{1}}}]

How to run the standalone fire model in WRF-SFIRE

2025-10-22T09:02:19Z

Jmandel: /* Running the software */ adding wait for wrf.exe to finish

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build WRF-SFIRE software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link the created '''wrfout''' file to '''fire_input.nc''': '''ln -s wrfout... fire_iput.nc'''

* Wait for wrf.exe to finish.

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-Fire-branch|jm2/devel}} {{WRF-Fire-commit|168fbfaa8a62061b51999001dc55162e2ac3a798|Oct 28 2011}}
* Tested with gfortran 4.4.4 and pgf90 11.9 on Linux, and gfortran 4.3.3 on OSX (from [http://www.macports.org/ MacPorts]).

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

How to run the standalone fire model in WRF-SFIRE

2025-10-22T00:22:14Z

Jmandel: /* Building the software */ WRF-SFIRE

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build WRF-SFIRE software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link or rename the created '''wrfout''' file to '''fire_input.nc'''

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-Fire-branch|jm2/devel}} {{WRF-Fire-commit|168fbfaa8a62061b51999001dc55162e2ac3a798|Oct 28 2011}}
* Tested with gfortran 4.4.4 and pgf90 11.9 on Linux, and gfortran 4.3.3 on OSX (from [http://www.macports.org/ MacPorts]).

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

How to run the standalone fire model in WRF-SFIRE

2025-10-21T23:24:58Z

Jmandel: /* Running the software */ update to SFIRE

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build the coupled WRF fire software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''test/em_sfire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link or rename the created '''wrfout''' file to '''fire_input.nc'''

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-Fire-branch|jm2/devel}} {{WRF-Fire-commit|168fbfaa8a62061b51999001dc55162e2ac3a798|Oct 28 2011}}
* Tested with gfortran 4.4.4 and pgf90 11.9 on Linux, and gfortran 4.3.3 on OSX (from [http://www.macports.org/ MacPorts]).

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

How to run the standalone fire model in WRF-SFIRE

2025-10-21T04:56:14Z

Jmandel: UNDER CONSTRUCTION

{{users guide}}

'''UNDER CONSTRUCTION'''

The fire code in WRF-SFIRE, called SFIRE (for Spread FIRE model), can be used independently without WRF, using only one-way atmosphere-fire coupling. WRF needs to run to create the atmospheric forcing first.

==Step by step instructions==

===Building the software===
* [[How to get WRF-Fire|Download and build the coupled WRF fire software]] to create '''wrf.exe''' and leave the '''NETCDF''' environment variable set.

* Change to the '''standalone''' directory.

* Find a suitable '''make.inc.*''' file and soft-link it to '''make.inc''', for example '''ln -s make.inc.gfortran make.inc''' and type '''make'''

===Running the software===

* Navigate to a directory with your example (such as '''WRFV3/test/em_fire/hill'''). Make sure '''namelist.input''' specifies a short '''history_interval_s''' (these will be the atmosphere states used by the fire model) and set large '''frames_per_outfile''' so that only one '''wrfout''' file is created.

* Set up the problem by either '''ideal.exe''' or '''real.exe''' and run '''wrf.exe''' as usual.

* Link or rename the created '''wrfout''' file to '''fire_input.nc'''

* Run '''fire.exe''' in the same directory. This will create the file '''fire_output.nc''' with the results.

==How it works==

* The standalone model '''fire.exe''' reads the fire model inputs from the '''wrfout''', including interpolated wind fields '''UF''' and '''VF'''. Because the first frame in '''wrfout''' is created before the fire model is called and so those fields are not set yet, the fire model starts from the second frame. The atmosphere fields are interpolated linearly in time between the frames before they are passed to the fire model.

* The file '''fire_output.nc''' has the same format as '''wrfout''' but it contains only the variables that are the fire model outputs and some other fields copied from '''wrfout''', which are needed for visualization and interpreting the results. These include coordinates of the fire nodes in '''FXLONG''' and '''FXLAT''', the time string '''Times''', and the terrain height '''ZSF'''.

* The standalone model build compiles the fire model files from the '''WRFV3/phys''' directory, so if the fire model changes, the standalone model may have to be updated. However, the standalone model does not depend on WRF directly. The code consists of 3 files:
** '''fire.F''' is the standalone model driver
** '''wrf_netcdf.F''' reads and writes {{wp|NetCDF|NetCDF}} files compatible with WRF
** '''wrf_fakes.F''' implements a very limited subset of WRF routines to avoid dependency

*The files '''config_assigns.inc''' '''namelist_defaults.inc''' '''namelist_defines2.inc''' '''namelist_defines.inc''' '''namelist_statements.inc''' files are copied from WRF build to maintain compatibility with '''namelist.input''' in WRF. When the WRF registry changes, these files will need to be updated manually from the directory '''WRFV3/inc''' after WRF is built and committed again.

==Remarks==

* The results of the coupled model and the standalone model will not be identical, even if the coupled model runs the same fire, because the wind fields are interpolated between the frames for the standalone model. But the results should be close.

* To simulate different fires in the standalone model, the coupled model should run without ignition. Then the coupled model will create the fire model inputs, but the atmosphere state will not be disturbed by the fire in the coupled model.

* The '''&fire''' section in '''namelist.input''' can change, and the fuel data including '''namelist.fire''' may also change.

* At the moment, '''fire.exe''' is serial only.

==Works with==

* {{WRF-Fire-branch|jm2/devel}} {{WRF-Fire-commit|168fbfaa8a62061b51999001dc55162e2ac3a798|Oct 28 2011}}
* Tested with gfortran 4.4.4 and pgf90 11.9 on Linux, and gfortran 4.3.3 on OSX (from [http://www.macports.org/ MacPorts]).

==See also==

* [[SFIRE|Fire model interface and standalone code description]]
* [[SFIRE variables]]

[[Category:WRF-Fire]]
[[Category:Howtos|Run the standalone fire model in WRF-Fire]]

Satellite Fire Data Products

2025-08-27T13:10:01Z

Jmandel:

[[Category:Data]]

== Satellite Fire Data Products ==

This page summarizes the main satellite fire data products from MODIS, VIIRS, and GOES, with focus on Level 2 Active Fires. The goal is practical: to understand what the data contain, how they are structured, and how to use them.

=== Processing Levels ===

* Level 1 (L1B): Calibrated, geolocated radiances at native resolution.
* Level 2 (L2): Derived geophysical variables at the same resolution as L1 (e.g., fire masks, Fire Radiative Power).
* Level 3 (L3): Gridded or time-composited variables on standard grids (e.g., daily fire counts per 0.25° cell).

=== Key Geometry Terms ===

* Swath: The cross-track stripe observed as the sensor scans.
* Granule: The basic time chunk of data (e.g., 5–6 minutes for polar orbiters; 1–10 minutes for GOES sectors).
* Pixel: One sample from the sensor. Pixel size depends on instrument and grows off-nadir. VIIRS mitigates this with aggregation and "bow-tie deletion."

=== MODIS Active Fires (Terra and Aqua) ===

* Satellites: Terra (morning ~10:30, drifting earlier), Aqua (afternoon \~13:30).
* Orbit: Sun-synchronous near-polar, ~705 km altitude.
* Swath and granules: 2330 km wide swath, ~5 min granules.
* Resolution: 1 km at nadir, coarser off-nadir.
* Products: MOD14 (Terra), MYD14 (Aqua).
* Fields: Fire mask (low/nominal/high confidence), confidence 0–100%, FRP (MW), brightness temperatures, view geometry.
* Revisit: Two daily looks at mid-latitudes from both satellites combined.

=== VIIRS Active Fires (S-NPP, NOAA-20, NOAA-21) ===

* Satellites: Three polar orbiters in the JPSS constellation.
* Orbit: ~824 km altitude, ~13:30 LT ascending node.
* Swath and granules: 3060 km swath, 6 min granules.
* Resolution: 375 m (I-band), 750 m (M-band).
* Products: VNP14IMG (S-NPP), VJ114IMG (NOAA-20), VJ214IMG (NOAA-21).
* Fields: Fire mask, confidence %, FRP (MW), brightness temps, geometry.
* Revisit: Multiple looks/day, with ~25–50 min spacing between satellites. Both day (~13:30) and night (~01:30) coverage.

=== GOES ABI Fire/Hot Spot Products ===

* Satellites: GOES-East (GOES-19), GOES-West (GOES-18).
* Orbit: Geostationary at ~35,786 km.
* Resolution: 2 km at nadir for IR band 7 (3.9 µm).
* Cadence: 10 min full disk, 5 min CONUS, 1 min mesoscale.
* Product: Fire/Hot Spot Characterization (FHS/FDC).
* Fields: Fire mask codes (10/30 high confidence, 11/31 saturated, 12/32 cloud-contaminated, 13–15/33–35 lower probabilities), FRP (MW).
* Notes: Use mask codes 10,11,30,31 for conservative detection. Pixel locations not terrain-corrected, so offsets over mountains occur.

=== Complementarity ===

* MODIS: Coarser (1 km) but long record since 2000; provides morning and afternoon views.
* VIIRS: Finer (375 m), more frequent coverage with three satellites.
* GOES: Coarser (2 km) but provides rapid updates (1–10 min), enabling near-real-time fire behavior monitoring.

=== Practical Usage Tips ===

* Filter by confidence: MODIS/VIIRS high-confidence or ≥80%; GOES codes 10,11,30,31.
* Account for off-nadir pixel growth and location errors.
* Match granule timing to incident timelines (5 min MODIS, 6 min VIIRS, 1–10 min GOES).
* FRP is in MW per pixel, but uncertainty varies (higher for GOES lower-confidence classes).

=== References ===

* MODIS Active Fire Product (Collection 6.1): [https://lpdaac.usgs.gov/products/mod14v061/](https://lpdaac.usgs.gov/products/mod14v061/)
* VIIRS 375 m Active Fire Product: [https://lpdaac.usgs.gov/products/vnp14imgv001/](https://lpdaac.usgs.gov/products/vnp14imgv001/)
* VIIRS Algorithm Theoretical Basis Document: [https://lpdaac.usgs.gov/documents/197/VNP14\_User\_Guide\_V1.pdf](https://lpdaac.usgs.gov/documents/197/VNP14_User_Guide_V1.pdf)
* GOES ABI Fire/Hot Spot Characterization: [https://www.ospo.noaa.gov/Products/atmosphere/fire/](https://www.ospo.noaa.gov/Products/atmosphere/fire/)
* NASA EOSDIS Data Processing Levels: [https://earthdata.nasa.gov/faq/data-processing-levels](https://earthdata.nasa.gov/faq/data-processing-levels)

Satellite Fire Data Products

2025-08-27T05:53:13Z

Jmandel: markup

== Satellite Fire Data Products ==

This page summarizes the main satellite fire data products from MODIS, VIIRS, and GOES, with focus on Level 2 Active Fires. The goal is practical: to understand what the data contain, how they are structured, and how to use them.

=== Processing Levels ===

* Level 1 (L1B): Calibrated, geolocated radiances at native resolution.
* Level 2 (L2): Derived geophysical variables at the same resolution as L1 (e.g., fire masks, Fire Radiative Power).
* Level 3 (L3): Gridded or time-composited variables on standard grids (e.g., daily fire counts per 0.25° cell).

=== Key Geometry Terms ===

* Swath: The cross-track stripe observed as the sensor scans.
* Granule: The basic time chunk of data (e.g., 5–6 minutes for polar orbiters; 1–10 minutes for GOES sectors).
* Pixel: One sample from the sensor. Pixel size depends on instrument and grows off-nadir. VIIRS mitigates this with aggregation and "bow-tie deletion."

=== MODIS Active Fires (Terra and Aqua) ===

* Satellites: Terra (morning ~10:30, drifting earlier), Aqua (afternoon \~13:30).
* Orbit: Sun-synchronous near-polar, ~705 km altitude.
* Swath and granules: 2330 km wide swath, ~5 min granules.
* Resolution: 1 km at nadir, coarser off-nadir.
* Products: MOD14 (Terra), MYD14 (Aqua).
* Fields: Fire mask (low/nominal/high confidence), confidence 0–100%, FRP (MW), brightness temperatures, view geometry.
* Revisit: Two daily looks at mid-latitudes from both satellites combined.

=== VIIRS Active Fires (S-NPP, NOAA-20, NOAA-21) ===

* Satellites: Three polar orbiters in the JPSS constellation.
* Orbit: ~824 km altitude, ~13:30 LT ascending node.
* Swath and granules: 3060 km swath, 6 min granules.
* Resolution: 375 m (I-band), 750 m (M-band).
* Products: VNP14IMG (S-NPP), VJ114IMG (NOAA-20), VJ214IMG (NOAA-21).
* Fields: Fire mask, confidence %, FRP (MW), brightness temps, geometry.
* Revisit: Multiple looks/day, with ~25–50 min spacing between satellites. Both day (~13:30) and night (~01:30) coverage.

=== GOES ABI Fire/Hot Spot Products ===

* Satellites: GOES-East (GOES-19), GOES-West (GOES-18).
* Orbit: Geostationary at ~35,786 km.
* Resolution: 2 km at nadir for IR band 7 (3.9 µm).
* Cadence: 10 min full disk, 5 min CONUS, 1 min mesoscale.
* Product: Fire/Hot Spot Characterization (FHS/FDC).
* Fields: Fire mask codes (10/30 high confidence, 11/31 saturated, 12/32 cloud-contaminated, 13–15/33–35 lower probabilities), FRP (MW).
* Notes: Use mask codes 10,11,30,31 for conservative detection. Pixel locations not terrain-corrected, so offsets over mountains occur.

=== Complementarity ===

* MODIS: Coarser (1 km) but long record since 2000; provides morning and afternoon views.
* VIIRS: Finer (375 m), more frequent coverage with three satellites.
* GOES: Coarser (2 km) but provides rapid updates (1–10 min), enabling near-real-time fire behavior monitoring.

=== Practical Usage Tips ===

* Filter by confidence: MODIS/VIIRS high-confidence or ≥80%; GOES codes 10,11,30,31.
* Account for off-nadir pixel growth and location errors.
* Match granule timing to incident timelines (5 min MODIS, 6 min VIIRS, 1–10 min GOES).
* FRP is in MW per pixel, but uncertainty varies (higher for GOES lower-confidence classes).

=== References ===

* MODIS Active Fire Product (Collection 6.1): [https://lpdaac.usgs.gov/products/mod14v061/](https://lpdaac.usgs.gov/products/mod14v061/)
* VIIRS 375 m Active Fire Product: [https://lpdaac.usgs.gov/products/vnp14imgv001/](https://lpdaac.usgs.gov/products/vnp14imgv001/)
* VIIRS Algorithm Theoretical Basis Document: [https://lpdaac.usgs.gov/documents/197/VNP14\_User\_Guide\_V1.pdf](https://lpdaac.usgs.gov/documents/197/VNP14_User_Guide_V1.pdf)
* GOES ABI Fire/Hot Spot Characterization: [https://www.ospo.noaa.gov/Products/atmosphere/fire/](https://www.ospo.noaa.gov/Products/atmosphere/fire/)
* NASA EOSDIS Data Processing Levels: [https://earthdata.nasa.gov/faq/data-processing-levels](https://earthdata.nasa.gov/faq/data-processing-levels)

Satellite Fire Data Products

2025-08-27T05:51:20Z

Jmandel: rm md **

== Satellite Fire Data Products ==

This page summarizes the main satellite fire data products from MODIS, VIIRS, and GOES, with focus on Level 2 Active Fires. The goal is practical: to understand what the data contain, how they are structured, and how to use them.

=== Processing Levels ===

* Level 1 (L1B): Calibrated, geolocated radiances at native resolution.
* Level 2 (L2): Derived geophysical variables at the same resolution as L1 (e.g., fire masks, Fire Radiative Power).
* Level 3 (L3): Gridded or time-composited variables on standard grids (e.g., daily fire counts per 0.25° cell).

=== Key Geometry Terms ===

* Swath: The cross-track stripe observed as the sensor scans.
* Granule: The basic time chunk of data (e.g., 5–6 minutes for polar orbiters; 1–10 minutes for GOES sectors).
* Pixel: One sample from the sensor. Pixel size depends on instrument and grows off-nadir. VIIRS mitigates this with aggregation and "bow-tie deletion."

=== MODIS Active Fires (Terra and Aqua) ===

* Satellites: Terra (morning \~10:30, drifting earlier), Aqua (afternoon \~13:30).
* Orbit: Sun-synchronous near-polar, \~705 km altitude.
* Swath and granules: 2330 km wide swath, \~5 min granules.
* Resolution: 1 km at nadir, coarser off-nadir.
* Products: MOD14 (Terra), MYD14 (Aqua).
* Fields: Fire mask (low/nominal/high confidence), confidence 0–100%, FRP (MW), brightness temperatures, view geometry.
* Revisit: Two daily looks at mid-latitudes from both satellites combined.

=== VIIRS Active Fires (S-NPP, NOAA-20, NOAA-21) ===

* Satellites: Three polar orbiters in the JPSS constellation.
* Orbit: \~824 km altitude, \~13:30 LT ascending node.
* Swath and granules: 3060 km swath, 6 min granules.
* Resolution: 375 m (I-band), 750 m (M-band).
* Products: VNP14IMG (S-NPP), VJ114IMG (NOAA-20), VJ214IMG (NOAA-21).
* Fields: Fire mask, confidence %, FRP (MW), brightness temps, geometry.
* Revisit: Multiple looks/day, with \~25–50 min spacing between satellites. Both day (\~13:30) and night (\~01:30) coverage.

=== GOES ABI Fire/Hot Spot Products ===

* Satellites: GOES-East (GOES-19), GOES-West (GOES-18).
* Orbit: Geostationary at \~35,786 km.
* Resolution: 2 km at nadir for IR band 7 (3.9 µm).
* Cadence: 10 min full disk, 5 min CONUS, 1 min mesoscale.
* Product: Fire/Hot Spot Characterization (FHS/FDC).
* Fields: Fire mask codes (10/30 high confidence, 11/31 saturated, 12/32 cloud-contaminated, 13–15/33–35 lower probabilities), FRP (MW).
* Notes: Use mask codes 10,11,30,31 for conservative detection. Pixel locations not terrain-corrected, so offsets over mountains occur.

=== Complementarity ===

* MODIS: Coarser (1 km) but long record since 2000; provides morning and afternoon views.
* VIIRS: Finer (375 m), more frequent coverage with three satellites.
* GOES: Coarser (2 km) but provides rapid updates (1–10 min), enabling near-real-time fire behavior monitoring.

=== Practical Usage Tips ===

* Filter by confidence: MODIS/VIIRS high-confidence or ≥80%; GOES codes 10,11,30,31.
* Account for off-nadir pixel growth and location errors.
* Match granule timing to incident timelines (5 min MODIS, 6 min VIIRS, 1–10 min GOES).
* FRP is in MW per pixel, but uncertainty varies (higher for GOES lower-confidence classes).

=== References ===

* MODIS Active Fire Product (Collection 6.1): [https://lpdaac.usgs.gov/products/mod14v061/](https://lpdaac.usgs.gov/products/mod14v061/)
* VIIRS 375 m Active Fire Product: [https://lpdaac.usgs.gov/products/vnp14imgv001/](https://lpdaac.usgs.gov/products/vnp14imgv001/)
* VIIRS Algorithm Theoretical Basis Document: [https://lpdaac.usgs.gov/documents/197/VNP14\_User\_Guide\_V1.pdf](https://lpdaac.usgs.gov/documents/197/VNP14_User_Guide_V1.pdf)
* GOES ABI Fire/Hot Spot Characterization: [https://www.ospo.noaa.gov/Products/atmosphere/fire/](https://www.ospo.noaa.gov/Products/atmosphere/fire/)
* NASA EOSDIS Data Processing Levels: [https://earthdata.nasa.gov/faq/data-processing-levels](https://earthdata.nasa.gov/faq/data-processing-levels)

Satellite Fire Data Products

2025-08-27T01:42:28Z

Jmandel: from ChatGPT 5. Prompt: Provide a technical explanation of fire data products from satellites, particularly MODIS, VIIRS, GOES, with focus on Level 2 Active Fires data, concept of swath, granules, pixels, their numerical values, revisits, orbit design. Summarize differences between Level 1, 2 and 3 data. Approach: practical, for someone who needs to use and understand the data. Provide original references with links. Provide as a file for a simple wikimedia instal.

== Satellite Fire Data Products ==

This page summarizes the main satellite fire data products from MODIS, VIIRS, and GOES, with focus on Level 2 Active Fires. The goal is practical: to understand what the data contain, how they are structured, and how to use them.

=== Processing Levels ===

* **Level 1 (L1B)**: Calibrated, geolocated radiances at native resolution.
* **Level 2 (L2)**: Derived geophysical variables at the same resolution as L1 (e.g., fire masks, Fire Radiative Power).
* **Level 3 (L3)**: Gridded or time-composited variables on standard grids (e.g., daily fire counts per 0.25° cell).

=== Key Geometry Terms ===

* **Swath**: The cross-track stripe observed as the sensor scans.
* **Granule**: The basic time chunk of data (e.g., 5–6 minutes for polar orbiters; 1–10 minutes for GOES sectors).
* **Pixel**: One sample from the sensor. Pixel size depends on instrument and grows off-nadir. VIIRS mitigates this with aggregation and "bow-tie deletion."

=== MODIS Active Fires (Terra and Aqua) ===

* **Satellites**: Terra (morning \~10:30, drifting earlier), Aqua (afternoon \~13:30).
* **Orbit**: Sun-synchronous near-polar, \~705 km altitude.
* **Swath and granules**: 2330 km wide swath, \~5 min granules.
* **Resolution**: 1 km at nadir, coarser off-nadir.
* **Products**: MOD14 (Terra), MYD14 (Aqua).
* **Fields**: Fire mask (low/nominal/high confidence), confidence 0–100%, FRP (MW), brightness temperatures, view geometry.
* **Revisit**: Two daily looks at mid-latitudes from both satellites combined.

=== VIIRS Active Fires (S-NPP, NOAA-20, NOAA-21) ===

* **Satellites**: Three polar orbiters in the JPSS constellation.
* **Orbit**: \~824 km altitude, \~13:30 LT ascending node.
* **Swath and granules**: 3060 km swath, 6 min granules.
* **Resolution**: 375 m (I-band), 750 m (M-band).
* **Products**: VNP14IMG (S-NPP), VJ114IMG (NOAA-20), VJ214IMG (NOAA-21).
* **Fields**: Fire mask, confidence %, FRP (MW), brightness temps, geometry.
* **Revisit**: Multiple looks/day, with \~25–50 min spacing between satellites. Both day (\~13:30) and night (\~01:30) coverage.

=== GOES ABI Fire/Hot Spot Products ===

* **Satellites**: GOES-East (GOES-19), GOES-West (GOES-18).
* **Orbit**: Geostationary at \~35,786 km.
* **Resolution**: 2 km at nadir for IR band 7 (3.9 µm).
* **Cadence**: 10 min full disk, 5 min CONUS, 1 min mesoscale.
* **Product**: Fire/Hot Spot Characterization (FHS/FDC).
* **Fields**: Fire mask codes (10/30 high confidence, 11/31 saturated, 12/32 cloud-contaminated, 13–15/33–35 lower probabilities), FRP (MW).
* **Notes**: Use mask codes 10,11,30,31 for conservative detection. Pixel locations not terrain-corrected, so offsets over mountains occur.

=== Complementarity ===

* **MODIS**: Coarser (1 km) but long record since 2000; provides morning and afternoon views.
* **VIIRS**: Finer (375 m), more frequent coverage with three satellites.
* **GOES**: Coarser (2 km) but provides rapid updates (1–10 min), enabling near-real-time fire behavior monitoring.

=== Practical Usage Tips ===

* Filter by confidence: MODIS/VIIRS high-confidence or ≥80%; GOES codes 10,11,30,31.
* Account for off-nadir pixel growth and location errors.
* Match granule timing to incident timelines (5 min MODIS, 6 min VIIRS, 1–10 min GOES).
* FRP is in MW per pixel, but uncertainty varies (higher for GOES lower-confidence classes).

=== References ===

* MODIS Active Fire Product (Collection 6.1): [https://lpdaac.usgs.gov/products/mod14v061/](https://lpdaac.usgs.gov/products/mod14v061/)
* VIIRS 375 m Active Fire Product: [https://lpdaac.usgs.gov/products/vnp14imgv001/](https://lpdaac.usgs.gov/products/vnp14imgv001/)
* VIIRS Algorithm Theoretical Basis Document: [https://lpdaac.usgs.gov/documents/197/VNP14\_User\_Guide\_V1.pdf](https://lpdaac.usgs.gov/documents/197/VNP14_User_Guide_V1.pdf)
* GOES ABI Fire/Hot Spot Characterization: [https://www.ospo.noaa.gov/Products/atmosphere/fire/](https://www.ospo.noaa.gov/Products/atmosphere/fire/)
* NASA EOSDIS Data Processing Levels: [https://earthdata.nasa.gov/faq/data-processing-levels](https://earthdata.nasa.gov/faq/data-processing-levels)

Contact

2025-08-09T22:34:17Z

Jmandel: updated

[[File:Jan_th.jpg|left|caption]]
'''Jan Mandel''' 
Professor Emeritus | Research Professor | HPC System Administrator />
Department of Mathematical Sciences 
University of Colorado Denver

[mailto:Jan.Mandel@gmail.com Jan.Mandel@gmail.com]
[mailto:Jan.Mandel@ucdenver.edu Jan.Mandel@ucdenver.edu]

[[Category:Contents]]

MediaWiki:Vector-2022.css

2025-08-07T17:59:01Z

Jmandel: 97.5

/* Static contained banner above content */
body.skin-vector-2022 .mw-page-container::before {
content: "";
display: block;
width: 100%;
height: 97.5px; /* or adjust as needed */
background: url("/images/c/cb/Openwfm.png") no-repeat center center;
background-size: contain;
background-color: #fff; /* optional, ensures clean base */
margin-bottom: -2em;
margin-top: -1em;
}

MediaWiki:Vector-2022.css

2025-08-07T17:58:27Z

Jmandel: 98

/* Static contained banner above content */
body.skin-vector-2022 .mw-page-container::before {
content: "";
display: block;
width: 100%;
height: 98px; /* or adjust as needed */
background: url("/images/c/cb/Openwfm.png") no-repeat center center;
background-size: contain;
background-color: #fff; /* optional, ensures clean base */
margin-bottom: -2em;
margin-top: -1em;
}

MediaWiki:Vector-2022.css

2025-08-07T17:57:20Z

Jmandel: Now too small, changing to height: 97pt, To flush page cache on Firefox: shift-command-R, on Safari shift-reload in url window.

/* Static contained banner above content */
body.skin-vector-2022 .mw-page-container::before {
content: "";
display: block;
width: 100%;
height: 97px; /* or adjust as needed */
background: url("/images/c/cb/Openwfm.png") no-repeat center center;
background-size: contain;
background-color: #fff; /* optional, ensures clean base */
margin-bottom: -2em;
margin-top: -1em;
}