Talk:WRF-Fire

This is a talk page in blog format. Enter your questions, wishes, or anything else as separate sections at the bottom (click the + tab above). Start your response with : on a new line to offset, and sign your contribution by ~~~~. Please reply to entries here not on the author's talk page so that the discussion stays in one piece; you may want to put a short message on the author's talk page by placing the code {{message|Talk:Name of the talk page you want to bring to their attention}} ~~~~ there. Please see Help:Talk for more on talk pages.

Current wish list

• Restart done
• Read the topography from a file in an ideal run
• Smoothing the terrain gradients for fire spread Input gradient rather than terrain height so that the gradient can be smoothly interpolated in preprocessing.
• Canopy fire
• Output to WRF-Chem
• Better quadrature for fuel left
• Gradual ignition from a point or a line, without limitation on the initial radius
• Walking line ignition (as the fireman walks igniting the fire) done

Anything more? Jmandel 18:59, 19 January 2010 (UTC)

• Remove (by default) the warm perturbation (bubble) from atmospheric initializations in idealized cases done
• 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) done

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)