Spatial thermal comfort (PET) is taking a very long time

[harmen6464]

Compared to my previous PET simulations, my PET simulations in the Spatial Thermal Comfort (port-processor) are taking a very long time for this area. The previous (of a bit smaller area, around 100 by 200m) took about 1 minute, however for this one I am already waiting for an hour with no visible progress. Is also noticed for this area that the MRT simulation took much longer. The extent of the rasters is about 460 by 540m with a resolution of 0.5 by 0.5m for MRT and 1 m by 1 m for the URock. Is it normal that it takes this long, or is there something wrong? I can share the data personally by email via Wetransfer.

[biglimp]

PET-calculation happens pixel by pixel so it might be slow depending on number of pixels investigated. The speed of the model depends on your settings. If you use anisotropic sky, it is slower. Also if you include vegetation. Also remember that the complexity of the model is O^n meaning that a double size modell domian is not double as slow to calculate but 4 times as slow.

[harmen6464]

Thank you for your reply. In this scenario, I was not using any vegetation. I left it for around 6 hours but after that it was not even showing a progress percentage. Is there a way to personally send you my data so you can have a look (if you'd want to do that and have the time of course)?

[biglimp]

First duoble check if you have any nodata values in your tmrt and wind speed maps. THat can be the reason why this is happening. @nilswallenberg , did we do some changes regarding the PET-calcualations, recently? @harmen6464 , have you updated UMEP recently?

[harmen6464]

I will check, I think the nodata values could be the issue here, although my other areas also had nodata values and it did not cause any trouble there... I will be busy with other things the coming days, but if I have time I will try to recreate the entire area but without nodata values, as a perfect rectangular area, to see if that works.

[harmen6464]

@biglimp I noticed that something strange happened in my urock output. Most of the buildings were recognised by urock from the input building layer and given a nodata value, but some buildings, especially buildings that were directly connected to other buildings with another height, were not considered as nodata and given wind speed 0 instead. I think this could be a problem, do you have any experience with this?

[j3r3m1]

Did you try the most recent URock version ? Because there was a mistake in previous versions that may have lead to this issue. If still do not work can you share the data ?

[harmen6464]

I have tried again with updated urock version, same outcome. I have just sent you my data per email in a wetransfer link.

[j3r3m1]

Hi Harmen,

I did not save your data and do not have access to the link any longer. However, I have seen that you do not have not selected any RASTER_OUTPUT which is needed to convert the URock output into the Solweig raster frame. Could you please:

1. try the URock calculations with:

   • the RASTER_OUTPUT input set with the SOLWEIG output raster,
   • the horizontal resolution at 3 m (2 m if a lot of your streets and buildings are very narrow < 4 m)
   • the vertical resolution to 2 m

2. if not better could you please resend the data to me l will download it and try as soon as possible

[harmen6464]

Hi Jeremy,

Thank you for your reply. I have just tried it with a 2x2m resolution and with the SOLWEIG output as input for the RASTER_OUTPUT. URock is now running much faster than last time. However, I am running into this error (which I haven't seen before). It occurs at this point (according to the Python console), so after the iterations finished:

Iteration 298 (max 500)
eps = 0.000107 >= 0.0001
Iteration 299 (max 500)
eps = 0.000104 >= 0.0001
Iteration 300 (max 500)
eps = 0.000102 >= 0.0001
Iteration 301 (max 500)
Time spent by the wind speed solver: 66.66420006752014 s
Rotates geometries from -140.0 degrees

I am using UMEP for processing 2.1.17 on Windows 11 Pro.

QGIS version: 3.40.5-Bratislava
QGIS code revision: 8d6d1b5448
Qt version: 5.15.13
Python version: 3.12.9
GDAL version: 3.10.3
GEOS version: 3.13.1-CAPI-1.19.2
PROJ version: Rel. 9.6.0, March 15th, 2025
PDAL version: 2.8.3 (git-version: 56e405)
Algorithm started at: 2025-04-28T16:08:19
Algorithm 'Urban Wind Field: URock v2023a' starting…
Input parameters:
{ 'ATTENUATION_FIELD' : '', 'BUILDINGS' : 'C:/Users/h.severiens/OneDrive - Merosch/Documenten/De Grote Modelvergelijking/Lelystad/gebouwen.gpkg|layername=gebouwen', 'HEIGHT_FIELD_BUILD' : 'hoogte', 'HORIZONTAL_RESOLUTION' : 2, 'INPUT_PROFILE_FILE' : '', 'INPUT_PROFILE_TYPE' : 0, 'INPUT_WIND_DIRECTION' : 140, 'INPUT_WIND_HEIGHT' : 10, 'INPUT_WIND_SPEED' : 5, 'LOAD_OUTPUT' : True, 'OUTPUT_FILENAME' : 'urock_output', 'RASTER_OUTPUT' : 'C:/Users/h.severiens/OneDrive - Merosch/Documenten/De Grote Modelvergelijking/Lelystad/Lelystad_extra/mrt_output/veg0/Tmrt_average.tif', 'SAVE_NETCDF' : True, 'SAVE_RASTER' : True, 'SAVE_VECTOR' : True, 'UROCK_OUTPUT' : 'C:\Users\h.severiens\OneDrive - Merosch\Documenten\De Grote Modelvergelijking\Lelystad\Lelystad_extra\urock_output\urock_output_poging2', 'VEGETATION' : None, 'VEGETATION_CROWN_BASE_HEIGHT' : '', 'VEGETATION_CROWN_TOP_HEIGHT' : '', 'VERTICAL_RESOLUTION' : 2, 'WIND_HEIGHT' : '1.5' }

Writing settings for this model run to specified output folder (Filename: RunInfoURock_YYYY_DOY_HHMM.txt)
Initiating algorithm
Creates an H2GIS Instance and load data
Creates the stacked blocks used as obstacles
Rotates obstacles to the right direction and calculates geometry properties
Roughness zone properties are:

• z0: 1.8445960589870325
• d: 7.769611282760905
• Hr: 19.00533633334219
• H_ob_max: 51.0
• lambda_f: 0.09705674378153194
  Creates the 2D Röckle zones
  Creates the 2D grid
  Initializes the 3D grid within Röckle zones
  Deals with building zones superimposition
  Deals with vegetation zones superimposition
  Initialize the 3D wind in the grid
  Rasterize the data
  Apply the wind solver equations
  Iteration 1 (max 500) - eps = 0.694172 >= 0.0001

Iteration 51 (max 500) - eps = 0.019008 >= 0.0001

Iteration 101 (max 500) - eps = 0.00723 >= 0.0001

Iteration 151 (max 500) - eps = 0.00244 >= 0.0001

Iteration 201 (max 500) - eps = 0.000847 >= 0.0001

Iteration 251 (max 500) - eps = 0.00029 >= 0.0001

Traceback (most recent call last):
File "C:\Users/h.severiens/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\UMEP-processing-main\processor\urock_processing_algorithm.py", line 454, in processAlgorithm
MainCalculation.main(javaEnvironmentPath = javaEnvVar,
File "C:\Users/h.severiens/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\UMEP-processing-main\functions\URock\MainCalculation.py", line 811, in main
saveData.saveBasicOutputs(cursor = cursor , z_out = z_out,
File "C:\Users/h.severiens/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\UMEP-processing-main\functions\URock\saveData.py", line 162, in saveBasicOutputs
saveRasterFile(cursor = cursor,
File "C:\Users/h.severiens/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\UMEP-processing-main\functions\URock\saveData.py", line 437, in saveRasterFile
ds = Open(tmp_file)
^^^^^^^^^^^^^^
File "C:\OSGeo4W\apps\Python312\Lib\site-packages\osgeo\gdal.py", line 9192, in Open
return _gdal.Open(*args)
^^^^^^^^^^^^^^^^^
RuntimeError: C:\Users\H36BA~1.SEV\AppData\Local\Temp\interp_before_fillna.tif: No such file or directory

Execution failed after 132.94 seconds (2 minutes 13 seconds)

Loading resulting layers
Algorithm 'Urban Wind Field: URock v2023a' finished

[j3r3m1]

You did not get this error in previous URock run ? Super strange. It is actually due to "." in your temporary file path that were not well taken into account in URock. It is now solved in version 2.1.20. Can you please let me know if works for you (and in this case closing the issue).

[j3r3m1]

Please try with jpype1 instead of jpype

[harmen6464]

Thank you! I managed to install jpype1 1.5.0 now, but when I tried to run Urock it closed QGIS around iteration 300...

[j3r3m1]

Strange since this library is not used in the iteration process. Can you try with jpype1 version 1.5.1, 1.5.2 and 1.6.0 (if exists) ?
If no better please share your dataset (the URock configuration also)

[harmen6464]

I have tried the same simulation 3 times each with version 1.5.0, 1.5.1, and 1.5.2. Version 1.6.0 does not exist. Results: all runs with 1.5.0 and 1.5.2 were completed without problems, every run with version 1.5.1 closed QGIS instantly. Somehow ironic that 1.5.0 now seems to work perfectly fine, like 1.5.2...