I’m using for the first time the Urban Cooling model (with InVEST 3.9.0), and I need some help in understanding why the copy of the input vector with areas of interest shows a “nan” value for the avoided energy consumption ($).
I attach here both my inputs (shp, TIF, and tabular data), as well as all the outputs of the run. If you could, I’d also like to know your opinion on my inputs.
Apart from that, I report below a summary of my inputs including a few questions I have (in red).
Thank you so much for your help.
Marco
INPUTS:
Land Cover Map: 1m resolution
62 - Artificial surfaces and constructions
73 - Cultivated areas
75 – Vineyards/Shrubs
82 - Broadleaf tree cover
83 - Coniferous tree cover
102 - Herbaceous vegetation
103 - Moors and Heathland/Grass
Areas of interest
Green Area Maximum Cooling Distance: 10 m
Reference Air Temperature: 25°C
Magnitude of the UHI Effect: 4°C
Reference evapotranspiration: Question: here I used the average monthly Et0 for August, but then I got confused when I had to insert the Reference Air Temperature or the Magnitude of the UHI Effect. If the Et0 shows monthly value, should I multiply the reference air temperature and the M. of the UHI effect by 30 (n. of days in a month)?
Cooling capacity calculation method. I tried to use both methods, not sure which one is the best
Building Footprints Vector, with the same integer for all buildings (1)
@marco.guzzetti the absence of avoided energy consumption values in your results may be caused by the input data column headers being case sensitive. The model expects the name “cost”, not “Cost”. Have you tried changing that label to lower case and running the model using such a version of the table?
thank you both for your quick reply. I’m still working on that but I have not been able to continue. I tried to rename the column “Cost” in “cost” but nothing has changed.
Again, I really appreciate your help, and I look forward to knowing what can be done to solve this issue.
following my previous message, I noticed that by increasing the LULC area I was able to solve the issue of the “nan” values.
I also slightly modified my inputs (I attach them here). However, I still have some doubts, and I would appreciate it if you could help me.
The uhi_results_[Suffix].shp does not show any energy savings values, and I wonder why, since I included in my inputs the costs per kWh.
The buildings_with_stats_[Suffix].shp shows the energy savings values, but I don’t understand if their unit is or by kWh. If it's then those values are huge and there’s something wrong. What it could be?
I’ve read that another user had a similar problem (Urban Cool Model Valuation Results) and @jesseG told her that ““energy_sav” column actually provides results for each building in total kWh saved, or mitigated, over the entire period of interest” . How do you set the period of interest? For example, if I want to consider one year or one month, how do I tell InVEST this? That could be very relevant for et0 (if I have the annual average value shall I divide it by 12?). If I have the daily energy consumption per building type, in kWh/degC/m shall I multiply it by 30 or 365?
Thank you so much for your help, and sorry for the confusion I’ve created.
Hi @marco.guzzetti , thanks for trying to troubleshoot this and for updating us.
This makes sense. I think the critical thing here is that the extent of the LULC extends beyond the Area of Interest by at least the distance of the “max blending distance”. When this is not the case, the nodata values from the edges of the LULC seem to creep deep into the AOI during the convolution steps. (This is evident in nodata appearing in intermediate/T_air.tif). I think we may be able to improve the model’s behavior there, but for now you found a good workaround by using a larger LULC.
The User’s Guide suggests this column should be included here, but I wonder if that is simply a mistake in the documentation. I think it makes more sense for energy_sav to appear in the buildings result. @jesseG do you agree this is just a mistake in the UG?
And I’ll let Jesse also comment on your other energy_savings question since I think he’s thought about that more than I have.
Thanks for keeping this thread active. I’m sorry that my suggestion did not help.
I’m glad that expanding the LULC extent resolved the NoData issue. As Dave said, it’s important that InVEST input layers have adequate coverage. This can become especially tricky if some inputs are particularly coarse.
After reviewing results from other Urban Cooling runs, I do not find any energy_sav columns in any uhi_results_[Suffix].shp output. I agree with Dave that this is a mistake in the User Guide and I will attempt to correct it today. Thank you for bringing this to our attention and I apologize for the confusion it has caused you. However, this output does have an avd_energy_cn column which gives “Avoided energy consumption ($)”. The energy sav column is in the buildings_with_stats[Suffix].shp output and the unit is purely monetary.
As for the period of interest, the model is time period agnostic. Your energy consumption per building type values (Consumption in kWh/ degC/m^2 in the Energy_consumption.csv input) have no time element (other than what’s built-in to kWh). They simply represent how many kWh each building requires in order to cool 1 m^2 by 1 degC. How long that takes depends on the power (kW) supplied to the building’s air-conditioning. It looks like your AOI is near Vienna, Austria. Of course, no air conditioning would be needed there during winter and parts of autumn. So please do NOT multiply these values to try and account for any period of time.
However, you are correct to mention the et0 layer since this is in units of mm. The model results are given over the same time period as the input data. So if your et0 values and other inputs were over 12 months, the results would be annual too. However, your et0 values are ~130mm, so I suspect they cover <1 year. It is up to the user to know the temporal range of their input data. I recommend consulting the data sources for those metadata, otherwise I would have to research the climate near Vienna in more detail to hypothesize the date range for your inputs (such as et0). But a quick look makes me think your values may be for only 1 month or 1 season and annual numbers would be closer to ~1,000mm. So YES, the et0 layer makes sense to multiply or divide its mm by if you know its temporal coverage and over what range you want results. If you had annual average values, you could divide by 12 to get at monthly averages.
thanks again for assiting me with your critical help.
I understood everything you both said, and I tried to run again the model using the monthly average et0 for the month of August (I attach here the shp. in case you’ll need it). The rest of the inputs are the ones that I shared before.
However, I’m still not sure about the results. In my “energy consumption” table I indicated that the cost per kWh of electricity is 0.12$. The output “buildings_with_stats” shows a huge amount of money that can be saved (see picture below) and I wonder if those values are more or less acceptable or not. Also, this is the amount of $ that can be saved in one year or one month (or in another period of time)?
My goal is to understand the economic impacts that arise from the increased forest cover in my study area. Thus, my idea is to use two LULCs (a baseline and a second one with more trees) to see how the energy consumption of buildings will change.
I reviewed the inputs revealed in your Output log file (InVEST-Urban-Cooling-Model-log-2021-04-05--14_38_15.txt). Do you intend to be using the “Building Intensity” (nighttime) CC calculation method? I believe that you want to use the daytime method instead, in which case be sure to select “Weighted Factors” as the Cooling Capacity Calculation Method in the InVEST interface. Additionally, I suspect that your Baseline air temperature of 25 degC is too high. (If you really do intend to use the nighttime method, it is definitely too high and should be closer to 15 degC.) But even for the daytime CC calculation method, the Reference or Baseline air temperature value should be representative of an area where the urban heat island is NOT in effect, such as in a rural area outside the city. In other words, what would the temperature be if the city were not there? Related to this, your Magnitude of the UHI effect value of 4 degC means that if the Baseline air temperature is 25 degC, the city could reach 29 degC.
The model is not aware of a time frame. Instead it calculates savings in kWh in terms of how much energy consumption was avoided because of the presence of cooling, natural green spaces/ LULC classes based on user inputs. To get at avoided cost, it simply multiplies these avoided energy consumption values by the price per kWh you entered ($0.12/kWh in your case). To know the time period of the results, it’s critical that you are certain of the time covered by all of your inputs, as these are the same. Along these lines, I remain a bit skeptical of your new August et0 values. They may be accurate, but from my quick research I would expect the lower end of the et0 range for that month to be closer to ~65mm, not 125mm. I also think your average RH is too low for August, or for any month in Vienna, where it looks like it rarely dips below 50%.
I question your Green Area Maximum Cooling Distance of only 100m. I believe a more accurate distance would be closer to the Air Temperature Maximum Blending Distance of 500m.
You are on the right track in running multiple scenarios and then comparing the results. I have tried several runs changing the input values as I described above and have obtained lower values for energy_sav (only 3 buildings >$7,400 and all <$37,000). But, most importantly, be sure you have a clear understanding of the date range of your inputs and are confident in the time period they cover. Only then will you be able to assign the same time range to the results.
Also of note, some of these building footprints are quite large (approaching 5,000 m^2 each), so high savings values would be expected for these large buildings. I recommend vetting your inputs more closely and reviewing their metadata before committing to certain values. The results are fairly meaningless if you cannot first assure that the inputs cover the same time period as one another and that you have confidence in what this period is (length and season/month).
