Skip to content

Add vulnerability functions and risk models.#568

Open
xbarra wants to merge 1 commit intoos-climate:mainfrom
arfima:statistics_paper_48_ecb
Open

Add vulnerability functions and risk models.#568
xbarra wants to merge 1 commit intoos-climate:mainfrom
arfima:statistics_paper_48_ecb

Conversation

@xbarra
Copy link
Collaborator

@xbarra xbarra commented Feb 13, 2026

We add vulnerability functions and risk models with the aim of replicating the paper:
'Climate change-related statistical indicators'
Statistics Paper Series No 48 from the European Central Bank.
https://www.ecb.europa.eu/pub/pdf/scpsps/ecb.sps48~e3fd21dd5a.en.pdf?4826f6ee77d3ac7a681916b6d419b751

Central to this is the introduction of the indexing of impacts and risk scores by indicator id
besides hazard type, allowing to compute and return indicator id-specific risk scores.
This is important for hazards for which different indicators measure different
types of impacts, like drought's consecutive dry days (CDD) and SPEI.

Co-authored-by: Virginia Morales vmorales@arfima.com
Co-authored-by: Víctor de Luna vdeluna@arfima.com
Co-authored-by: Juan Román Roche jroman@arfimaconsulting.com
Co-authored-by: Violeta Crespo Cobas vcrespo@arfima.com
Co-authored-by: Arfima Dev dev@arfima.com

Signed-off-by: Violeta Crespo Cobas vcrespo@arfima.com

We add vulnerability functions and risk models with the aim of replicating the paper:
'Climate change-related statistical indicators'
Statistics Paper Series No 48 from the European Central Bank.
https://www.ecb.europa.eu/pub/pdf/scpsps/ecb.sps48~e3fd21dd5a.en.pdf?4826f6ee77d3ac7a681916b6d419b751

Central to this is the introduction of the indexing of impacts and risk scores by indicator id
besides hazard type, allowing to compute and return indicator id-specific risk scores.
This is important for hazards for which different indicators measure different
types of impacts, like drought's consecutive dry days (CDD) and SPEI.

Co-authored-by: Virginia Morales vmorales@arfima.com
Co-authored-by: Víctor de Luna vdeluna@arfima.com
Co-authored-by: Juan Román Roche <jroman@arfimaconsulting.com>
Co-authored-by: Violeta Crespo Cobas <vcrespo@arfima.com>
Co-authored-by: Arfima Dev dev@arfima.com

Signed-off-by: Violeta Crespo Cobas <vcrespo@arfima.com>
@joemoorhouse
Copy link
Collaborator

Hi everyone, and many thanks for this! The big thing (and probably only thing) here to discuss is the interface change that scores are no longer per hazard but now per hazard and per indicator ID. This is a somewhat different direction of travel from #566 which reinforced that the approach is to have one score per type of hazard (as before), but the scores are aggregated from multiple impacts - and those impacts do have different hazard indicators.

The other change in that merged PR is to make the scores more impact-based. In fact it is probably fair to say that industry 'best practice' is evolving to replace exposure-based scores with impact-based as far as is possible: measures reflecting economic loss. From that future standpoint, indicator ID is still not a first class citizen in the interface, because the impacts have been aggregated. For example, for heat hazards we could have impacts related to productivity loss or downtime, which each have different hazard indicators, but these would be aggregated into something financially meaningful (e.g. combined revenue annual average loss) which the score is based on.

What are then the possibilities:

  1. Don't have multiple scores for drought; calculate from multiple indicators and even have intermediate scores but then aggregate into a single score (do users want multiple scores for the same thing anyway? Are those not rather methodological details?)
  2. If there is a strong feeling that sub-scores, per asset and per indicator ID need to be reported then I think we need to add a different part of the API and separate flag to deal with that and treat more as a different mode/enhanced reporting mode. I don't think we should change that part of the main API to have one score per hazard. Not only will it break stuff, but it does not seem to me to be well-aligned to the target where measures are impact-based not exposure-based.

My preference is for 1 all else equal, but there may well be a use-case which I am not aware of, so some form of 2 might be needed. In any case: to discuss!

@joemoorhouse
Copy link
Collaborator

joemoorhouse commented Feb 24, 2026

Strong preference for option 2. Proposal is to support score by hazard indicator ID, but make this an optional drill-down. A proposal for kernel changes to achieve this is here:
#573
This is a variation of the approach above but which preserves current API and aggregation of impacts to give a single per-hazard score. Idea is also to split out the core changes needed and merge these in first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants