search

firetools / qgis2fds

An open source and free tool to export terrain elevation, landuse, and georeferencing to NIST FDS for computational fluid dynamics (CFD) wildfire or atmospheric pollutants dispersion simulations.
GNU General Public License v3.0
17 stars 13 forks source link

California terrain data appears to have a significant fault line #47

Closed mcgratta closed 1 year ago

mcgratta commented 1 year ago

Camp_Fire.zip I'm attaching a qgz file that has a few issues. I hope you are able to work with it. If not, I can send the resulting FDS files.

  1. The terrain of interest is in northern California. I am interested in a patch of terrain that is approximately 20 km by 20 km. I specify 100 m resolution in the qgis2fds script. The processing takes about an hour, which is much longer than I remember these taking the last time i did this. I am using the latest version of QGIS and qgis2fds.
  2. The resulting GEOM file contains a sizeable slash through the middle, like a very steep valley. Is this related to sewing two maps together?

image

  1. The resulting FDS file has these mesh lines: 
    &MULT ID='Meshes'
  DX=1590.34 I_LOWER=0 I_UPPER=12
  DY=1441.80 J_LOWER=0 J_UPPER=13 /
&MESH IJK=15,14,33 MULT_ID='Meshes'
  XB=-10324.12,-8733.78,-10085.67,-8643.88,-997.71,2333.29 /

    DY=X4-X3, but because of round-off, it is different by 1 cm. This is interpreted by FDS as a gap between meshes. We could fix FDS, but do you think it would be better to round XB to the nearest meter instead of centimeter?

Also, the qgz file was originally created for a patch of terrain in the eastern United States. I kept all the layers the same, and moved the patch to California. Could this be the source of the problem? That is, is this file somehow drawing in too much data from the entire US?

emanuelegissi commented 1 year ago

Hi Kevin, I'll take a look tomorrow. Ema

Il giorno ven 28 apr 2023 alle ore 21:40 Kevin McGrattan < @.***> ha scritto:

Camp_Fire.zip https://github.com/firetools/qgis2fds/files/11356739/Camp_Fire.zip I'm attaching a qgz file that has a few issues. I hope you are able to work with it. If not, I can send the resulting FDS files.

  1. The terrain of interest is in northern California. I am interested in a patch of terrain that is approximately 20 km by 20 km. I specify 100 m resolution in the qgis2fds script. The processing takes about an hour, which is much longer than I remember these taking the last time i did this. I am using the latest version of QGIS and qgis2fds.
  2. The resulting GEOM file contains a sizeable slash through the middle, like a very steep valley. Is this related to sewing two maps together?

[image: image] https://user-images.githubusercontent.com/11333911/235237132-0b661f8f-a45d-4c04-b3f7-a4f5d5bc59c7.png

  1. The resulting FDS file has these mesh lines:

    &MULT ID='Meshes' DX=1590.34 I_LOWER=0 I_UPPER=12 DY=1441.80 J_LOWER=0 J_UPPER=13 / &MESH IJK=15,14,33 MULT_ID='Meshes' XB=-10324.12,-8733.78,-10085.67,-8643.88,-997.71,2333.29 /

DY=X4-X3, but because of round-off, it is different by 1 cm. This is interpreted by FDS as a gap between meshes. We could fix FDS, but do you think it would be better to round XB to the nearest meter instead of centimeter?

Also, the qgz file was originally created for a patch of terrain in the eastern United States. I kept all the layers the same, and moved the patch to California. Could this be the source of the problem? That is, is this file somehow drawing in too much data from the entire US?

— Reply to this email directly, view it on GitHub https://github.com/firetools/qgis2fds/issues/47, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVYYJLEM2GCSUDC7HEILXDQMMJANCNFSM6AAAAAAXPUH3FE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- "When old people used to wish each other peace, we didn't understand the meaning of this word. Now we really understand." [Natalia Balasynovych, mayor of Vasilkiv, Ukraine 2022]

emanuelegissi commented 1 year ago

I opened your file on my laptop. The DEM data seems continuous, so it should be a qgis2fds problem. 20x20km is a very large terrain, the case took 27 minutes to be exported here.

Here is the bug, I can reproduce it: image

Does a smaller case reproduce the same bug? I tried to cut the domain, but the bug does not appear anymore.

image

Tomorrow evening I am going to inspect the created bingeom with BlenderFDS to rule out an FDS or Smokeview problem.

emanuelegissi commented 1 year ago

Checked with BlenderFDS image

It is a qgis2fds issue.

Now trying again to simplify the case.

emanuelegissi commented 1 year ago

I could not simplify the case and reproduce the issue. Did you somehow circumvent the issue? How?

mcgratta commented 1 year ago

I chose another location. I was just preparing a demonstration case, but decided to choose another location with steeper terrain. I'll close this case because this might be something uncommon. If it occurs again, I'll open another case. Thanks.

emanuelegissi commented 1 year ago

Thank you very much

Il giorno mer 7 giu 2023 alle ore 17:27 Kevin McGrattan < @.***> ha scritto:

Closed #47 https://github.com/firetools/qgis2fds/issues/47 as completed.

— Reply to this email directly, view it on GitHub https://github.com/firetools/qgis2fds/issues/47#event-9460901553, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMVY5WNJ3N6I3A2CJ5C63XKCMWBANCNFSM6AAAAAAXPUH3FE . You are receiving this because you commented.Message ID: @.***>

-- "When old people used to wish each other peace, we didn't understand the meaning of this word. Now we really understand." [Natalia Balasynovych, mayor of Vasilkiv, Ukraine 2022]