Wildfire sim with LEVEL_SET_MODE=4 segmentation fault

[emanuelegissi]

I attach a LEVEL_SET wildfire simulation that segfaults at around 340s. The case is as small as possibile, quite fast to run, and unfortunately still crashing. After some investigation I am still clueless.

Here are fds and qgis2fds files: https://drive.google.com/drive/folders/1tM-Ur-d-h9ryBecgQVbZ1NjqSIXYXV6F?usp=sharing

May I ask you a quick look? Thank you in advance. This should be the first demo of a on-the-field use of FDS for tenability condition forecast during wildfires. We are having a very large firefighting exercise on Le Manie area on Sunday.

The problem lies at MESH #8:

Time Step: 1600, Simulation Time: 339.87 s WARNING: Minimum density, 0.120 kg/m3, clipped in Mesh 8 Time Step: 1700, Simulation Time: 346.31 s WARNING: Minimum density, 0.120 kg/m3, clipped in Mesh 8 WARNING: Minimum density, 0.120 kg/m3, clipped in Mesh 8 WARNING: Minimum density, 0.120 kg/m3, clipped in Mesh 8 Time Step: 1800, Simulation Time: 351.70 s WARNING: Minimum density, 0.120 kg/m3, clipped in Mesh 8 forrtl: severe (174): SIGSEGV, segmentation fault occurred

   Time Step    1800   August 20, 2021  09:10:32
   Step Size:    0.558E-01 s, Total Time:     351.70 s
   Pressure Iterations:     10
   Maximum Velocity Error:  0.95E+00 on Mesh   8 at (  11  23  16)
   Maximum Pressure Error:  0.18E+02 on Mesh   8 at (  11  23  17)
   ---------------------------------------------------------------
   [...]
   Mesh    8
   Max CFL number:  0.58E+00 at (  10,  23,  18)
   Max divergence:  0.48E+01 at (  10,  23,  18)
   Min divergence: -0.75E+00 at (  11,  23,  19)
   Max VN number:   0.15E+00 at (  12,  26,  28)
   [...]

[emanuelegissi]

Forgot to add. I am using the nightly FDS and Smokeview:

Fire Dynamics Simulator

Current Date : August 20, 2021 08:51:58 Revision : FDS6.7.6-517-ga37657af7-nightly Revision Date : Tue Aug 17 22:13:24 2021 -0400 Compiler : Intel ifort 2021.1 Compilation Date : Aug 18, 2021 11:31:36

MPI Enabled; Number of MPI Processes: 16 OpenMP Enabled; Number of OpenMP Threads: 1

MPI version: 3.1 MPI library version: Intel(R) MPI Library 2021.1 for Linux* OS

[mcgratta]

I'll take a look.

[emanuelegissi]

Thank you!

On Fri, Aug 20, 2021, 14:15 Kevin McGrattan @.***> wrote:

I'll take a look.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-902649885, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYYGR6R6MCVEHXCUT3DT5ZBPDANCNFSM5CP3QQHQ .

[rmcdermo]

Kevin is saying that

&MISC NO_SLIP=T

will work. I'd go with that. Setting CC_STRESS_METHOD=F did not solve the problem for me.

[emanuelegissi]

Ok, I'll try that. It would be good for the demo.

On Fri, Aug 20, 2021, 16:57 Randy McDermott @.***> wrote:

Kevin is saying that

&MISC NO_SLIP=T

will work. I'd go with that. Setting CC_STRESS_METHOD=F did not solve the problem for me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-902753747, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY5A7ZJGZZTTX6GVGUDT5ZUL3ANCNFSM5CP3QQHQ .

[rmcdermo]

@emanuelegissi This input file seems to working. It is up to 3300 s and still going (latest source). lemanie.fds.txt

[emanuelegissi]

My previous attempt crashed at 390s. I am now rerunning the case following your advices:

&MISC ORIGIN_LAT=44.1965043 ORIGIN_LON=8.3891232 NORTH_BEARING=0. TERRAIN_IMAGE='lemanie_tex.png' LEVEL_SET_MODE=4 CC_STRESS_METHOD=T CFL_MAX=0.9 CHECK_HT=T /

&PRES VELOCITY_TOLERANCE=1.E-6, MAX_PRESSURE_ITERATIONS=100 /

&SURF ID='A01' RGB=255,254,212 VEG_LSET_FUEL_INDEX= 1 NO_SLIP=T /

And I raised the MESH z1 of 50 meters more: &MESH IJK=72,132,35 MULT_ID='Meshes' XB=-560.358,165.308,-779.937,545.592,116.000,472.500 /

Maybe the OPEN condition was too close to some parts of the terrain?

I'll let you know, I am confident.

...

Il giorno sab 21 ago 2021 alle ore 03:46 Randy McDermott < @.***> ha scritto:

@emanuelegissi https://github.com/emanuelegissi This input file seems to working. It is up to 3300 s and still going (latest source). lemanie.fds.txt https://github.com/firemodels/fds/files/7024675/lemanie.fds.txt

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-903034337, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY4UMBGG7WVE4B76Y4LT54APHANCNFSM5CP3QQHQ .

[rmcdermo]

@emanuelegissi The case finished for me with the input file above. I was on 16 cores and it ran in about 8 hours (8 times slower than real time). We need to investigate what was slowing things down. I'm going to systematically loosen the stability criteria to try to see what is responsible. Let's leave this Issue open until we have the defaults working properly for this case.

Thanks for the real-world case. Of course, the usual caveats apply for this method being in development (level set parameters, boundary conditions, etc.). Use with caution! I would treat uncertainties in model output as being very high. The results are a "reasonable guess", not a definitive forecast.

[mcgratta]

Just look at the _cpu.csv file. My guess is that with such a low VELOCITY_TOLERANCE, you are maxing out on pressure iterations.

[emanuelegissi]

After yesterday exercise, this morning I was less stressed out, and could think a little more to what was happening to the Le Manie simulation. To reproduce the segfault earlier I rose the wind speed at 100s.

Then I just set a taller domain, increasing the number of cells between the terrain and the OPEN boundary, and the segfault disappeared. No other modification needed (eg. CC_STRESS_METHOD=T). There was some minimum density clipping at very high wind speeds.

In Smokeview I noticed some high speed vectors close to the terrain that I presume refer to cut cells.

To try to speed the calculation up, I switched off the radiation solver. Is there something else I can do?

I am uploading the updated qgis2fds and fds files to the same google drive share: https://drive.google.com/drive/folders/1tM-Ur-d-h9ryBecgQVbZ1NjqSIXYXV6F?usp=sharing

The qgis file works only with the this morning qgis2fds from the github repo.

[emanuelegissi]

Forgot to add that without radiation the simulation runs at 1:3 to realtime (16 MESHes of 41580 cells each on 16 cores). Adding more MESHes and cores doesn't seem to improve the speed. But I need more time to investigate that.

Il giorno lun 23 ago 2021 alle ore 15:41 Emanuele Gissi < @.***> ha scritto:

After yesterday exercise, this morning I was less stressed out, and could think a little more to what was happening to the Le Manie simulation. To reproduce the segfault earlier I rose the wind speed at 100s.

Then I just set a taller domain, increasing the number of cells between the terrain and the OPEN boundary, and the segfault disappeared. No other modification needed (eg. CC_STRESS_METHOD=T). There was some minimum density clipping at very high wind speeds.

In Smokeview I noticed some high speed vectors close to the terrain that I presume refer to cut cells.

To try to speed the calculation up, I switched off the radiation solver. Is there something else I can do?

I am uploading the updated qgis2fds and fds files to the same google drive share:

https://drive.google.com/drive/folders/1tM-Ur-d-h9ryBecgQVbZ1NjqSIXYXV6F?usp=sharing

The qgis file works only with the this morning qgis2fds from the github repo.

[mcgratta]

I think that the GEOM terrain is currently fragile. It sometimes helps to remesh the case, but there are still issues related to the surface boundary layer treatment.

[rmcdermo]

Yes, but I think the biggest thing we need to take away from this case is that the default VELOCITY_TOLERANCE needs to be rethought. I did not have time over the weekend. But I will start running cases now to see what values works.

[mcgratta]

One idea is to make VOLOCITY_TOLERANCE, u_tol, a fraction of u_max, the maximum gas phase velocity used in the CFL constraint (dt=dx/u_max). Then we are saying that u_tol*dt = C dx, where C is that fraction. Or in other words, we are fixing the maximum distance across a grid cell that the error can propagate.

[rmcdermo]

@marcosvanella I set up a set of cases that explored the VELOCITY_TOLERANCE with the default GEOM settings, but they all either went unstable or gave a seg fault. The cases are here:

/home4/rmcdermo/Issues/Issues_9819/VELTOL*/

[rmcdermo]

@mcgratta Tying VELOCITY_TOLERANCE to something like u_max would definitely be a step in the right direction. Though, I think that changing VEL_TOL time step to time step is more complicated than we need. Further, the error in velocity is never just confined to propagating one cell; it is elliptic, the error is felt all the way across the mesh instantly.

[drjfloyd]

Would u_max get us what we want as a general criteria? In a wind simulation where wind speed increases with height that could give a large tolerance at ground level where wind speeds are lower and we might have structures present where we want to avoid penetration of wind through walls. For more general simulations where we don't want flow through solid obstructions we wouldn't want a spurious high speed flow to suddenly allow a lot of flow through walls.

[rmcdermo]

Yes, I agree. I am more inclined to choose a reasonable constant value that we judge we can tolerate for mesh and solid penetration errors. Generally, I think this is way smaller than we usually allow, probably on the order of 0.01 m/s or less.

[emanuelegissi]

@Randy McDermott @.***> Yes, sure, the method is in development, and we are using it more as a capability demo of what we are probably going to use in 5 years than as a tool.

At the moment we are integrating CIMA Propagator simulations as an operational tool, using the incoming data from a field weather station (very rugged, firefighter safe...).

I attach an example of a very simple simulation map generated with that data. On the map you see the positioning of the teams, the resources, and the WUI (eg. isolated houses) that need specific protection. [image: Esercitazione_AIB_Finale_Ligure_Le_Manie_22-08-2021_Simulazione_ore_12-14.jpg] In the next iteration we are going to superimpose the orthographic thermal imagery (right picture) of the fire at different times, so that we can restart the simulation for the following 6 hours based on real data. We are able to produce such images with UAVs (drones) equipped with thermal cameras at a 2 hours frequency. To avoid flight interference we are using the time intervals when firefighting planes are refuelling. Not an easy task. But I imagine this would be very useful for model validation!

I am going to present this effort in more detail at the IAFSS webinar LOF&BE on Sept 7, 2021 10:00 am Eastern USA.

At the same time I am working on qgis2fds features to import these fire lines as ignition sources.

[image: DJI_0841_small.JPG][image: DJI_0842_IR.JPG]

Il giorno sab 21 ago 2021 alle ore 13:46 Randy McDermott < @.***> ha scritto:

@emanuelegissi https://github.com/emanuelegissi The case finished for me with the input file above. I was on 16 cores and it ran in about 8 hours (8 times slower than real time). We need to investigate what was slowing things down. I'm going to systematically loosen the stability criteria to try to see what is responsible. Let's leave this Issue open until we have the defaults working properly for this case.

Thanks for the real-world case. Of course, the usual caveats apply for this method being in development (level set parameters, boundary conditions, etc.). Use with caution! I would treat uncertainties in model output as being very high. They are a "reasonable guess", not a definitive forecast.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-903104341, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY5IJQG3GFD67G7V7XLT56GX7ANCNFSM5CP3QQHQ .

[emanuelegissi]

Here are the missing images:

[emanuelegissi]

(I am probably misusing this issue, sorry)

[mcgratta]

What is the status of this issue?

[rmcdermo]

Marcos is trying to pin down where things go bad. It still looks like it is somehow related to pressure iterations, but also the CFL for cutfaces.

I want to keep this open until we have something that can be used to pin down a maximum value of VELOCITY_TOLERANCE.

[mcgratta]

Marcos, can you take another look at this case with the latest code.

[mcgratta]

Ema -- how difficult would it be to add to QGIS2FDS the capability to create the terrain using OBST lines as an option?

[emanuelegissi]

Kevin, It shouldn't be too hard. I never used this feature before, as I believed it was going to be superceded by GEOMs. May you point me to an example? Ema

On Wed, Dec 15, 2021, 22:18 Kevin McGrattan @.***> wrote:

Ema -- how difficult would it be to add to QGIS2FDS the capability to create the terrain using OBST lines as an option?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995221317, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY6WH5TUIA5U6C7NXSTUREA4BANCNFSM5CP3QQHQ .

[rmcdermo]

Kevin, Marcos is planning to implement this into FDS for terrain. The obst will inherit the ZLS of the original geom, thus solving the slope problem for the speed function.

On Thu, Dec 16, 2021 at 12:13 AM Emanuele Gissi @.***> wrote:

Kevin, It shouldn't be too hard. I never used this feature before, as I believed it was going to be superceded by GEOMs. May you point me to an example? Ema

On Wed, Dec 15, 2021, 22:18 Kevin McGrattan @.***> wrote:

Ema -- how difficult would it be to add to QGIS2FDS the capability to create the terrain using OBST lines as an option?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995221317, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACXMVY6WH5TUIA5U6C7NXSTUREA4BANCNFSM5CP3QQHQ

.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995445718, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBWXQJCAXM7U45JMI5X5N3URFYOXANCNFSM5CP3QQHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Sent from my iPhone

[mcgratta]

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

[emanuelegissi]

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here: https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[mcgratta]

Ema, thanks. Take the easy road. FDS will just snap the OBSTs appropriately. In the long run, we still want to focus on the new GEOM syntax, but we need something simple in the short term while GEOM is still in development. This will also enable us to compare performance and timings using both the new and old formats.

[emanuelegissi]

Ok, great. I am going to stabilize the new code then.

On Mon, Dec 20, 2021, 15:33 Kevin McGrattan @.***> wrote:

Ema, thanks. Take the easy road. FDS will just snap the OBSTs appropriately. In the long run, we still want to focus on the new GEOM syntax, but we need something simple in the short term while GEOM is still in development. This will also enable us to compare performance and timings using both the new and old formats.

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-997978073, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY7VBGKJHERIGIZSIUDUR45EXANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

Still some glitches. Almost there. Happy holidays! [image: image.png]

Il giorno lun 20 dic 2021 alle ore 14:29 Emanuele Gissi < @.***> ha scritto:

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here:

https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

Ok, I pushed to the qgis2fds repo an improved version of the OBST terrain generation. It should work now, The voids in the OBST terrain are filled, no OBST overlapping required. The OBST terrain should be as close as possible to the GEOM terrain. (The texture is still not displayed correctly, as it should be cut differently. Still experimenting on that.) Hope this helps. Emanuele

Il giorno dom 26 dic 2021 alle ore 17:17 Emanuele Gissi < @.***> ha scritto:

Still some glitches. Almost there. Happy holidays! [image: image.png]

Il giorno lun 20 dic 2021 alle ore 14:29 Emanuele Gissi < @.***> ha scritto:

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here:

https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

In today's qgis2fds the OBST terrain texture seems correctly cut. The visualization in Smokeview is not as smooth as with GEOM terrains, but this seems not to be a qgis2fds issue. Polishing and testing continues. Emanuele

Il giorno dom 26 dic 2021 alle ore 23:33 Emanuele Gissi < @.***> ha scritto:

Ok, I pushed to the qgis2fds repo an improved version of the OBST terrain generation. It should work now, The voids in the OBST terrain are filled, no OBST overlapping required. The OBST terrain should be as close as possible to the GEOM terrain. (The texture is still not displayed correctly, as it should be cut differently. Still experimenting on that.) Hope this helps. Emanuele

Il giorno dom 26 dic 2021 alle ore 17:17 Emanuele Gissi < @.***> ha scritto:

Still some glitches. Almost there. Happy holidays! [image: image.png]

Il giorno lun 20 dic 2021 alle ore 14:29 Emanuele Gissi < @.***> ha scritto:

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here:

https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

Here is a screenshot. On the left-hand side an OBSTs terrain, on the right-hand side the same terrain made of a GEOM. [image: image.png]

Il giorno lun 27 dic 2021 alle ore 14:57 Emanuele Gissi < @.***> ha scritto:

In today's qgis2fds the OBST terrain texture seems correctly cut. The visualization in Smokeview is not as smooth as with GEOM terrains, but this seems not to be a qgis2fds issue. Polishing and testing continues. Emanuele

Il giorno dom 26 dic 2021 alle ore 23:33 Emanuele Gissi < @.***> ha scritto:

Ok, I pushed to the qgis2fds repo an improved version of the OBST terrain generation. It should work now, The voids in the OBST terrain are filled, no OBST overlapping required. The OBST terrain should be as close as possible to the GEOM terrain. (The texture is still not displayed correctly, as it should be cut differently. Still experimenting on that.) Hope this helps. Emanuele

Il giorno dom 26 dic 2021 alle ore 17:17 Emanuele Gissi < @.***> ha scritto:

Still some glitches. Almost there. Happy holidays! [image: image.png]

Il giorno lun 20 dic 2021 alle ore 14:29 Emanuele Gissi < @.***> ha scritto:

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here:

https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[gforney]

ema, I don't see the screenshot glenn

[emanuelegissi]

Today I cleaned up the code and tested the verification cases. Let me know if it works for you, and I will prepare a release. Ema

Il giorno lun 27 dic 2021 alle ore 15:09 Emanuele Gissi < @.***> ha scritto:

Here is a screenshot. On the left-hand side an OBSTs terrain, on the right-hand side the same terrain made of a GEOM. [image: image.png]

Il giorno lun 27 dic 2021 alle ore 14:57 Emanuele Gissi < @.***> ha scritto:

In today's qgis2fds the OBST terrain texture seems correctly cut. The visualization in Smokeview is not as smooth as with GEOM terrains, but this seems not to be a qgis2fds issue. Polishing and testing continues. Emanuele

Il giorno dom 26 dic 2021 alle ore 23:33 Emanuele Gissi < @.***> ha scritto:

Ok, I pushed to the qgis2fds repo an improved version of the OBST terrain generation. It should work now, The voids in the OBST terrain are filled, no OBST overlapping required. The OBST terrain should be as close as possible to the GEOM terrain. (The texture is still not displayed correctly, as it should be cut differently. Still experimenting on that.) Hope this helps. Emanuele

Il giorno dom 26 dic 2021 alle ore 17:17 Emanuele Gissi < @.***> ha scritto:

Still some glitches. Almost there. Happy holidays! [image: image.png]

Il giorno lun 20 dic 2021 alle ore 14:29 Emanuele Gissi < @.***> ha scritto:

Today I almost completed the OBST exporting machinery in qgis2fds.

But there is a problem I had underestimated. The GEOM triangle pairs (squares) are not aligned to the MESH reference system.

The reason is explained here:

https://github.com/firetools/qgis2fds/wiki/FAQ#why-is-the-exported-fds-terrain-geom-larger-and-rotated-compared-to-the-fds-domain-mesh

So I cannot just create an OBST for each GEOM square, because the GEOM squares are rotated around the z axis. This is what I would obtain:

[image: image.png]

The possible solutions I see are:

1. the easy one: overlapping the neighboring OBSTs to close the holes. But I do not understand if this would work in FDS and how much OBST overlapping would be allowed.
2. the hard one: using a different geographic gridding algorithm aligned to the MESH reference system, with reduced fidelity to the original DEM (elevation) data.

The first solution is almost ready, even if I still have some issues. This is what I obtain now (OBST terrain on the left side, the same GEOM terrain on the right side): [image: image.png]

The second solution would need a substantial rewrite and duplication of what is currently done in qgis2fds, much more than the two days' work I estimated in advance. And the resulting terrain would be different from the GEOM terrain.

There are also a couple of additional questions I should solve:

1. The texture projection on the OBST terrain seems to work differently than in GEOMs.
2. I cannot get FDS to recognize the boundary condition on top of the OBST terrain. Is it just a problem of Smokeview visualization or am I doing something wrong?

I pushed the current code to the repo so that you can easily check it. There is a new toggle in the UI: [image: image.png]

Don't judge too harshly the fds.py and geometry.py code, it's still a hack ;-) Disclaimer: The GEOM terrain side should still work well, even if I had to modify some code (so it could be terribly broken ;-).

Let me know how you wish I proceed. Emanuele

Il giorno ven 17 dic 2021 alle ore 19:45 Emanuele Gissi < @.***> ha scritto:

I started working on the feature. Seemengly quite simple, a couple of days work.

On Thu, Dec 16, 2021, 17:40 Emanuele Gissi @.***> wrote:

Ok, I understand now. It seems quite simple to implement. Let me check an I'll let you know.

On Thu, Dec 16, 2021, 16:03 Kevin McGrattan < @.***> wrote:

The idea is that the user would specify the grid resolution, and each OBST would have the "true" height of the terrain at that point. When read in, this true height would be used to calculate the gradient of the terrain.

Ema -- how about using your existing example of San Francisco?

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-995899236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZZ3POZI27BW2JEE4TURH5S7ANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[rmcdermo]

@emanuelegissi Thank you very much for your quick work on this, especially over the holidays. I hope to have time to test this today, but still have company in town, so might be tomorrow. Cheers

[emanuelegissi]

@Randy McDermott @.***> Happy to contribute to the challenge. Enjoy the company, no problem from my part.

Il giorno mar 28 dic 2021 alle ore 15:23 Randy McDermott < @.***> ha scritto:

@emanuelegissi https://github.com/emanuelegissi Thank you very much for your quick work on this, especially over the holidays. I hope to have time to test this today, but still have company in town, so might be tomorrow. Cheers

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-1002129602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY5MW2UCMSV63IIAXI3UTHB5BANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[mcgratta]

As usual, I am struggling with QGIS. I had to upgrade, and now I am trying to reinstall the qgis2fds plugin from the git repository. I have deleted and re-created the qgis2fds folder in my local plugins folder, and I have recloned the latest qgis2fds repository. But I still see this:

[rmcdermo]

I will try now... in the meantime, make sure you've followed the steps for installing the "live" version here:

https://github.com/firetools/qgis2fds/wiki/Installing

[emanuelegissi]

Well, I probably forgot to bump the version number ;-) whoops

On Tue, Dec 28, 2021, 18:11 Randy McDermott @.***> wrote:

I will try now... in the meantime, make sure you've followed the steps for installing the "live" version here:

https://github.com/firetools/qgis2fds/wiki/Installing

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-1002202280, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY3O2SK6YJMY6L2JSRTUTHVTNANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[emanuelegissi]

I will fix it as soon as I touch a keyboard, it's dinner time

On Tue, Dec 28, 2021, 18:56 Emanuele Gissi @.***> wrote:

Well, I probably forgot to bump the version number ;-) whoops

On Tue, Dec 28, 2021, 18:11 Randy McDermott @.***> wrote:

I will try now... in the meantime, make sure you've followed the steps for installing the "live" version here:

https://github.com/firetools/qgis2fds/wiki/Installing

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-1002202280, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY3O2SK6YJMY6L2JSRTUTHVTNANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[rmcdermo]

Ema, doesn't the view that Kevin is seeing indicate he is using the latest Release of qgis2fds, when what he needs is the live repo version to test your changes? Based on your earlier comments, I thought you had not yet created a release plugin.

[mcgratta]

I believe that I am using the live repo version. I think I uninstalled and reinstalled it. In any event, updating the version number and date of any new version (even a test version) is very important with something like QGIS because I never feel that I have it installed right.

Message ID: @.***>

[rmcdermo]

@emanuelegissi I was able to install with QGIS 3.22 without any problem. I went through the "quick start", omitting fire line, etc. and was able to export a terrain with OBST. But I had not included a land use *.csv file yet. I then copied the 'Landfire.gov_F13.csv' from your repo to my project directory and pointed to that file in landuse. When I tried to Run the script, I get this error message. My qgz file is also attached in the zip file.

test.zip

[emanuelegissi]

I confirm I forgot to bump the version number. I fixed it now and pushed to the repo. Sorry again guys.

@Randy McDermott @.***> This is the latest QGIS bug that sometimes resurfaces. I trap it, but I cannot reproduce it reliably. In general, it is enough to restart QGIS and it disappears.

Please, try the three test cases at: https://github.com/firetools/qgisfds.verification If this ugly bug comes out reliably I will try to investigate it further.

Il giorno mar 28 dic 2021 alle ore 20:20 Randy McDermott < @.***> ha scritto:

@emanuelegissi https://github.com/emanuelegissi I was able to install with QGIS 3.22 without any problem. I went through the "quick start", omitting fire line, etc. and was able to export a terrain with OBST. But I had not included a land use *.csv file yet. I then copied the 'Landfire.gov_F13.csv' from your repo to my project directory and pointed to that file in landuse. When I tied to Run the script, I get this error message. My qgz file is also attached in the zip file.

[image: Screen Shot 2021-12-28 at 2 01 03 PM] https://user-images.githubusercontent.com/4418497/147599611-e07befe3-3aa4-4f3e-830b-85318f5e5b7c.png

test.zip https://github.com/firemodels/fds/files/7786092/test.zip

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/9819#issuecomment-1002248323, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYZ63C4VAGB72Z5SHZDUTIEXFANCNFSM5CP3QQHQ . You are receiving this because you were mentioned.Message ID: @.***>

[mcgratta]

I am caught in an endless loop. I updated my local git qgis2fds repository, the one that lies within the Application space of QGIS. I open QGIS. I open the plugin manager. I see that the September version of qgis2fds is installed. I click on Uninstall Plugin, but get the message "Plugin uninstalled failed: Failed to remove the directory ..." I then notice that there is another directory under AppData, which might just be an alias for the one under Application. In any event, I have opened and closed QGIS and installed and uninstalled qgis2fds and cloned and recloned the qgis2fds repo endlessly, in every possible order. I'm in the Ninth Level of Hell.