-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for adaptation options calculations #154
Comments
After yesterdays discussion, I have a better Idea how to proceed with this. First, we need change in the "cost" field of the adaptation options. There, the three cost fields need to be replaced with numeric fields (price pro m^2). This is easy, but we also need to change a presentation in all views to accommodate these three new fields and then drop the old ones. @stefanon, @mattia-leone : I hope that I can change this later today. Once the fields are available, PLINIUS will start filling in the data. All values will be in €, valid for Italy (we need to inform the user about this and also to think about transforming this to Austria or Sweden later.)
Next is to define a new node or taxonomy type that will be used to define "adaptation strategy". Something like this:
Each adaptation strategy defines one or more adaptation options applied to one land use category. E.g. "apply cool roofs and green walls on 50% of the residential middle density houses". I am not 100% sure what exactly is needed in this node, so [I have opened a ticket for this] #155).
Third part is to add "Adaptation Options: Appraisal" step where user can choose one adaptation option strategy for each land use. They don't have to choose adaptation strategy for each land use category - those that aren't set are implicitly set to "no adaptation option". I'm thinking of some table where users can choose this. The simplest solution would be to replicate what we already do for adaptation options on https://csis.myclimateservice.eu/study/25/step/3686/view/table. The problem here is that nothing prevents the user to choose several conflicting options. Better solution would be a table listing all land uses in the first column and allowing the user to choose the adaptation strategy in the second, plus having some information about this strategy shown in the third column. @patrickkaleta , @fgeyer16, do you have some bright ideas on how to do this? (I'll probably open new ticket to decide on how exactly to do this.) @humerh : this makes it clear what EMIKAT can get from CSIS. A list of "strategies" to apply. Each strategy is linked to its description, and then to individual adaptation options. There is no explicit geometry, just the geometry of the project. The difficult part is that EMIKAT would have to choose where to apply the the "strategy". E.g., if the strategy is to apply something to 50% of the houses, preferably in the "cells with high mortality", then EMIKAT would needs to find how many houses are in the project, find the cell with highest mortality, apply this to all houses in this cell, find the next highest mortality cell, apply there and so on - until 50% mark has been reached. This sounds too complex to me, we need to re-design this somehow. @ALL, any ideas?As for the cost calculations, I don't know what we have at a table today, if anything. @mattia-leone , @stefanon How are we (going to) calculate the cost of the crisis? @humerh , @patrickkaleta: is anything already designed or implemented in this direction? Finally, we will need something similar to what is already shown in risk/impact and ideally a possibility to compare a situation with/without adaptation options. Which reminds me that we'll have to calculate the cumulative costs over N years, not just costs of a single event. Any comments/sugestions? |
Dear all, I am a bit lost. Everything was clear at the time of my last meeting with Denis about how to calculate the effect of adaptation, using "strategies" instead of single measures, and working with the land use percentages. |
about adaptation cost calculations, we have a very complete set of data about this. |
I changed the cost fields, so you should be able to now insert specific values for development, retrofitting and maintenance costs. Remaining changes to the data structure will be done after the initial release of the CSIS, because such changes always affect the content synchronization between Development site and production site, which I want to keep at a minimum before the initial release. Just one question, so that I can add a correct description to the cost fields. Is the maintenance cost calculated on a per-year basis or for the entire estimated lifespan of the adaptation option? |
I see that Partrick has changed the cost fields in adaptation options, but the old fields (and not the new ones) are still shown everywhere. I will open a new issue for this and proceed with fixing the views. (should be OK now) |
The interface to the REST interface, including adaptation options is included in the Wiki page: The new views for cost reports will also be documented there. |
CSIS is now able to show the results for the Adaptation option calculations in the Map and Table component. The Adaptation Strategy selected by the user is linked with the study_variant keyword So, depending on the currently selected Study scenario, the Map and Table components will pull the results for either the baseline scenario or the adapted scenario from Emikat. Example: https://csis-dev.myclimateservice.eu/study/25/step/3682/view/table (selecting either "worst case, 20y, adapted" or "worst case, 20y" will show different results. |
Ideally, we can decouple the study_variant from the Study Scenarios, so that it could be possible to show in the Map component the differences of the Study scenario with and without Adaptation options side by side (we already have the split screen with two maps, so we should use it). @therter let's maybe discuss this in a short telco to see how feasible that would be for us in the remaining time. |
Another thing, we need to check the plausibility of the adaptation options calculations.I'm afraid currently it's not quite what we are looking for. For example see these two layers for the "Local effect mean radiant temperature": Otherwise, the selected Study scenarios are the same (same time period, RCP...), so the "with adaptation options" layer should show less red squares and not more. Also, in the Table , the adapted scenario shows higher temperatures: @humerh and @mattia-leone can you please have a look at the current results produced by Emikat for the Adaptation options calculation? It seems that right now, applying our adaptation strategies only make things worse in the end. |
@mattia-leone and @stefanon FYI: For comparison: As can be seen in the tables, T_MRT, T_UTCI and T_A are on average slightly higher in the adapted scenario. |
@mattia-leone has told me today that they have found some error in calculation. Didn't get it exactly, but it could be that we are multiplying the values of old parameters with new ones instead of replacing them. |
Hi @patrickkaleta , did you check Martina's email? It relates with what @DenoBeno says. Actually is the opposite, before we put "multiply value" for the Ts parameter, which is wrong (and that could explain the higher values in the adaptation), while now Martina corrected this with "replace value" P.S. working on the impact stuff, hope to send what agreed in the telco over the weekend |
Hi @mattia-leone, yes I've read her mail. We will deploy her changes to the live CSIS soon (I'm assuming today or tomorrow) and then we can see how that affects the calculations for the adaptation options. |
The changes made by Martina have been synchronized onto our PROD system and I triggered the Emikat calculation again. Looking at the results, I don't see any changes. However, I noticed that the AO Effects taxonomy has some problems. Some effects are included multiple times: I double-checked with the DEV instance, to make sure that those duplicates weren't caused by a faulty synchronization into PROD, but these duplicates already existed on the DEV server before. I didn't check all of them, but for instance the Surface temperature = 1.27 effect is in the system twice and one of them still uses "multiply" instead of "replace value". Therefore, it's possible that Emikat is still supplied with wrong parameters, which lead to wrong calculation results. @mattia-leone and @martinapizzicato please check again all the AO effects and remove unnecessary duplicates. An AO effect only needs to be included once in this taxonomy and then it can be referenced multiple times in different AOs. And make sure that the AOs then reference only the remaining (and hopefully correct) ones. |
Us example calculation was made in Naples on calata capodichino street, near the airport. |
Guys hope you can fix all this. At the moment I am working in finalizing D2.4 by Friday August 7th, since after that PLINIVS team will be on vacation and won't be available anymore until the end of the project, except answering the phone and reading emails from time to time. |
You can also check AO calculation on this map. Left is without AO, right side is with this adaptation strategy applied. |
I guess that the most important thing is to have our toy working for the final review. About this, you can count on our support in September of course. |
@mattia-leone Sorry, EMIKAT calculation is disabled on CSIS-DEV, you have to https://csis.myclimateservice.eu. But I don't know if we have already the latest version of CSIS-DEV published on CSIS @patrickkaleta ? |
ah ok, actually I supposed so, but saw Denis' study on Vienna with all the adaptation steps included, so I thought it was ready also for Napoli. Let me know if we can make it, as said I have time until Friday, then again in September to support final review preparation (which is much more important than deliverables when it comes to the CSIS!!) |
No, not yet. I think it will be available later today or tomorrow. Currently I'm testing the updated Group module after discovering this issue yesterday. The two Views in question have already been fixed, but since the Groups module plays such a major role in the CSIS I need to check the other Views as well, which might not all be covered by the CI automated testing. |
Synchronization from DEV to PROD is done, but I wasn't able to synchronize our GL-templates and the Study types (see #184 for details). @mattia-leone nonetheless you should now be able to check the adaptation strategies in Napoli. I created this Study on PROD and made you the owner of it. Let me know if you have any troubles working with it. |
Hi Patrick, just read the message. I have now triggered the calculation and waiting for the results. |
apart from the holes, I think the flood local effect is not correct. It displays red cells up on the hill, while it should be the opposite. @stefanon maybe @patrickkaleta and/or @humerh have inverted the classification of some layers? |
also here right map panel does not display results.
I see also some mismatches in the layers that are visualized here.
Risk/Impact maps should be limited to:
- Mortality rate increase (Heat Waves)
- Outdoor discomfort (Heat Waves) - I think you named the layer "Heat Waves impact" as from the impact calculation discomfort.doc.. my mistake I think it's more clear if we name it like this
- Economic impact on roads (Flood)
- Economic impact on residential buildings (Flood)
- Economic impact on non-residential buildings (Flood)
The layers "number of exposed persons" and "population density class" should be moved to the "Exposure" map tab. @patrickkaleta I hope you can easily fix this, tomorrow I will look at the Adaptation section |
The right HC-LE map is currently configured to show the adapted scenario which has not bee calculated. I'm, aware that for the user it's not obvious where and when adaption scenarios are are shown. The new AO appraisal step introduced some inconsistencies which I don't know how to resolve even at conceptual level. Anyway, I can change that if you prefer to see on the right map the non-adapted scenario when no adapted scenario is available, otherwise it shows the adapted one.
The map show only the parameter PF_PROP. There are many other HC-LE PF values available, which are not yet exposed via EMIKAT GeoServer: PF_STREAMS, PF_CL_STREAMS. PF_DELTA_ELEV, PF_CL_DELTA_ELEV, PF_RUN_OFF_AVERAGE, PF_CL_RUNOFF, PF_RAIN_MM: 80, PF_CL_RAIN. Perhaps it would help to show them on the map, too? For this @humerh would have to set-up the respective styles.
Hm, ATM there is only one 'flood impacts in euro' layer.
O.K. I will implement the changes in the respective resource specification on CSIS-DEV. Please be aware that we have atm some problems with the synchronisation, so it might take till the end of the week for the changes to become available on CSIS-PROD.
To do this, the layers have to be made available in EMIKAT View Exposure data (Population) calculated from EMIKAT by @humerh. ATM it contains just POPULATION_TOTAL. Once this is done, I can update the respective resource specification on CSIS-DEV. Since I'm leaving the project on 12. August, I'll also tell @therter how to make these changes in the resource meta-data.
O.K. flood damage probability is currently not available anyway. |
hi @p-a-s-c-a-l thanks for the info. now i triggered the calculation, and indeed the right panel is showing the effect of adaptation strategies. this seems ok for heat waves but it should give some variation also on flood impact.. wonder why not about the other points (sorry I don't know how to quote your sentences as you did with mine..):
|
If you are talking about PF_RESIDENTIAL_BUILDINGS;PF_NON_RESIDENTIAL_BUILDINGS;PF_ROADS_M2, I don't know if those are Economic impacts in €. Perhaps @humerh can clarify. Those columns aren't available in EMIKAT GeoServer anyway, so @humerh would have to create the respective styles first. |
ok, I ask @humerh also to double check if the classification and style of the layer "flood damage class" is correct with respect to what indicated by @stefanon and me. I see almost everything red on that layer, while the damage in euro is much more diversified and more in line with the results I would expect in terms of impact. |
OK folks, we have a showstopper here: I have made new calculations in Linz and in Stockholm now and discomfort level is 5 everywhere and for every scenario. It's really silly, look at this: That's UTCI. And this is discomfort (left). Heat impact (right) did not load, but it could be my connection.: Discomfort level in this table is NOT five everywhere! It's ranging from 2 to 4. https://csis.myclimateservice.eu/study/179/step/4825/view/table This table too. From 2 to 4. https://csis.myclimateservice.eu/study/179/step/4828/view/table My working assumption is that the discomfort is calculated properly but then somehow wrong values are taken for the maps. Same for the heat wave impact. |
One important question on impacts. What are these impacts that we calculate? Is it impact of a single event or cumulative impact of all events happening in 20 years (which is then nearer to risk). When you think of it, the individual 20 year events should have much higher damage cost and mortality than 1y events. Like 10 times higher... And the sum of all 1 year events over 20 years could be both higher and lower than a single 20 y event... |
the impact calculation is on a single scenario representative of the selected reference event (frequent, rare, occasional) in the selected 30 year period. it is not the cumulative impact of all the event in the period |
The map uses the style HW_DISCOMFORT_LEVEL so it should show the same values as in the table. If you click on a cell, You'll see that HW_DISCOMFORT_LEVEL also ranges from 2 to 4. So it's probably just a problem of styling. |
Heinrich has fixed the maps now. At least the discomfort looks ok, didn't check the heat impacts part |
Now the table and the multi criteria steps are gone from this study. That's really strange. I looked at Linz map and here are two screenshots for past and for the worst case future scenario. Both showing discomfort and heat impact, both yearly events. It would seem that impact is still wrong in the map. Discomfort changed, impact should change too... |
The text was updated successfully, but these errors were encountered: