clarity-h2020 / local-effects

Data for local effects calculation
GNU General Public License v3.0
0 stars 1 forks source link

Local Effects automation script #1

Closed ghilbrae closed 4 years ago

ghilbrae commented 5 years ago

There are some considerations that we are currently discussing (@luis-meteogrid ) regarding this issue. We've found two options in terms of the path to follow. One is more accurate but may pose some problems in terms of the integration with EMIKAT, and the other one has some calculation errors but will make integration with EMIKAT easier.

Preparing a script to calculate the local effects for outdoor temperature, once the process for Naples is done, seems simple. It will be useful for the calculation of those same layers for the rest of European cities, and we plan to have it implemented in two weeks.

There is no problem to produce some raster files or one or more shapes files as final product, so as EMIKAT can choose the most convenient format to use. We can also produce the intermediate layers in the desired grid and the formulae used so as EMIKAT can be able to re-calculate the local-effects directly. Nevertheless I would like to verify with Plinius (@alecapolupo ) and the Emikat developers (@humerh ) whether to work in this way or not.

The problem arise when using the European Grid instead of the original geometries. Then you have to use mean values to evaluate the value to assign to each cell, and being the formulae highly non linear the results are different if you compute the mean values of the final product or if you obtain the final product using the mean values of each layer. So, when you modify the albedo (let's say) in an area, what does it really means? I am afraid in CSIS you will be able to modify mean values obtained from the original geometries, but in such case we are not going to know which values we have to change in order to use the same script. The other option, using the mean values to obtain the final product doesn't work either, as I explained before. This problem may be solved by using the second option proposed, i.e. calculating the values from the means and thus ensuring that EMIKAT will be able to obtain the same results using the same formulae. The only drawback are the already mentioned calculation errors.

To avoid synchronizing problems and adding an extra layer of complexity, we think that if we go for the second option, the best approach would be to perform all calculations inside the CSIS taking advantage of EMIKAT's ability to do calculations. This way we could calculate all Local Effects for all European cities selected. We would later make available all variables for EMIKAT to consume and the formula.

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

@humerh Has a final decision been taken? As we intended in a 1st attempt to just change land use distribution per grid cell for HC-LE recalculation in an adaptation scenario, does this offer any simplification?

humerh commented 5 years ago

No, I have implemented the calculation of adptation option in a way, that either the land use distribution as well the parameters (albedo,...) can be modified.

I expect a "table of modifications", which will overlay the base layer grid. Only the modified cells have to be given;

You can get the raster for baseline by this call:

https://service.emikat.at/EmiKatTst/api/scenarios/2846/feature/tab.CLY_HW_GRID_DETAILS.1856/table/data

and you can update the modified table by POSTing them to this address:

https://service.emikat.at/EmiKatTst/api/scenarios/2846/feature/tab.CLY_HW_GRID_DETAILS_PROJ.1856/table/data

ghilbrae commented 5 years ago

It seems it has already been agreed the way of we both using the same formula. @humerh if you consider this solved please close the issue.

ghilbrae commented 5 years ago

As discussed during the Plenary Meeting, it is important for all of use to use the same algorithm for the Local Effects calculations.

PLINIVS (Mattia & Giulio), we'd like to have your current version of these calculations, we don't care about the programming language in which it has been written (you told us it is in SQL and this is fine by us). Once we have this we'll verify our own and provide Heinrich with an updated version.

ghilbrae commented 5 years ago

@alecapolupo can you please redirect this issue to Mattia or Giulio, it's been a week and we have no answer. Thanks!

ghost commented 5 years ago

Dear Angela,

I dindn't reply because I'm waiting for Giulio and Mattia's response. I cannot take a decision without them. Best, Ale

ghilbrae commented 5 years ago

We know, that's why we wondered if you could send the issue their way because they do not seem to have github users. Thanks!!

ghost commented 5 years ago

Giulio is on holiday, so we should wait until he returns.

ghost commented 5 years ago

@ghilbrae @luis-meteogrid

we have just uploaded the word file related to flooding local effect computation (https://newrepository.atosresearch.eu/remote.php/webdav/CLARITY/WP3%20Science%20Support/T3.2%20Climate%20Intelligence/Flooding_screening.docx). Unfortunately, prof. Zuccaro is on holiday and we haven't had the time to discuss it but I'm sending it to you so that you can start to have an idea about the procedure to implement and to let us know your observations.

humerh commented 5 years ago

From my point of view this issue is still solved for many weeks. Why isn't it closed? What do you expect fromme to contribute?