Skip to content
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

Improve efficiency of local exceedance intensitry/impact and local return periods functions #1012

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

ValentinGebhart
Copy link
Collaborator

@ValentinGebhart ValentinGebhart commented Feb 14, 2025

Changes proposed in this PR:
Changes address the methods Hazard.local_exceedance_intensity, Hazard.local_return_period, Impact.local_exceedance_impact, and Impact.local_return_period.

  • The interpolation util function is now only called for centroids with nonzero intensity/impact.
  • Intensities/Impacts are rounded to 3 significant digits, as 2 significant digits as before led to bad extrapolation behaviour.
  • docstring was extented to explain how data are extrapolated.
  • floating point problem in util.interpolate.round_to_sig_digits was fixed.
  • The plotting functions Hazard.plot_rp_intensity and Impact.plot_rp_imp now directly call the corresponding functions above, and a warning is added about how to recover values that are computed with CLIMADA 5.0.0 or earlier.

Comments:

  • The extrapolation method might still be improved in the future.

This PR fixes #1010

PR Author Checklist

PR Reviewer Checklist

Comment on lines +1168 to +1171
LOGGER.info(
"Some errors in the previous calculation of local exceedance impacts have been corrected,"
" see Impact.local_exceedance_impact. To reproduce data with the "
"previous calculation, use CLIMADA v5.0.0 or less."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool idea, I am not sure though that this should be an info logging. @emanuel-schmid : what would be the most elegant way to inform the users that something changed, without having logs all the time?

Comment on lines +1174 to +1175
impacts_stats, title, column_labels = self.local_exceedance_impact(
return_periods
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make this calculous optional? Or what would be the way to refine the plot without having to recalculate these values (which can take quite long)? Is it using the util method instead?

Copy link
Collaborator Author

@ValentinGebhart ValentinGebhart Feb 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best way is to do gdf, title, columns = hazard.local_exceedance_intensity() and u_plot.plot_from_gdf(gdf, title, columns). Then you can just change the plot options by repeating the second step, without recalculating the gdf. The plot_rp_intensity is just a wrapper around these two functions, which is why I asked if we want to keep it in the first place.

One way of not repeating the calculation here if one calls the function plot_rp_intensity twice would be to save the local exceedance gdf as an attribute of the Hazard object, but I don't think we want to do that?

Copy link
Collaborator Author

@ValentinGebhart ValentinGebhart Feb 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about writing the info to better use the other two functions in the docstring, as you suggested in the issue? Is this enough?

Copy link
Member

@chahank chahank Feb 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would be a solution I think. For small hazards I guess the method is rather fast, and for lager ones there would the solution in the docstring.

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.

2 participants