Talk:WRF-Fire development notes

Bubble

• Remove (by default) the warm perturbation (bubble) from atmospheric initializations in idealized cases.
• Modify the code and add namelist variables allowing for ingesting the cold/warm perturbation of a specified size (for people interested in fire propagation in downburst/convective environments).

Adamko 17:22, 12 February 2010 (UTC)

Proposed input of additional data in ideal run

• Single topography for both the atmosphere and the fire models - from an arbitrary uniform mesh aligned with coordinate axes
• Fuel data for the fire model - at the centers of the fire mesh
• Surface data for WRF - see e.g. /dyn_em/module_initialize_seabreeze2d_x.F around call ns_set_iswater, at centers of the atmosphere mesh ("mass points")

The input will be done similarly as in dyn_em/module_initialize_b_wave.F per suggestion of the WRF developers. See subroutine read_input_jet.

This is as far as I want to go in ideal.exe, more complicated data input should be done through real.exe.

Jmandel 01:29, 1 February 2010 (UTC)

Agreed. No reason to reinvent the wheel here.

Jbeezley 02:41, 8 February 2010 (UTC)

Proposed computation of smooth terrain gradient

Currently the terrain height zsf is given at the centers of the fire grid cells. The terrain gradient is then computed in Fire by central differences, and this is the gradient that enters in the Rothermel's formula. When the terrain height is interpolated from coarser data (by bilinear interpolation), the gradient is discontinuous at the fire mesh scale, which causes jumps in fire propagation. Instead, I propose:

1. The gradient components will be computed on a staggered grid directly from the data, on the mesh where the data is given. That is, the x-component of the gradient will be computed at midpoints in the x-direction between the data points by central differencing, and similarly the y-component of the gradient will be computed at midpoints the y-direction between the data points.
2. The two components of the gradient will be interpolated to the centers of the fire grid nodes by bilinear interpolation
3. Terrain height for the atmospheric model will be computed by bilinear interpolation from the data

The staggered mesh where the gradient is computed in 1. is reminiscent of the staggered mesh WRF uses for the wind; in fact, the interpolation in 2. is exactly the same that I already use for the interpolation of the wind to the fire mesh. This should result in

1. Gradient as accurate as the resolution of the topography data allows, without an unnecessary loss of accuracy
2. Continous gradient, without any jumps
3. No artificial smoothing needed

The terrain height data can/should be given in its native resolution, unrelated to the any model mesh sizes. This will be easy to handle when terrain data is loaded from a file in an ideal run. In a real run, it might be more appropriate to do this computation in WPS. Jmandel 00:48, 8 February 2010 (UTC)

I'm not sure that what you propose will actually eliminate the need for artificial smoothing. From what I have read, the data itself can be quite noisy with errors on the order of the horizontal resolution or more. WPS already handles these issues at the atmospheric grid level; it may be best to keep the computations there. What about:

1. For ideal, the fire grid topography is read in just like the fuel category field (already processed to the fire grid). The user can do the smoothing and interpolation. Ideal will compute the gradients from this directly and populate the slope field.
2. For real, the interpolation, smoothing, and gradient is computed with WPS. This is a trivial addition, nothing more than a few lines in a runtime parameter file. We would just need to modify the registry to mark the fire resolution slope field as input and restart. The fire code in wrf.exe would procede assuming that these fields are already populated.

One complication for this would be that the gradients would be specified on cell centered grid. WRF and WPS have no concept of staggering on the fire grid.

Jbeezley 02:41, 8 February 2010 (UTC)

It would eliminate the need for artificial smoothing to get rid of the blockiness caused by coarse topography resolution, but of course the input of the altitude would be much simpler for me... and it would let the user deal with the smoothing issues. Terrain gradients from WPS at centers of the cells is precisely what is needed, thanks. No need for any staggered grid there. Jmandel 23:51, 8 February 2010 (UTC)

Saved explanation, removed from the wish list: This will allow the gradient to be smoothly interpolated in preprocessing in the WPS or in setting up ideal cases. No artificial terrain smoothing is needed. The current scheme interpolates terrain height linearly, and if the mesh the terrain is interpolated from is much coarser than the fire mesh, this results in gradient jumps along the terrain mesh lines. Then, the fire spread rate jumps along the terrain mesh lines. Jmandel 20:48, 13 June 2010 (UTC)

Standalone driver

This is how WRF-Fire was originally developed. The driver was phys/model_test_main.F until deleted in November 2008. The last commit with the driver working might be this. It should be resurrected now after the long argument lists are cleaned up. What would the driver do for inputs and outputs? NetCDF? Jmandel 04:39, 30 May 2010 (UTC)

I think NetCDF would be best. In fact, I think we should maintain some sort of compatibility between these and WRF output files. This way, we can use existing visualization/data assimilation code. All this really requires is naming the variables and dimensions the same. Jbeezley 07:55, 30 May 2010 (UTC)

Re this edit: Why would a standalone driver be for diagnostics only? Of course diagnostics would be the main purpose for us, but many models, such as FARSITE, do not interface with atmosphere either. If we can run from the same data, it would be interesting to compare. I suppose this could be still called diagnostics, though. Jmandel 16:37, 5 June 2010 (UTC)

Gradual ignition

The current scheme requires that the ignition area is several fire mesh steps large. When such area ignites all at once, all the heat is output to the atmosphere at once, instead of being output gradually and allowing ground layer circulation to develop over time.

• Very fine fire mesh simulation first to identify if there actually is a problem.

Jmandel 19:06, 2 June 2010 (UTC)

Kara Yedinak has asked some questions about ignition in this thread involving virtual ignition and Gaussian sources. I do not think I have done anything about it yet and I do not quite understand the issue (Gaussian sources of what? Heat output into the atmosphere?) Maybe this could be merged with/replace/clarify the gradual ignition. I have edited the line for Kara in WRF-Fire#Contributors to replace "exposed bugs contributing to a better fire initialization" by "suggestions for improvements". In any case I do not think I have made any such improvements yet. The above thread was all I could find now about the issue. Janice, if there were in fact some bugs and I forgot to do anything about them I'd like to know please. Jmandel 16:19, 5 June 2010 (UTC)

Ugly includes

Archived from the wish list: Remove the ugly includes in the argument lists to get the coefficients down the call chain to the spread rate calculations. Pass the coefficients by pointers defined in a module instead. Declare the pointers in the module, or pass them around in a single derived type argument. This is a necessary step before including the weather and fire components into VisTrails separately. (And also before reviving the standalone driver.) Jmandel 07:28, 14 June 2010 (UTC)

Surface Initialization

By default, the atmospheric surface layer and the land surface models are turned off, and there is no control over the basic surface properties in the idealized runs. In particular, there is no way to define the roughness length (z0) affecting the wind profile, and the skin and soil temperatures (TSK and TMN) affecting the surface heat flux. In order to have more realistic surface winds and surface heat fluxes, improvements in surface initialization are needed. The goal here would be to use general WRF mechanisms for the surface initialization based on the atmospheric surface layer model and land surface models. The surface properties would be defined using the USGS classification and LANDUSE.TBL records. Using on of the land surface models would allow for heaving the surface temperature and surface heat fluxes dynamically affected by the fire Adam Kochanski 11:55, 14 July 2010

Ignition Time

Currently, the number of seconds elapsed from the start of the simulation is calculated as the time_step * dt (see source). This assumes dt is constant. A correct implementation would use WRF domain time control derived types to query for the start time. For instance, the current simulation time is queried here. The start time for the current nest can be returned using the function domain_get_start_time here along with other useful time control subroutines. These functions return derived types based on ESMF specifications. In particular, these derived types support common operators such as addition, subtraction, and comparison (.le., .eq., etc.). See implementation of these types here and here. (Note: WRF renames the types internally from ESMF_Time to WRFU_Time.)

Another improvement over the current implementation would be to allow fire ignitions to occur in a restart run. This may come automatically if the simulation start time is obtained from domain_get_start_time; however, there may be breakage somewhere inside the model that I don't know about.

Jbeezley 21:12, 26 August 2010 (UTC)

See Timekeeping in WRF Users' guide, and also Earth System Modeling Framework ESMF Reference Manual for Fortran (2004). Jmandel 16:02, 18 September 2010 (UTC)

Fire spin-up

We'll add level function history information into input files to run the growing fire as given by data, until the given perimeter is reached, then the fire simulation takes over. This will allow the atmosphere to evolve along with the growing fire. Also, this will provide some support for gradual ignition. Jmandel 05:23, 30 August 2010 (UTC)

Google Earth

Google API seems to be the visualization and data format standard for wildfire data now. Output KML files... routine for surface data, almost all from the Four Mile Canyon fire was available as a Google Earth file. Can we have weather & fire as 3D COLLADA file? (file format used also for games such as Unreal engine). Check out Google Earth API also for a web-based display. We have proposed Google Earth visualization for wildfires in 2006 and 2007 but never connected to WRF-Fire. Jmandel 02:26, 19 September 2010 (UTC)