-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Urban Wind Field stuck during the process #703
Comments
Can you please share wind direction, vertical and horizontal resolutions used ? |
OK I think I have spotted where everything is getting worse (multiplying by 500 the number of geometries for nothing...), it is in the backward zone tables (TEMPO_WEIGHTED_WAKE_BACKWARD_20250116145703 and TEMPO_WEIGHTED_CAVITY_BACKWARD_20250116145703): https://github.com/UMEP-dev/UMEP-processing/blob/65b105bb04326870f306a693e5414c30bcd6baf2/functions/URock/InitWindField.py#L2117 I have to investigate if the issue is created at this SQL query or before and solve it. |
The resolution i used is 5x5 meters and for the wind direction i used the default ones: 45°. Also, with the yesterday update of the pug-in (via the repository) the pc doesn't get slowed down anymore, even tho it still takes too long and keep getting stuck on processing the 'Deals with building zones superimposition' fase, without concluding the elaboration. Dunno if this might help or not. Thank by the way! |
It helps knowing that most of the bugs are away. Remains the one you describe. The reason why it takes too long is definitely related to this multiplication by 500 lines. I will be back with a solution |
Hello!!! |
Unfortunately I could not find the time to investigate this issue yet. Hope I will find the time in the next week. |
Hello,
I was trying using the Urban Wind Field processor several times in the past few weeks, but it kept giving me error. I explained the first problem that occurred in a discussion couple days ago (here: #700), and in these days I think I got how to overcome this problem, which I explained in a comment.
Unfortunately, it worked for same area but for another one it didn't. Basically, when I run the UWF processor it slows down a lot my pc, that much that I can't even work on it, and stays like that for hours and hours. This has never happened to me. I thought it was for the size of the area, but with two other similar areas it didn't cause any other problem, it was quick. This has been happening since I updated UMEP from the repository couple days ago, when I wanted to resolve the first problem above. When this happens, I shut down the pc.
Here's the input data i used: Input data.zip
RAM 16 GB
Versione di QGIS: 3.34.5-Prizren
Revisione codice QGIS: 4b308492
Versione di Qt: 5.15.3
Versione Python: 3.9.18
Versione di GDAL: 3.8.4
Versione di GEOS: 3.12.1-CAPI-1.18.1
Versione di PROJ: Rel. 9.3.1, December 1st, 2023
versione di PDAL: 2.6.0 (git-version: 3fced5)
The text was updated successfully, but these errors were encountered: