Dear all,
I’m using the urban cooling model (INVEST version 3.10.1) but as reported in a post now closed, to produce results it takes about 40 minutes or more each time.
I have done as suggested to delete cache but it does not improve.
Is it normal for it to be like this?
Can it be due to the high number of LULC classes (about 60)?
The processing step that takes the longest time is: geoprocessing.(2786) INFO convolution worker approximately 49.4% complete on T_air_results_UC_allCMRC 5.tif
Hi @antobaro , thanks for posting. This certainly could be normal. The runtime is dependent on the size of the input data, specifically the cell size and extent of the LULC. What are these for your dataset? If runtime is a big concern, you could experiment by resampling your LULC to a much larger cell size.
Please share more details about your input data and the logfile from the output workspace if you are still concerned something isn’t right.
The last processing took 1h47min!
(but probably the time has increased also because I was using the PC for other things)
My cell size is 10mx10m.
I don’t have the Log of this last run anymore because I’m overwriting, but I attach you the one of the run before.
In any case, I’m getting output results a bit “strange”, I’ll see what comes out with the latest changes made and if they still remain “strange” if I can, I share my input data.
Thanks for sharing your log. I expect you might see faster runtimes if you reduce the “Air Blending Distance”. Maybe you have good reason to set it at 2000 meters, but if not, the User Guide suggests 500m as a starting point. And I expect that will speedup that most long-running step in the model.
And what is the total extent of the raster? In other words, how many pixels are there? This is what mainly determines the overall runtime.
Thanks @dave Dave, with a reduced “Air Blending Distance” the model runs much faster!
I placed 2000m because by default, when I opened the window of the program was already set 2000m and because also in this article (https://www.sciencedirect.com/science/article/pii/S0169204621001262?via%3Dihub) have placed at 2000m.
Apart from this, this article in general seems to me very interesting for an evaluation of the results.
Ps.
I wrote above that the results were a little “strange”, I realized why:
simply in the biophysics table I put the values of albedo and shade in the format xx,yy while they were to be placed as 0.xxyyy (or if albedo for a lucode = 25, 05 then 0.2502), as also written in the user guide (see ratio).
Unfortunately I was based on the biophysics table provided as an example for the model (biof.table FAKE). When unzipping and opening in excel the format that appears is the first one, that is the wrong one.
Maybe it can be useful for some other user too!
It’s good to hear that it sounds like you have a resolution!
As for the format of albedo and shade values in the sample data’s biophysical table (“Biophysical_UHI_fake.csv”), I do not see the funky xx,yy format you refer to when I open this file in MS Excel. However, because this is a CSV file, we recommend reading it in a plain text editor program, such as Notepad++, Sublime, or Atom, etc. for accuracy. Often, depending on how it’s set up, Excel is known to change the display of formats and values of CSV files.