Talk:WRF-Fire

From openwfm
Revision as of 00:53, 8 February 2010 by Jmandel (talk | contribs) (→‎Proposed computation of smooth terrain gradient: discontinuous at the fire mesh scale)
Jump to navigation Jump to search

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 ~~~~. See Help:Talk for more editing conventions for talk pages.

Current wish list

  • Restart done
  • Read topography from file in ideal run
  • Smoothing the terrain gradients for fire spread
  • Canopy fire
  • Output to WRF-Chem

Anything more? Jmandel 18:59, 19 January 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)

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 midpoint 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)