Coupling with WRF-Chem

As of WRF 3.4, WRF-Chem is now included in the SFire repository. Work into coupling SFire with WRF-Chem is ongoing. See branch chem. As of April 21, 2012, a working template has been implemented to inject a tracer into the atmosphere. This implementation seems to work as expected.

SFire smoke tracer in action. See File:Smoke small.avi.

Compiling with chem support

Compiling the code with support for WRF-Chem is similar to the standard procedure. You must set an environment variable WRF_CHEM and configure with the argument chem as follows.

export WRF_CHEM=1
./configure chem
./compile em_fire

Running an idealized example

An idealized example based on the hill case has been created in test/em_fire/chem. This example doesn't quite work out of the box because WRF-Chem requires USGS landuse data that the ideal case doesn't initialize. To get this example working, you have to trick WRF into thinking that the input file contains USGS landuse data. (I'm not sure if this data is even used when just using passive tracers anyway.) To do this, you can just change the global attribute MMINLU in wrfinput_d01 to the string "USGS". A python script (make_usgs.py) that does this is included in the test/em_fire/chem directory, but it requires netcdf4-python to run. Assuming you have this module, the following will execute the example.

./ideal.exe
./make_usgs.py
./wrf.exe

The tracer will appear as an atmospheric variable in the output file with the name smoke.

Development notes

As of April 21, 2012, the tracer is simply copied from the heat flux at the surface on the atmospheric mesh (GRNHFX). A call to fire_emission has been added to module_fr_sfire_driver_wrf.F 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 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 several large arrays called *_emis, chem, and tracer. These arrays are four dimensional indexed like (x,z,y,s), where s is the chemical species. The chem and tracer arrays are located on the standard atmospheric grid, while the *_emis arrays have an alternate vertical grid indexed to config%kemit. An internal table keeps track of where each species is stored in these arrays. The domain structure contains scalars such as p_smoke and p_e_so4 that give the species index for each type. The species quantities are specific to different chemistry options (chem_opt) 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 tracer_opt. This controls what tracers are generated for Chem. For example, trace_opt = 1 creates a single tracer called smoke, see the registry for package definitions.

For the passive tracer scheme (chem_opt = 14), 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 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.