Height correction for the temperature?

DenoBeno commented 4 years ago

Why don't we apply the height correction to our temperature model? should be 0.65K/100m according to http://meteorologytraining.tpub.com/14312/css/14312_47.htm

That's quite a lot, actually.

In Venna we have 300 m difference between lowest and highest points. I suppose it will be 100-150, for the urban part of the city (1°C difference), the rest is just woods.
In Naples it's 0 to 453m according to Wikipedia, not sure about the urban part. but it could be 1 to 1.5°C difference in apparent temperature just for this reason.
In Salzburg, the study area can be on top of the hill at 2000m. Not very useful (no people there), but our predicted temperatures will be off by >10 °C there and that's embarrassing, no?

DenoBeno commented 4 years ago

Just had a look at https://de-de.topographic-map.com/maps/7is7/Neapel/ - some suburbs are at 200m.

In Vienna, the lowest parts of the urban area are at 150m, the highest around 250.

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

Is the information on elevation available in our HC-LE input layers? If not, could it be generated e.g. from SRTM data? We would just need the average height in a 250x250 grid cell, right? So that's one new grid layer with elevation information. This could directly be stored in EMIKAT, right?

humerh commented 4 years ago

I think, the most influencing data to the current model ist the air temperatur of a specific grid cell. We do the calculation with a fixed temperature, which comes from the Event definition. The definition of the event assumes a specific temperature for a specific duration for all cells of the study area. NO REAL temperature distribution for a specific day is used.

This definition is independend of elevation. Having 38°C on sea level is handled the same as an event with 38°C on 600m (like Madrid)

RobAndGo commented 4 years ago

I think the method proposed by both @DenoBeno and @p-a-s-c-a-l is sound.

The original surface temperatures from EURO-CORDEX are on the coarse 10km x 10km grid, and the surface height of this grid box will be the average of all elevations within this box (_Havg). For example, I used these temperatures for the three heat wave event classes (frequent, occasional, rare).

Now, when the temperatures are applied to the downscaled ~250m cells, the temperature has to be adjusted for the different elevations at a rate of 0.65K/100m. This will result in lower temperatures for points which lie above _Havg and higher temperatures for points which lie below _Havg.

This means that, although some parts of the area will be cooler, there will also be parts which become hotter.

New text: Actually, since this calculation is done for midday conditions with maximum solar radiation, the temperature decrease with height would not be 0.65°C/100m but rather the steeper dry adiabatic lapse rate of 1°C/100m, particularly for elevations below about 1km in height. This represents the depth of a convectively-mixed boundary layer typical on summer days. Above the boundary layer height of 1km, a more sensible temperature decrease would be the rate of 0.65C/100m.

DenoBeno commented 4 years ago

That makes sense, yes. In many cases it will not matter, but it will matter if there are some hills around. E.g. the temperature could become higher in Salzburg and Innsbruck, while getting colder on surrounding hills.

E.g., here is an extreme example:

Sankt Gilgen is at 545m, the hilltop on the east is at 1777m. :-) The average height in that area is what? 800m? 1000?

Even better: Innsbruck is at ca 600 m, Sistrans at c. 1000. Very vertical area... Temperatures in the south (hills) should be lower than in the north (valley).

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

Discussion continues here.

clarity-h2020 / emikat

Height correction for the temperature? #28