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)

Subscale ignition

Adam has noticed that the fire spread in the FireFlux sim is too fast. This appears to be at least partly because of the ignition and he got a better match with a smaller fire mesh step. But there are limits to how fine the fire mesh can be, even with Jon's latest improvement that allows an array in the NetCDF file to be over 2GB. There seem to be two reasons: 1. the ignition area is too large and it fires up all at once 2. in reality, a fire starts small, and only as the flame length grows, the wind-driven spread rate kicks in. Adam noted data that show that the spread rate starts slow and then goes up. One explanation would be that the spread rate depends on the flame length, and the flame length in turn increases with the mid-flame wind speed, so they feed on each other. Consequently, it can take a while before the fire is fully engaged (is engaged a technical term? I heard it in the Fourmile Canyon fire), yet the current model ignores that. To start, I'll just parametrize the spread rate as a linear function of distance from ignition until the full spread rate is reached.

So, after floundering for weeks, I have finally made up my mind. Line ignition will be by imposing level set function/ignition time based on the no-wind a given spread rate for a number of seconds until the ignition radius given in the namelist. Advancing the level set equation will run concurrently, by taking the pointwise minimum of the existing level set function and the imposed one in each time step, much like the pointwise minimum I am doing now. This will be called subscale ignition because the new parametrization is below the mesh resolution as well as below the model scale itself.

Jmandel 17:39, 17 October 2010 (UTC)

Parametrized ignition

Slow down the wind-driven spread rate by introducing new wind reduction factor: zero at the ignition line, 1 at a given distance from the ignition line. The distance will be measured as a combination of the distance to the nearest active point on the ignition line, and upwind distance. Taking upwind from the current point also avoid parallelism issues - we cannot go downwind from the ignition line because we cannot take info from the ignition line to other tiles, yet the level set function needs to be set on other tiles too. The distance from the ignition line where the full spread rate is reached will be a new property of fuel, and the weight in the mix between the nearest and upwind distance will be a parameter.

Or just attenuate winds close to ignition point.

Jmandel 23:12, 28 December 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)

Actually, we can prescribe just the ignition time - and use it as the level set function itself also. Will need to be extended to all domain. Two choices: continue spreading immediately (to replace existing ignition mechanism by gradual ignition) and just replay the history (for spin-up to a given perimeter). In branch jm2/ign. Jmandel 05:43, 29 September 2010 (UTC)

Google Earth

Google API seems to be the visualization and data format standard for all sort of geo data including 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 the previous project in 2006 and 2007 but never connected to WRF-Fire yet. VisTrails works with Maya and there is a COLLADA plugin for Maya... Jmandel 02:26, 19 September 2010 (UTC)

Jon figured out the basics. Remains interpolation to the grid google earth wants, autoupdating... Jmandel 05:47, 29 September 2010 (UTC)

ForeFire in Corsica has something like that. Jmandel 02:53, 28 December 2010 (UTC)

Fuel height

Suggested by Janice, all errors in the interpretation of what she said are mine. For every fuel, list the height to take the wind from and interpolate there at every fire mesh node directly. This would be similar as in CAWFE, which makes the grid level to take the wind from (fuel height) a part of the fuel description. I did not do it this way because it is more complicated and computationally expensive that what is in the code now (interpolate to 6.1m, then use the wind reduction factors) and I did not know what the fuel height numbers might be and how to adjust the rest of the spread rate coefficients, but it is certainly better, particularly if the first few grid levels are below the 6.1m. Then it would make sense to also make the roughness height a part of the fuel description, we would need the fine resolution. Jmandel 05:01, 8 February 2011 (UTC)

This has been on the back burner as "vertically interpolate the wind to different heights for different fuels" since November 2010. Putting back on the wish list now. Jmandel 12:49, 15 February 2011 (UTC)

Better quadrature for fuel left

• The quadrature is done separately on 4 smaller cells per fire cell. The interpolation of time from ignition to the smaller cells should take into consideration the case when some of the nodes interpolated from are ignited and some are not. branch jm2/fuel branch vk/test blog. merged into master (fast forward) March 23, 2011, but do not use method 2 yet.