Add vulnerability functions.

[xbarra]

We add vulnerability functions 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

Co-authored-by: Virginia Morales [email protected]
Co-authored-by: Víctor de Luna [email protected]
Co-authored-by: Arfima Dev [email protected]

Signed-off-by: Virginia Morales [email protected]

[xbarra]

I am reviewing all the tests before adding the commit, I'll try to have it on Monday and add more descriptions.

We'll do a separate PR for the documentation, ideally next week.

[ModeSevenIndustrialSolutions]

Looks good to me.
(Presumably you'll sort the pre-commit/linting checks when this comes out of draft?)

[xbarra]

Looks good to me. (Presumably you'll sort the pre-commit/linting checks when this comes out of draft?)

yes, want to pass cleanly

[joemoorhouse]

Ah, looks like this has some conflicts with the just-merged #310 unfortunately. @xbarra, I can take a look at that if you like unless you have already resolved? - the ground just shifted under your feet somewhat!

Hi @ModeSevenIndustrialSolutions, what's the plan about linting for OSC projects actually - are we meant to using ruff or black (and indeed will they clash?).

[ModeSevenIndustrialSolutions]

Hi @ModeSevenIndustrialSolutions, what's the plan about linting for OSC projects actually - are we meant to using ruff or black (and indeed will they clash?).

Ruff replaces a lot of separate python linting tools, and apart from getting the benefit of consolidation, is much faster and more efficient. It also de-centralises the configuration options because it can read its config from stanza in pyproject.toml. Hopefully we can all therefore perhaps agree on the value of this tool, and mandate its use, but configuration can be modified on a per-repo basis. Therefore, we don't need to maintain some central "one size doesn't fit all" configuration that will be unpalatable to lots of people.

I've been working on a whole bunch of DevOps tooling updates, and will hopefully be able to demonstrate the progress on this topic in a couple of weeks time!

• Matt

[xbarra]

@joemoorhouse I have already resolved them.

I am also going to push the change to ruff as linter

[xbarra]

We are fixing the mypy complains.

I will add mypy to the pre-commit hooks config.

[xbarra]

Note: This PR's commits should not be squashed together, since they are quite different.

Once again, albeit I am extremely partial to the linear history, merging commits have unintended consequences.

I am more than happy in doing a manual rebase if needed. [Not that I want to have more stuff to do in my life, but for linear history, I would do it].

Also the workflow is using isort, and because of that it fails.

[joemoorhouse]

Hi @xbarra, thanks for all of the fixes, the ruff and test commits are looking good I think. On the vulnerability changes, I am a bit confused by the StressTestImpact - I don't understand why this is added into the kernel (i.e. this is really changing the framework) alongside the existing ImpactDistrib class. As far as I can tell, this contains an instance of HazardPercentilesStressTest which is very specific to the ECB stress-testing methodology and contains specific values relating to that approach (and indeed is in risk_models module not in the kernel which is the right place for it). In other words we have an element added to the kernel which relates to one specific methodology I think.

I think what is going on is that you have some RiskMeasureCalculators e.g. ThermalPowerPlantsRiskMeasures that is comparing to a baseline which is actually a hard-coded set of parameters, but then I would have thought that HazardPercentilesStressTest that contains those parameters should simply be in that class? In other words, base_impact is not actually being used in this case, which is fine, but I don't think that should lead to kernel/framework changes.

Happy to discuss. This is actually a largish framework change, impacting the kernel (in particular risk.py) so I think it's important to check this point.

Thanks,
Joe

[xbarra]

Hi @xbarra, thanks for all of the fixes, the ruff and test commits are looking good I think. On the vulnerability changes, I am a bit confused by the StressTestImpact - I don't understand why this is added into the kernel (i.e. this is really changing the framework) alongside the existing ImpactDistrib class. As far as I can tell, this contains an instance of HazardPercentilesStressTest which is very specific to the ECB stress-testing methodology and contains specific values relating to that approach (and indeed is in risk_models module not in the kernel which is the right place for it). In other words we have an element added to the kernel which relates to one specific methodology I think.

I think what is going on is that you have some RiskMeasureCalculators e.g. ThermalPowerPlantsRiskMeasures that is comparing to a baseline which is actually a hard-coded set of parameters, but then I would have thought that HazardPercentilesStressTest that contains those parameters should simply be in that class? In other words, base_impact is not actually being used in this case, which is fine, but I don't think that should lead to kernel/framework changes.

Happy to discuss. This is actually a largish framework change, impacting the kernel (in particular risk.py) so I think it's important to check this point.

Thanks, Joe

Thank you so much for the feedback, Joe.
We are adjusting our changes to that.

[xbarra]

Hi @joemoorhouse
the last revision has your proposed ajustments.

Let us know of other changes needed.

[xbarra]

Moved back use_case_id to a string.

[xbarra]

depends on os-climate/hazard#108
After which, the inventory.json will need to be updated.