Skip to content

Feature/frequency unit#532

Merged
emanuel-schmid merged 25 commits intodevelopfrom
feature/frequency_unit
Sep 19, 2022
Merged

Feature/frequency unit#532
emanuel-schmid merged 25 commits intodevelopfrom
feature/frequency_unit

Conversation

@emanuel-schmid
Copy link
Copy Markdown
Collaborator

Changes proposed in this PR:

  • Introduce a field frequency_unit in classes Impact, ImpactFreqCurve
    The fields have no impact on the calculation whatsoever, they are purely informative.
    Nevertheless concatenation of Hazard objects is inhibited if they have different frequency_unit values.

This PR fixes issue #516

Pull Request Checklist

  • Correct target branch selected (if unsure, select develop)
  • Source branch up-to-date with target branch
  • Docs updated
  • Tests updated
  • Tests passing
  • No new linter issues

Comment on lines +802 to +803
LOGGER.warning("resetting the frequency on a hazard object who's frequency unit"
"is %s and not %s will most likely lead to unexpected results",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I do not really like the "will lead to unexpected results". This very vague. Can we make it more precise you think?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Good question! Can we? The thing is that the user is sending contradicting signals at this point. Why do they set a frequency_unit other than 'annual' and then still use the method in a way that is strongly related to 'annual' frequencies.
I'd say they have to look and see themselves. 🤷

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we could say something like:

"The frequency unit will be changed from %s to %s. The resulting frequency will thus be most likely incorrect. Consider setting reset_frequency=False and set the frequency manually for the selection."

"| coord_exp |np.array| exposures coordinates [lat, lon] (in degrees) (Exposure.gdf.latidues, Exposure.gdf.longitude)|\n",
"| frequency |np.array| annual frequency of events (Hazard.frequency)|\n",
"| frequency |np.array| frequency of events (Hazard.frequency)|\n",
"| frequency_unit |str| unit of event frequency, by default '1/year', i.e., annual, this attribute is purely informative and does not effect calculations (Hazard.frequency_unit)|\n",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is it really needed to the "this attribute is purely informative..." ? For instance, this is also the case for the event_id, the unit or the date. And this can change in the future, in particular if time is integrated more deeply into CLIMADA.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Just wanted to emphasize that the frequency_unit is not being considered at any point in calculations. All it really does is change labels in plots.
As a naive user, when I can set a frequency_unit in an object and I get a frequency, I might naturally suspect the two to be somehow correlated. Which is not the case. Therefore the warning.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

But this is also the case for other entries. Thus, I would remove it as it is confusing why this is said for that entry, but not for others. Furthermore, there will likely be methods in the future that will actually care about the frequency unit.

@chahank
Copy link
Copy Markdown
Member

chahank commented Sep 14, 2022

Thanks for the changes! Very useful. A few small comments.

@emanuel-schmid
Copy link
Copy Markdown
Collaborator Author

@chahank Thanks for reviewing! 🎉

@emanuel-schmid emanuel-schmid merged commit 1eb36d0 into develop Sep 19, 2022
@emanuel-schmid emanuel-schmid deleted the feature/frequency_unit branch September 19, 2022 18:06
@emanuel-schmid emanuel-schmid mentioned this pull request Oct 3, 2022
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