Difference between revisions of "Talk:WRF-Fire"

Latest revision as of 21:01, 28 May 2010

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.

The WRF-Fire wish list has been moved to WRF-Fire wish list and the discussion to Talk:WRF-Fire wish list. This page now serves for a discussion about the WRF-Fire page itself.

@@ Line 1: / Line 1: @@
-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 <nowiki>~~~~</nowiki>. See [[Help:Talk]] for more editing conventions for talk pages.
+{{talk}}
-==Current wish list==
+:''The WRF-Fire wish list has been moved to  [[WRF-Fire wish list]] and the discussion to [[Talk:WRF-Fire wish list]]. This page now serves for a discussion about the WRF-Fire page itself.''
-* <s>Restart</s> done
-* Read topography from file in ideal run
-* Smoothing the terrain gradients for fire spread
-* Canopy fire
-* Output to WRF-Chem
-Anything more? [[User:Jmandel|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. <code>/dyn_em/module_initialize_seabreeze2d_x.F</code> around <code> call ns_set_iswater</code>, at centers of the atmosphere mesh ("mass points")
-The input will be done similarly as in <code>dyn_em/module_initialize_b_wave.F</code> per suggestion of the WRF developers. See <code>subroutine read_input_jet</code>.
-This is as far as I want to go in ideal.exe, more complicated data input should be done through real.exe.
-[[User:Jmandel|Jmandel]] 01:29, 1 February 2010 (UTC)
-Agreed.  No reason to reinvent the wheel here.
-[[User:Jbeezley|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:
-# 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.
-# The two components of the gradient will be interpolated to the centers of the fire grid nodes by bilinear interpolation
-# 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
-# Gradient as accurate as the resolution of the topography data allows, without an unnecessary loss of accuracy
-# Continous gradient, without any jumps
-# 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.
-[[User:Jmandel|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:
-# 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.
-# 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 <code>wrf.exe</code> 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.
-[[User:Jbeezley|Jbeezley]] 02:41, 8 February 2010 (UTC)

Difference between revisions of "Talk:WRF-Fire"

Latest revision as of 21:01, 28 May 2010

Navigation menu

Search