Tmrt calculation script

ghilbrae commented 5 years ago

We've just uploaded a script to make a preliminary calculation of Tmrt, it is in its own branch tmrt-calculation for now.

Here's the link to the folder: https://github.com/clarity-h2020/local-effects/tree/tmrt-calculation/LE_scripts

The script is written in python3 but it should be clear enough for you to understand what we are doing. We are mostly following what's in the spreadsheet @alecapolupo sent, though we had to improvise some things. For example, there are no indications of which are the radiation fluxes we should use, in this case we've just created our 6 following what's there and making an educated guess about which of them would be involved in each of the six. Note that we've decided to interpret this six as: above, below, South, North, East, West.

@alecapolupo you should check the script and confirm that our calculations are correct, we tried to follow the same naming conventions you used on the spreadsheet.

@humerh we've used a JSON file to store some parameters, but also hardcoded or randomly generated some data in the script. These data should come from some DB or the CSIS or any other place you or EMIKAT has the information, but for the purpose of trying to go forward and start getting results it seems like a good option for a first version.

ghost commented 5 years ago

Hi @ghilbrae,

I will check the script as soon as possible. I sent the papers related to the model to Luis some months ago, so if you have any doubts in understanding it, you can check them. Is this script the same that Luis applied to compute the local effect?

luis-meteogrid commented 5 years ago

Hi @alecapolupo This is not the same script we used to compute the local effects some months ago. This new one take into consideration the last modifications you sent us in order to take into account all possible directions for the incident energy flow (alongside with some assumptions we had made to fit the idea better) and most important this new one does not use the original geometries of the vector files for the computation but the percentages of 'occupancy' percentages of each layer for the European grid cells. This is why we would like to check with you the algorithm. Should you have any problem following the description of it, we can arrange a brief skype meeting (maybe this week) in order to clarify and agree about the assumptions we have made.

ghilbrae commented 5 years ago

We have just updated the script and some parameters to see if we can get better results. They can be accessed in the same branch as before: https://github.com/clarity-h2020/local-effects/tree/tmrt-calculation/LE_scripts

If you want to see the changes, check the commit: https://github.com/clarity-h2020/local-effects/commit/44861d7885d51cf90e8cd202e53f1ec8118e4b6e

@alecapolupo we really need you to check the script and let us know if the approach and the changes we've made make sense. As we've pointed out, the information on the excel is not complete in some regards and we've also made some assumptions we need you to approve as you understand best the meaning of it all and can point out the best options in terms of formulas and parameter values. @luis-meteogrid is going to explain these assumptions here to complement the script.

luis-meteogrid commented 5 years ago

Hi @alecapolupo, hi @humerh, hi @negroscuro As @ghilbrae remarks on the last comment, we have made some assumptions over the algorithm described in your excel file. Some of them arise when using the formula as there were just two different K and L directions in the description section, while 6 in the formula to obtain the final flux. We have interpreted the terms in order to figure out which direction was related with and settled down the different fluxes accordingly. Then we have check every parameter influenced the equation in the expected way, making minor changes to suit the vegetation_shadow in order to lesser the Tmrt calculation when it is higher. Other assumptions arise when trying to use the algorithm you gave us with the information that can be stored in a cell instead of using the original geometries. We have some issues to figure out how to manage intersections when we just have percentages of occupation for the layers for every cell, and even if we tell ATOS to store a lot more parameters in order to compute a suited flux, it is difficult to imagine how these intersections may change when applying an adaptation option. This problem is related with the computation of hillshade_building and with Building_shadow. Some other questions are: Do raillways be affected by Urban Fabric and thus have a hillshade_build value as roads? For now we are working with green factor equal to 0.37. But do we have to prepare the algorithm to be able to treat 17 different types of trees in each cell? the percentage of occupation of each one of them would be needed and consequently the calculation would be slowed down to be able to use it 'on-line'. Before making a decision, we would like to discuss it with you and with Heinrich to verify that the solution adopted is the most appropriate considering the environment of the tool we are working with.

luis-meteogrid commented 5 years ago

Hi @alecapolupo In regards to floods we also have some doubts to generate the script that can be used by @humerh. There are no issues with the Run-off C parameter, but we don't know which the definitions for the FUA_tunnel computations come from. As far as we know there are no layers of very low urban fabric or isolated, are these somehow to be calculated? Moreover we are concerned with the values of Basin Area Ab, length of flow L and Altitude z. ¿How are you planing to inform this values at a cell resolution? (take into account that several different basins may be present in a cell)

humerh commented 5 years ago

Clarity

I adapted the parameters. This is the new result. For Ta=38°C the resulting Tmrt is in the range of 60° - 90°C. Isn't this a little too high ???

ghost commented 5 years ago

Hi @luis-meteogrid,

regarding the flood, we are creating a word document in order to explain all the procedure, partially described in D3.2, in details. No layers related to "very low urban fabric" or "isolated" should be created since to simplify the procedure we have aggregated the urban fabric in three categories "low", "medium" and "dense". Those layers have been generated by @negroscuro.

p-a-s-c-a-l commented 5 years ago

Isn't this a little too high ???

Seems so. @RobAndGo What do you think?

RobAndGo commented 5 years ago

That is a good question regarding whether the values of Tmrt are realistic or not. I do not have any personal experience as to what "typical" values of Tmrt are. Here is one result from the literature:

In a case study (P196fullpaperMohamedMahgoub.pdf) from Cairo (latitude ~28°N), measurements from 9 different locations (represented by the different curves) within the city yielded the following Tmrt values during the day (29 June, 1 July):

The corresponding air temperature for each location is shown here:

The characteristics of the locations are described in the table:

and what the locations actually looked like are shown here:

The meteorological conditions were "clear, hot and calm summer day" with maximum temperature of 34.8 °C (29 June) and 36.6 °C (1 July). Note that they give wind speeds of "mean wind speed of 16.1 ms and 21.3 ms" which contradicts their description of "calm summer day" (21.3ms = 77km/h!), so I guess there is an error there.

Based on photos (e.g. 6, 9) which look similar to urban layouts in the old part of Naples, these curves would represent maximum values that can be observed in Naples, given that the latitude of Naples is 40°N (Cairo is at 28°N). That is, the highest values of Tmrt may not exceed 70°C.

RobAndGo commented 5 years ago

Another study (484_2017_Article_1332.pdf) concerns by how much Tmrt will change in the future for 3 European cities (Gothenburg, Frankfurt, Porto). They do indeed show that for the baseline climate, Tmrt does exceed 60°C, and will exceed 60°C in the future.

Specifically, with the following plot they show the number of hours per year where Tmrt > 60°C.

Specific values are shown in the following table:

RobAndGo commented 5 years ago

So in summary, I would suggest that the Tmrt values from Cairo at an air temperature of ~36°C would represent a maximum value for southern European cities, i.e. we should expect Tmrt values for Naples to be Tmrt < 70°C. Given that Porto does get values above 60°C for only 20 hours in a year at present would suggest a reasonable upper limit for Naples to also be around 60°C.

The Tmrt values that @humerh presented were for an air temperature of 28°C - perhaps maximum values of Tmrt around 50°C at this temperature would be more reasonable.

luis-meteogrid commented 5 years ago

Hi @RobAndGo I have been using the two papers @alecapolupo sent us, among others:

A Framework for Outdoor Mean Radiant Temperature Simulation: Towards Spatially Resolved Thermal Comfort Mapping in Urban Spaces (Tarek Rakha1, Pouya Zhand and Christoph Reinhart)
SOLWEIG 1.0 – Modelling spatial variations of 3D radiant fluxes and mean radiant temperature in complex urban settings (Fredrik Lindberg & Björn Holmer & Sofia Thorsson)

The first one show higher temperatures that the ones on El Cairo for Syracuse (NY, USA)

MRT simulation of Downtown Syracuse NY USA in representative summer days of June 20th with an intermediate sky cover and July 4th with a clear sky condition. As you can see temperatures can reach more than a 100C at noon. On the second one, the analysis goes through Goteborg reaching just 58C As Solweig 1.0 is an open source tool we were thinking it may be a good way to assess the reliability of our script, the only problem being who would be able to run the tool in a proper way.

p-a-s-c-a-l commented 5 years ago

Tmrt results can be validated with those from DC3 Linz Modelling studies that are using Grasshopper, Rhino, Envimet. Please contact @toetzert for more details.

ghilbrae commented 5 years ago

It was agreed during a dedicated meeting to do the validation of the results using MUKLIMO and SOLWEIG.

It will be carried out by ZAMG, PLINIUS and METEOGRID. One of the expected results is to finally agree on a formula to use. For now we are using a temporary formula but we do not expect it to change much in its final form and it should not be a problem as it already produces results.

ghilbrae commented 5 years ago

We are closing the issue now and will update or create a new one for the new formula.

ghilbrae commented 4 years ago

Hi,

As per the 21st of June comment https://github.com/clarity-h2020/local-effects/issues/8#issuecomment-504346001 this is the script we sent to @humerh, please let us know if you modified it in some way on your side and send us the latest version.

@mattia-leone @stefanon you can check the link to the script in the comment already mentioned and let us know your comments. You can also check the following comment to that one in which @luis-meteogrid (21st June) provided some more information on the approach we took.

stefanon commented 4 years ago

Thanks, this is very useful for checking the Tmrt calculation and differences in implementation.

luis-meteogrid commented 4 years ago

In addition to this, we must agree on the methodology to generate the layers of urban fabric structure from the information from the urban atlas and another source so that @negroscuro can finish calculating the input layers. ¿Do you already have a suggestion @mattia-leone ?

negroscuro commented 4 years ago

In addition to this, we must agree on the methodology to generate the layers of urban fabric structure from the information from the urban atlas and another source so that @negroscuro can finish calculating the input layers. ¿Do you already have a suggestion @mattia-leone ?

@luis-meteogrid it is being discussed here: https://github.com/clarity-h2020/data-package/issues/59

RobAndGo commented 4 years ago

Hi @ghilbrae Regarding your post above, I had a quick look at your python script. Just a comment, do you need to convert the angles theta, eta from degrees into radians before using them within the trigonomic functions sin, cos?

Further, in the line: K_l1 = I * (Sb - (1 - Sv) * (1 - tau)) * math.cos(eta) I think it should read: K_l1 = I * (Sb - (1 - Sv) * (1 - tau)) * math.cos(eta) * math.sin(theta)

And in the line: L_2 = (2 - phi_v - phi_b) * sigma * epsilon_wall * Ts**4 I think it should be: L_2 = (2 - phi_v - phi_b) * sigma * epsilon_wall * Ta**4

And in the line: L_3 = (-phi_v - phi_b) * sigma * epsilon_wall * Ts**4 I think it should be: L_3 = ( phi_v - phi_b) * sigma * epsilon_wall * Ts**4

RobAndGo commented 4 years ago

OK, now I have found the reference from which the radiation model is based, namely this one: Lindberg & Grimmond, 2011 "The influence of vegetation and building..."

humerh commented 4 years ago

I am happy, that we now review the implemented script in a broad discussion.

Last week I sent this evaluation notice to Mattia and Stefanon. You find also the implemented formula in this document and the way to get intermediate results directly from EmiKat. 20191212Evaluation of formulas for the Study area.docx

stefanon commented 4 years ago

Please find here: https://github.com/clarity-h2020/local-effects/blob/tmrt-calculation/hw_localeffect_tmrt_v2.sql the script with the updated formula for Tmrt calculation as discussed in today WP3 Technical Meeting.

RobAndGo commented 4 years ago

Thank you @stefanon. I inserted the equations from the code into the excel spreadsheet that @humerh produced some time ago, and I get realistic values - i.e. for Ta=38°C, Ts=60°C, Sv=1, I get T_mrt=55°C

Models - Local Effect 17_01_Calc_rg.xlsx

The big change for me is the correct separation of the short-wave radiation components in the cardinal directions.

stefanon commented 4 years ago

This is a good news, thank you for testing! With the routine calculations applied to Naples, with local scale data, results now appear to be at least 'consistent' with expectations and temperature range (see image, Ta=36°C Ts=f(Ta)):

stefanon commented 4 years ago

A thing to taking into account doing Tmrt calculations, as discussed with @negroscuro here:

https://github.com/clarity-h2020/data-package/issues/59#issuecomment-566985221

is to check not using input parameters with 'null' values in the Tmrt formula.

negroscuro commented 4 years ago

From my side parameters are there and no null values are delivered regarding parameters of land use layers. Regarding altitudes there coudl be null values if altitude could not be calculated for any reason (like having no DEM data for a cell or having no Basin for a cell, etc...)

clarity-h2020 / local-effects

Tmrt calculation script #8