Open nikosuser opened 2 months ago
A starting point might be to try a simpler version of level set in FDS. I would expect FARSITE to be more similar to FDS level set mode 1 or 2, depending if you are using Wind Ninja to establish a background wind field.
If the results agree when given equivalent inputs for the wind field, we can probably rule out an issue with the basic algorithm and the issue is then with how the fire and the wind are interacting in mode 4.
I reran the simulation with modes 1 and two. I got similar results, with the back fire spreading excessively
I checked the wind and it seems that only the first value is used in modes 1 and 2, the wind does not become transient. For the original case I checked again and the wind is transient as prescribed through the ramps. I will report, however, that the wind magnitude values when plotted AGL are not transient.
I did notice in the original case that near the ground the ground effects do produce some recirculation. It might be the case that the level set method uses the wind velocity of the recirculation? I am running a case with no fire to study how the wind evolves.
Note that this simulation was done using obstructions for the terrain. I tried running this with surfaces in 6.9.0 (the version loaded in our HPC) and it did not manage to start (i.e. get to the point of the first iteration) after 8 hours.
Can you upload the input file for me to try running?
Done
Thanks! I'm traveling today but will look asap
For mode 1, the wind will change in time according to the ramps you set (note that with the latest version of FDS, you need RAMP_SPEED_T
and RAMP_DIRECTION_T
because there can be ramps for elevation as well). However, you will not see this changing wind in the output slices because the whole velocity field is not being updated, just the wind speed parameter passed to the level set model. This questions about the outputs/rendering for mode 1 is something we could look into improving.
For mode 2, the wind will evolve up to the point of starting the fire and then the field will be frozen. If you want a spatially resolved wind field that evolves in time you should use mode 3 or 4.
That being said... I would first focus on a comparison of FARSITE and level set mode 1. Run your case in FARSITE with the same wind information (time varying but not spatially varying). Are the time intervals in your first comparison images the same for FDS and FARSITE? To me the mode 1 results in FDS make some sense. First the fire spreads downslope with the wind:
Later, if you run your case long enough, the backing fire spreads (aided by the slope).
There level set front will always spread against the wind, assuming there is fuel available, its just a matter of how quickly ...hence my question about the simulation durations being the same. You could also compare FDS and FARSITE at a few snapshots to get a better sense of the differences.
If the 1-to-1 comparison is far off for a few different snapshots, there might be an issue of topography. The next step would be to run both cases (again with a spatially uniform wind/mode 1) with the terrain flattened so we are just comparing fuel and wind effects.
I did some extra simulations according to what you said.
I compared the two models with the same fuel but completely flat terrain. The results were comparable, with differences probably coming down to inane model differences.
I did then try uniform fuel and real elevation, and got the results below:
I used mode 1, 4 hour simulation. The back fire seems to be a lot faster compared to farsite. Again it is hard to compare the two without some post processing for visualisation but, comparing the fire scars to their ignition spots, the FDS results seem to climb a lot more. Running the simulation for 10 hours exacerbates the problem (I can find screenshots if need be). It might be that the model is very sensitive to slope? Again, this might be expected behavior and just another model difference, I just want to be sure of the results.
On another note, how does FDS take slope into account? Does it interpolate the slope values of each cell based on the elevation raster?
FDS should compute the gradient base on a central difference of elevation at cell centers and then apply these slopes to get an slope coefficient vector for each cell. See A1-5 in the appendix of this paper: https://www.publish.csiro.au/wf/wf13178
So then there is a question of whether the elevation values in your input file agree with those being used in FARSITE. I'm not sure if you have an easy way to do that. This is more of a check of your pre-processing than then model. If you are using qgis2fds you could also try representing the terrain as complex geometry (GEOM) and see if that makes any difference.
I can try modifying one of the level set verification cases we have to check upslope backing spread against the expected value from the implementation described in that paper. If there is some difference between that paper and FARSITE that is a different story.
For comparing outputs, would it be possible to include a single FARSITE prediction (say at 4hrs) in the background image for smokeview? Without seeing how the contours overlay I'm finding it difficult to see how much of a difference we are talking about.
I did use qgis2fds for the data. The elevation data I used in both cases are in meters, which i assume is what FDS expects. I tried running this with GEOM but it took a prohibitively long time to start (8 hours in and it did not start iterating).
I will rerun the case I sent (possibly at 6 hours) and overlay the arrival time contour of Farsite. This should let us compare overall scars and (to some extent) the comparative rate of spread.
Niko, can you upload the geom terrain case? I'd like to take a look at it. ThanksOn Sep 19, 2024 5:26 PM, nikosuser @.***> wrote: I did use qgis2fds for the data. The elevation data I used in both cases are in meters, which i assume is what FDS expects. I tried running this with GEOM but it took a prohibitively long time to start (8 hours in and it did not start iterating). I will rerun the case I sent (possibly at 6 hours) and overlay the arrival time contour of Farsite. This should let us compare overall scars and (to some extent) the comparative rate of spread.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yup it's in meters. I meant more are the specific values in the input file the same as they are for the FARSITE input. Qgis2fds may be doing interpolation based on your grid resolution.
I'll update you when I get a chance to check backing spread in a simple case.
@marcosvanella Here you go mati_GEOM.zip
I ran the comparison with uniform fuel again and directly placed the output of Farsite on FDS as a terrain image. Red lines are hourly marks, and black lines are in 10-min arrival intervals. All fuels are fuel model 3, simulation total 6 hours for both .
https://github.com/user-attachments/assets/92e8bae6-0caf-4a7d-84cb-891c01abfd92
It seems the FDS Level set is in general faster in all directions, both along with and against the wind. Might be worth doing a parametric study on my end to see what is going on, but that will have to wait until after some deadlines
I did some more testing on this. Specifically I ran some test cases on the elementary behaviors of the model and compared them. I compared FDS level set mode 1, level set mode 4, Farsite and ELMFIRE to have some measure of comparison.
Results:
No-wind-no-slope: good agreement. FDS4 is faster than FDS1 which might be because of the induced wind. No-wind-slope: FDS 1 good agreement with Farsite. ELMFIRE uses a different spread model so it makes sense. FDS4 results in higher head ROS values which can be explained by induced wind wind-no-slope: This is where it gets interesting. FDS 1 and 4 are significantly faster than either Farsite or ELMFIRE, both for headfires and backfires. The wind is 15kph (farsite) = 4.3 m/s (FDS) = 9.3 mph (ELMFIRE).
See figures below. RED = Farsite BLACK = ELMFIRE VIOLET = FDS1 TEAL = FDS4
(also note the six discontinuities that occur in the corners where meshes meet.
In short, the original issue of the simulated Mati fire being too fast might be because the effect of the wind, compared to the other models, is greater. I do not know if this is expected behavior but I will flag it here anyways.
This solved my original issue but this new issue persists, let me know if I should close this issue and start another one.
Can you provide the details of the fuel layer? We should be able to do a calculation of the head fire rate based on the model assumptions (which I believe are meant to be equivalent for LS1 and farsite) and maybe get an idea of where things are off.
This is all fuel model 3, 126 x 126 cells, 30m cells.
Are you using the FDS default fuel moisture in all cases (3% for fine dead fuel)? If so, using BehavePlus I get a zero-wind zero-slope spread rate of .0341 m/s. I assume you also get this in FDS because you say the no-wind case agrees with FARSITE ...but you can double check this by looking at the *.out file for the ROS_00 value.
Then, if you input a 4.3 m/s wind (I assume this is the value at 6 m or it doesn't vary with height), FDS will use eq A2 in the paper I linked above to get a mid-flame wind speed. So using fuel model 3 height of 0.675 m the wind speed FDS is plugging in to Rothermel should be ~1.84 m/s. Going back to BehavePlus and using this mid-flame value I get a head fire spread rate of 0.699 m/s.
Can you estimate the head fire spread rates from your example to see how FDS LS1 and FARSITE compare to this value? If FDS agrees with it, then I assume the wind speed is not applied in the same way in FARSITE. If FARSITE agrees with it, then we have a bug in FDS.
So, the screenshots I set were with the standard Farsite fuel moisture (6% FFMC), so the difference is exaggerated because of this. I reran with 3% FFMC and the difference is less but still there. Based on the new simulations:
The head ROS value from Farsite in this case is 38.2 m/min ( = 0.637 m/s) and the FDS head ROS is (roughly calculated) 0.731 m/s.
I would guess the 6 meter height comes from the common 20ft high wind readings. I think I remember that Farsite defines the wind as 10m high (when the inputs are metric). Could this be the source of the discrepancy?
Sorry, yeah I'm not really very familiar with FARSITE. According to that above paper from Tony et al., if you enter a metric windspeed in FARSITE then its assumed the reference measurement was made at 10m. It is converted to a 6m/20ft windspeed by reducing it by a factor of 1/1.15 and then it is plugged into the wind adjustment formula for 6m/20ft wind. So going backwards, a 4.3 m/s wind in FDS is a 18 km/h wind in FARSITE (each at their respective reference heights).
That should bring you one step closer. As for why the FDS value is above the theoretical Rothermel value of 0.699 m/s, I'm not yet certain. Could you post your LS1 input for this test? I can dig a bit further.
What version of FARSITE are you using for reference? Missoula deprecated FARSITE as a stand-alone tool a few years ago. @ericvmueller are you sure the wind adjustment factor is always 1.15 in the current FARSITE? My understanding is it also considers the depth of the fuel bed, canopy cover fraction, etc. I do not see it mentioned explicitly in the latest documentation, but the behave algorithm is documented here: https://research.fs.usda.gov/treesearch/39729
1.15 is not the wind adjustment factor. It is a factor to get reference measurement made at metric standard height to a value at imperial standard height. The adjustment factor is then applied, which includes the parameters you mention.
Thanks for clarifying. Does LS1 in FDS use a similar calculation for wind adjustment factor? If not, it will be hard to compare with FARSITE directly. We could output the gridded winds from FARSITE post-adjustment and use that as an input to LS1.
Yup there is the same adjustment equation in FDS. So no matter what your vertical wind profile is near the surface in FDS, the value the model uses is the one at 6m/20ft and then adjusts it based on assumptions about flame height (https://www.frames.gov/documents/behaveplus/publications/Albini_and_Baughman_1979_INT-RP-221_ocr.pdf)
@johodges I am using Flammap 6.2, and to avoid confusion with the MTT fire spread model I still refer to the integrated Farsite model in Flammap as Farsite. @ericvmueller See file attached, made with qgis2fds windy.zip
I confirmed within the routine that FDS computes a head fire spread rate of 0.7035 m/s, which is pretty close to the expected BehavePlus (Rothermel) value.
I added some devices to your case to directly measure arrival time at 100m intervals in the head fire direction:
&DEVC XBP=0,0,-1000,1000,0,0, POINTS=20, QUANTITY='TIME OF ARRIVAL', TIME_HISTORY=T/
The fit gives a spread rate ~4% below the expected one
This may improve with increasing grid resolution, as the discrepancy appears to be in the advection of the level set not in the computation of the head fire spread rate. Still, I'm hopeful if you adjust either the FARSITE or FDS wind speed so they agree when scaled to the same reference height the contours will line up reasonably well (for LS1).
I am attempting to simulate the Mati wildfire in FDS in level set method (setting 4). I used qgis2fds to generate the necessary data and edited the FDS files to include wind etc. The results seem to promote the spread of backfire excessively. Comparing the results with a Farsite simulation (and the real fire scar) shows that FDS overestimates the back spread and underestimates the forward spread. I am not sure if this is expected behavior or something to be looked into.
Screenshots Smokeview: Farsite: Real Scar: https://en.wikipedia.org/wiki/2018_Attica_wildfires#/media/File:Rafina_-_Neos_Vountzas_-_Mati_fire_delianation_map_EMSR300.jpg Comparison:
Desktop (please complete the following information):
I can upload all files (once I figure out how to do this, results are half a Gig).