Integrates risk trajectories within climada #1037

spjuhel · 2025-04-02T12:35:37Z

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 (Handled, different group_id are possible, metric is computed at each date and interpolated in between)
Make a decision about risk transfer (possibly after discussion with @chahank, see Integration of risk trajectories within climada #1039 ):
Make plots nicer, also cleanup "plot.py" file (no longer needed?)
Write extensive guide (see Integration of risk trajectories within climada #1039 )

PR Author Checklist

PR Reviewer Checklist

…_for_impf

Co-authored-by: Lukas Riedel <[email protected]>

spjuhel · 2025-04-04T07:36:45Z

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.

- Replaced RiskPeriod class by CalcRiskPeriod class to centralize shared computations and dynamic metric instantiation. - Improved efficiency by reusing shared computations across metrics. - Added InterpolationStrategy and ImpactCalcStrategy classes to abstract that part of the computation

chahank · 2025-09-17T10:08:52Z

Small comments to the tutorial. They are really just from a user’s perspective at the moment.

Instead of a wall of text, maybe start with a quick example which goes within one or two cells to the results. I can help with that :)
Is the snapshot.measure supposed to be a MeasureSet ? Shall we then use the name measureset or similar?
The method snap.apply_measure() cannot apply the measure that are already in snapshot.measure ? This is a bit unintuitive. Should snapshot.measure and .apply_measure be private?
default_rp at [50, 100, 500] is probably a bit ambitious. Is it necessary to have a default?
The risk_traj.eai_exp contains the column coord_id , but risk_traj.coord_id does not exist. It is unclear what one should do with this information.
risk_traj.risk_periods returns a list of python pointers, so quite useless (in particular since it is a property without docstring, so I cannot make sense of that output). Should this be private?
risk_traj.risk_components_metrics() maybe change components to contribution ? Also, there is the index column which is unclear.
plot_per_date_waterfall() maybe rename plot_time_waterfall() as it is more than just per date?
I think the handling of the RP is a bit confusing now. There is a default set, but it is unclear how and why. Then there is a method to access them, isk_traj.return_periods_metrics which requires the RPs as input. However, the method risk_traj.per_period_risk_metrics() (and others) just compute the RP based on the default.
The use of the method isk_traj.npv_transform is unclear. Should this be private? Idem for risk_traj.identify_continuous_periods
In a future, the discounted vs not discounted risk plot might be implemented directly, looks useful.
Maybe we could make Enum classes to define the choices for the interpolation and impact calculations methods.

Really exciting, overall the use looks very straightforward! (edited)

climada/trajectories/impact_calc_strat.py

climada/trajectories/interpolation.py

chahank · 2025-09-23T08:57:52Z

climada/trajectories/interpolation.py

+    res = []
+    for point in range(interpolation_range):
+        ratio = point / (interpolation_range - 1)
+        mat_interpolated = mat_start * (1 - ratio) + ratio * mat_end
+        mat_interpolated.data = np.exp(mat_interpolated.data * np.log(rate))
+        res.append(mat_interpolated)
+    return res


Could also be a list comprehension.

And curiosity, what does res stand for?

result / return

Ok, this is a terrible name, but also not fundamental.

How do you handle the change of .data within a list comprehension ?

climada/trajectories/interpolation.py

chahank · 2025-09-23T09:52:22Z

climada/trajectories/snapshot.py

+    A snapshot of exposure, hazard, and impact function at a specific date.
+
+    Attributes
+    ----------
+    date : datetime
+        Date of the snapshot.
+    measure: Measure | None
+        The possible measure applied to the snapshot.


Probably incomplete.

Properties have their own docstring if you are talking about that?

hmmmm ok, I see. This is quite confusing, since the properties are just wrapper for attributes which are not described here. Reading this, one does not know what is in the snapshot, it looks like there are only dates and measures.

I agree, but this is the PEP standard.

climada/trajectories/snapshot.py

chahank

Started with an overview of the easier parts. Will need much more time for the more complex core classes.

climada/trajectories/snapshot.py

climada/trajectories/timeseries.py

climada/trajectories/interpolated_trajectory.py

chahank · 2025-09-23T10:02:48Z

climada/trajectories/interpolated_trajectory.py

+from climada.trajectories.riskperiod import (
+    AllLinearStrategy,
+    CalcRiskPeriod,
+    ImpactCalcComputation,
+    ImpactComputationStrategy,
+)


Any reason to not import these modules directly (instead of importing them from riskperiod) ?

I don't understand the question?

Do you mean from riskperiod import instead of from climada.trajectories.riskperiod ?

This is virtually the same (slightly more robust). These lines are generated automatically by my LSP when a new import is required.

Sorry for being unclear. I meant that for instance ImpactCalcComputation should be imported from its module, i.e. from climada.trajectories.impact_calc_strat right?

Oh, right! Yes indeed this is not elegant.
In any case, I think I am going to make proxies within trajectory/__init__.py to simplify imports.

chahank · 2025-09-23T10:03:47Z

climada/trajectories/risk_trajectory.py

+LOGGER = logging.getLogger(__name__)
+
+POSSIBLE_METRICS = ["eai", "aai", "return_periods", "risk_components", "aai_per_group"]
+DEFAULT_RP = [50, 100, 500]


As raised in the discussion, I think there is a conundrum with this default. It should imho be removed.

Is it a forced input? What if people are not interested in RP? Is it empty by default?

I do not undersand this response exactly.

Having arbitrary defined default RPs, which sometimes are applied, and sometimes user input RPs are applied, is confusing, as explained in the discussion to this PR. So, I would remove the default here. You can always set the default in the method that computes the values for the RPs. Then it is clear to the user. I would also choose a bit more conservative values, e.g., [20, 50, 100]. The RP500 is only rarely available in hazard datasets.

Does this clarify the response?

So how it works now is that the methods do not have RPs has argument any more (simplifies a lot) and always use the .return_periods attribute which has a default value (changed to 20, 50, 100) and can be set at init (to be coded still) or via the property afterwards (and takes care of updating the metrics).

Does that work for you?

Sounds good! Important is that you can set it in the init and via properties too.

Updated in 3a026cd

climada/trajectories/interpolated_trajectory.py

climada/trajectories/risk_trajectory.py

climada/trajectories/interpolated_trajectory.py

climada/trajectories/risk_trajectory.py

- Fixes aai per group in static - components -> contributions - privatisation of some funs

- reworked return periods (only changed via the property, not the metrics methods) - removed npv boolean, risk is now always computed with risk discount if present - reworked caching (results are now correctly cached) - reworked computation related properties (now more tightly connected to computings objects - removed `time_points` from computing object as not usable - clearer names

…ctory

spjuhel and others added 10 commits March 18, 2025 17:37

Implements equality methods for impf and impfset

3692813

adds a few tests

1606896

Merge remote-tracking branch 'origin/develop' into feature/eq_methods…

a8b45c6

…_for_impf

updates changelog

3776228

Improves dict comparison

f6d9feb

Co-authored-by: Lukas Riedel <[email protected]>

Applies suggestion from Lukas (1)

222644d

Co-authored-by: Lukas Riedel <[email protected]>

init commit

29ecee4

Pushes tutorial notebook

d7c0f23

Working tutorial

31ef976

fixes a typo from mass edit

10ca243

spjuhel requested review from emanuel-schmid and peanutfun April 3, 2025 14:35

This comment was marked as duplicate.

Sign in to view

spjuhel added 12 commits April 15, 2025 18:42

fixes some bugs

4ea685d

fixses some linter issues

0d6335b

feat(trajectory): interpolation and impactcalc files, eai_gdf metric

31ea96d

impact func __eq__

3f13c2e

feat(test): adds test for ImpactFuncSet

519c9af

fix(format): removes trailing whitespace

adfc7e2

Merge branch 'feature/eq_methods_for_impf' into feature/risk_trajectory

6856117

fix: npv arg not considered in .all_risk_metrics()

9c358ca

refactor: enforce kwargs in RiskTrajectory init

b7bf68b

refactor: adds consistency between attribute

b75ab91

refactor(risktraj): lays better foundations for MeasureAppraiser

e12b2c4

Improves for CB

21cc433

Use of PeriodIndex instead of DateTimeIndex

0a04ab9