Welcome and update

[Emanuele Gissi]

Welcome to this new discussion group.

Yesterday evening I committed the new qgis2fds geometric algorithm that should be much faster than the previous one by using the Python numpy lib.

The verification cases run smoothly, but if any new issue arise... it's my fault.

Let me know if it still works for you.

There was a bug in QGIS 3.14 that prevented saving the terrain extent in the QGIS case file.

QGIS 3.14.1 is out, and the issue should be fixed.

Please let me know when you update your QGIS release to 3.14.1, so that I can push the feature back.

Emanuele

[Randy McDermott]

Hi Ema,

I updated my qgis2fds repo and updated QGIS to 3.14.1.  I tried to run the attached case and it is stuck in "Draping Z values from DEM..."

Can you see if you have the same problem?

Thanks,

Randy

--
You received this message because you are subscribed to the Google Groups "qgis2fds discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qgis2fds+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qgis2fds/9e40d0ed-2b69-469f-950d-f72cad1729a9n%40googlegroups.com.

[Emanuele Gissi]

Ok, I'll check it out. 

[Emanuele Gissi]

Hi Randy,

this morning the landfire.gov server seems down.

The QGIS log says:

2020-07-23T08:59:33     WARNING    Network request https://landfire.cr.usgs.gov/arcgis/services/Landfire/US_200/MapServer/WCSServer?SERVICE=WCS&REQUEST=GetCapabilities&VERSION=1.0.0 timed out

And the website states:

Users may experience intermittent service Thursday evenings due to routine maintenance.

I will try again later.

Emanuele

[Emanuele Gissi]

Hi Randy,

The landfire.gov server is back online.

First of all, the qgz file you sent me has no project CRS. You can either:

• click on the bottom-right corner of the project window on the world-with-a-cross greyed out icon.

• or click on the Project > Properties > CRS menu

Then select a CRS for the project.

I suggest the WGS 84 (EPSG:4326).

If you leave the project CRS empty QGIS cannot properly align your layers.

The reason why the draping algorithm was waiting forever probably was that these landfire public servers seem to be protected from huge data requests, and simply stop delivering the requested data tiles.

A way to circumvent the issue is to make a local copy of the DEM and the FBFM13 data.

This subject deserves a wiki page on its own, but before starting to write, please try this:

1. right-click on the US_200FBFM13 layer in the layer panel and choose Export > Save As. I suggest saving the date in the same project directory.
2. in the Save Raster Layer panel, set the filename and the extent (larger than your presumed working area, to stay on the safe side). Leave the resolution as it is.

Repeat for DEM data.

You now have two new FBFM13 and DEM layers linked to local data.

Try again to export your FDS case.

In my laptop it takes 61s to export 718458 verts and 1433520 faces and texture; the domain is around 33x30km.

This sets the new record ;-)

Get all the files at:

https://drive.google.com/drive/folders/1V-9g0veFeVEVRNhzLM4P2pf85Yz6F4BN?usp=sharing

Cheers,

Emanuele

 

[Randy McDermott]

Ok, I will try that. 

[Randy McDermott]

Ema,

I managed to get Export terrain to finish.  I definitely think we need a wiki on this type of case.  I think it will be the norm, not the exception.

Few of other issues:

1. I kept getting bitten by "Terrain Extent".  I think this should have a default setting, maybe the Map extent is the best default.

2. I suggest more error checks that help the script fail gracefully with an intelligible error message if it gets stuck or the user has otherwise done something dumb (like I did many times).  This is far from idiot proof (me being the idiot).

3. My understanding is that things should just now run straight out of the box for FDS.  I have attached a zip for everything that I generated.  When I run this input file with the latest code, I get the attached error message (Marcos, can you see if there is an obvious issue here?)

Thanks,

Randy

 burn_scar_test.zip

[Randy McDermott]

I tried again.  Attached is a screen shot of the Terrain extent inputs before I ran.  Before setting these, I had a crash shown by the second image "Could not reproject ..."  One wrong move, and you get locked up like this.  This may have been because I had an inconsistent CRS on the burn scar layer of the texture map (?).  Whatever may cause this type of thing needs to be checked before the script starts (if at all possible)---it is hard to recover once the script gets stuck in this state, you have to kill QGIS and start again.

Nevertheless, I got it to run again and this time got past the original error (not sure why), but instead I get a seg fault in geom per the attached.

 burn_scar_test_2.zip

On Thu, Jul 23, 2020 at 4:24 PM Vanella, Marcos (Fed) <marcos....@nist.gov> wrote:

I'll check it out.

---

From: Randy McDermott <randy.m...@gmail.com>
Sent: Thursday, July 23, 2020 4:14 PM
To: Emanuele Gissi <emanuel...@gmail.com>; Vanella, Marcos (Fed) <marcos....@nist.gov>
Cc: qgis2fds discussion <qgis...@googlegroups.com>
Subject: Re: [qgis2fds] Welcome and update

 

[Emanuele Gissi]

On Thu, Jul 23, 2020, 22:14 Randy McDermott <randy.m...@gmail.com> wrote:

Ema,

I managed to get Export terrain to finish.  I definitely think we need a wiki on this type of case.  I think it will be the norm, not the exception.

Yes, surely.

Few of other issues:

1. I kept getting bitten by "Terrain Extent".  I think this should have a default setting, maybe the Map extent is the best default.

If you have QGIS 3.14.1, pull the code I committed to the repo some hours ago. It should restore the map extent saving I had removed due to the QGIS bug. I got bitten one thousand times too.

2. I suggest more error checks that help the script fail gracefully with an intelligible error message if it gets stuck or the user has otherwise done something dumb (like I did many times).  This is far from idiot proof (me being the idiot).

Please, tell me where you think I can improve the situation. Something that comes to my mind is testing project CRS existence. We are still in experimenting mode

3. My understanding is that things should just now run straight out of the box for FDS.  I have attached a zip for everything that I generated.  When I run this input file with the latest code, I get the attached error message (Marcos, can you see if there is an obvious issue here?)

Yes, the things should work straight out if the box. They currently do on my laptop verifications. I frequently update the FDS binary, but you are moving quite fast and I don't update on a daily basis. Maybe the cause.

Thanks,

Randy

On the funny side, this evening I got a fever and flu symptoms. I just got tested and it seems I am currently negative to COVID-19. Anyway it's likely that I am going to have a full week of isolated BlenderFDS dev time. Maybe a pandemic software release? ;-)

Cheers,

Ema

[Randy McDermott]

OK, I will try to update.  Hope you feel better!

[Emanuele Gissi]

I see from the screenshot that you are using the EPSG:5070 as project CRS. Please, try again setting it to plain WGS84.

(Luckily I am not that bad, just a flu for now)

[Randy McDermott]

Ema,

When I update my repo I do not see any new commits.  And I still do not see Terrain Extent default.

[Emanuele Gissi]

I had forgotten to push, sorry. I did it now.

I am now checking your files on my pc.

Ema

[Randy McDermott]

Ema,

Ok, changing the project CSR to WGS84 did it.  So, this is an example of something that should be flagged.  If it is a requirement, we check and tell the user right away.  It would make more sense to me that we would want the CRS to be consistent between the project and the layers, which were all using Conus Albers, so I chose that.

Now I'm trying to figure out how to show the texture map in Smokeview.

Thanks,

Randy

On Thu, Jul 23, 2020 at 5:11 PM Vanella, Marcos (Fed) <marcos....@nist.gov> wrote:

I reproduced the intersection issue. I don't know if the problem is with my SMV but the terrain looks like this:

I'll try to see if it is an fds terrain building issue.

---

From: Randy McDermott <randy.m...@gmail.com>
Sent: Thursday, July 23, 2020 5:06 PM
To: Emanuele Gissi <emanuel...@gmail.com>
Cc: Vanella, Marcos (Fed) <marcos....@nist.gov>; qgis2fds discussion <qgis...@googlegroups.com>

Subject: Re: [qgis2fds] Welcome and update

[Randy McDermott]

OK, here is the burn scar, which is what I was originally working on with this case.  So, this is getting there!  Thanks for putting up with my trials.

[Randy McDermott]

Ema,

I closed QGIS, updated my qgis2fds repo, reopened QGIS and loaded my project.  The Terrain Extent was populated.  I then simply clicked Run, and got the following error.  The qgz is attached.  I think there must be some variable not getting retained whenever QGIS is closed.  And in my mind, the user should not have to go through all the checks every time they reload a project.

Thanks,

Randy

[Randy McDermott]

So, if I delete the "Domain origin", then it runs.  When I then got back to the Export Terrain parameters dialog, there are now values in the Domain origin field, presumably the ones it just used to run.  Now if I just click Run again, I get the same error.

[Emanuele Gissi]

Randy,

1. This last one is a QGIS bug. When the underlying qgis2fds plugin is updated, strange behaviours appear.

I am investigating that. Close everything, delete the Python compiled files, and try again, it should disappear.

QGIS 3.14.1 is not the stable release, it's testing, so prepare for a hard ride until finalized.

2. I checked your file. In fact you can use any CRS as project CRS. I am currently exporting the case with EPSG:5070. This is why it isn't enforced.

The problem in your file was that the CRS transformations in Project > properties > CRS > Transformation were messed up. I deleted and recreated all of them.

And it worked. You probably touched that while trying to import the scar image.

3. In your file you had a terrain extent that was larger than the available local data. This is hard to check, but I'll try to do that as well. I am opening issues on the missing checks.

Don't get too frustrated, GIS software is complex and we all are newbies on that. I often have the same feeling while using new FDS features that I do not fully understand ;-)

If you open up the code, you see how complex it is to keep it as general as possible so that any data source can be used, not limited to landfire.gov

And please, open issues on further checks you suggest.

Ema

[Randy McDermott]

Don't worry. I'm not frustrated.  It is amazing to me that this is working at all.  I'm just keen to make it user friendly, and while I had some momentum in working on it, I was just throwing you all the things I could find.  If you'd prefer I open Issues, I'm fine with that as well.  We can let this welcome thread close out.

[Emanuele Gissi]

Thank you Randy, I am sometimes worried that what I code is not up to expectation.

If possible, after discussing like this, I prefer opening issues. Yesterday I already opened a couple.

Ema

[Emanuele Gissi]

Hi Randy,

following your suggestions:

1. I wrote two new wiki pages:
1. https://github.com/firetools/qgis2fds/wiki/Saving-remote-layers showing how to save remote layers to local storage
   
2. https://github.com/firetools/qgis2fds/wiki/Recovering-from-errors classifying all qgis2fds error conditions and offering hints on how to fix them
   
2. I added several new sanity checks (eg. on CRSs validity)

Now I am finishing the CERN Meyrin example wiki page.

Emanuele

[Randy McDermott]

Ema,

Great!  Thanks for your efforts.

Best,

Randy

[Emanuele Gissi]

The CERN Meyrin example wiki page is ready. I shared it with our friends at CERN and obtained their blessing.

Emanuele

[Randy McDermott]

Great, Thanks!

--

Sent from my iPhone