Integrates risk trajectories within climada

[spjuhel]

Changes proposed in this PR:

Implements RiskTrajectory objects to ease the evaluation of risk / impact in between two points in time.

See the associated discussion here: #1039

A notebook showcasing this new module is available in doc/tutorial/climada_trajectory.ipynb. (It is not a real tutorial yet, but will serve as its basis).

Also note that the future option appraisal module will be based on this.

Remaining TODO s

• Sort the list of Snapshot by their date when instantiating
• Add a check that Exposures have the same shape within a risk trajectory.
• Add a check that group_id are identical for Exposures or handle that case (how?)

PR Author Checklist

• Read the Contribution Guide
• Correct target branch selected (if unsure, select develop)
• Descriptive pull request title added
• Source branch up-to-date with target branch
• Documentation updated
• Tests updated
• Tests passing
• No new linter issues
• Changelog updated

PR Reviewer Checklist

• Read the Contribution Guide
• CLIMADA Reviewer Checklist passed
• Tests passing
• No new linter issues

[spjuhel]

I created a discussion here #1039
I think it is better than an Issue, as we will probably continue this discussion if/when we want to integrate timeseries in the future.

[luseverin]

Hi @spjuhel, super nice work!
Besides some comments on the juypter notebook (typos and a few suggestions), I have the following comments:

• Not sure about the meaning of the group_id parameter and why it is required. When not specified, RiskTrajectory() fails with a KeyError: 'group_id' . As far as I understood this should be an optional argument, or did I misundertand this?
• What about changes in vulnerability/impact function? I think you mention in the tuto that is complicated due to non-linearity, but the same argument applies to hazard and exposure. Wouldn't it be possible to have the risk delta attributable to changes in vulnerability in the same way as it is done for hazard and vulnerability already? Something like this: RiskDelta(v) = Risk(haz_past exp_past, vul_fut) - Risk(haz_past, exp_past, vul_past). Not sure this makes sense..

[luseverin]

I think I like the idea of such an object. It could already be quite useful by itself to users to just have a simple way of handling their hazard, exposures and impact function data for different years and cases, no?

[luseverin]

To make the waterfall plot more readable, you could:

• Write a formula instead of the text i.e. hazard_risk = Risk(haz_fut, exp_fut, impf) - Risk(haz_past, exp_fut, impft) ?
• Make the xlabels a bit less croweded by e.g. adding a \n between the metric and the date

[luseverin]

Cool plot!

[luseverin]

Not sure what you mean here.. aren't all components non-linear? Do you mean that the interactions between the different components are non-linear?

[luseverin]

Maybe here add an example on how to modify the exposures gdf to assign the categories to different groups

[luseverin]

Here a legend is missing

[chahank]

I think canonically in the impactcalc class it is fine if either is defined. Any reason to require both here?

[chahank]

I think this is a bit cryptic to read. What is a risk layer for instance?

[chahank]

Would it maybe be cleaner to use the methods defined in impactcalc or impact to compute this?

[spjuhel]

I think so, this is legacy code from Victor. I don't really know why he didn't use existing options.

I think I am just going to remove that part, and let it be handled by the ImpactCalc from what is defined in the exposure.

[chahank]

Ok, understood. I think you will still have to handle this explicitly somewhere as the default in ImpactCalc is (or was?) not well adapted for the adaptation option case, and because it is unclear whether it is the residuals or the transfer.

[chahank]

Does this mean that the insurance cover is shared among all exposure points and equally distributed? If yes, I think this needs to be made very clear in the docstring. Otherwise I am confused about what this relative residuals / transfers mean.

[chahank]

Very cryptic for a user if triggered not in this method specifically, when a method calls this method.

[chahank]

what is a time range? Here there are only time points...

[chahank]

There is no specified range in this method.

[chahank]

Quite cryptic.

[chahank]

Might it be a big effiency gain to have the impact matrices to be lil_matrix format all the time instead of crs_matrix? I think the later is mostly a legacy choice.

[chahank]

time is a bit a weird variable name, as if I understand correctly it should be a counter right?

[chahank]

So this would be global covers and attachment for the whole exposure? What about the cover and attachment per exposure point as saved in the exposure?

[chahank]

Is this method not completely useless?

[spjuhel]

Only in appearance. It has a use in option_appraisal, where we need "_compute_metrics" to remain the same, but _generic_metrics to have a different signature.

[chahank]

Just a note: you are modifying 145 files in this branch, I do not think this is all related to this PR ;).

[peanutfun]

you are modifying 145 files in this branch, I do not think this is all related to this PR ;).

A lot of the changes are already integrated in develop. Maybe another merge of develop into this branch might help.