Talk:WRF-Fire development notes

Current wish list

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)

Standalone driver

This is how WRF-Fire was originally developed and the driver was available as 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.