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

Feature/reassign centr bydflt #527

Merged
merged 18 commits into from
Aug 12, 2022
Merged

Conversation

emanuel-schmid
Copy link
Collaborator

@emanuel-schmid emanuel-schmid commented Aug 4, 2022

Changes proposed in this PR:

  • As discussed in PR Feature/refactor impact calc #436, not reassigning centroids may lead to faulty results through side effects
  • As decided on the CLIMADA developer day, the easiest solution is to introduce an ImpactCalc.impact parameter that may be used to suppress re-assignment of centroids
  • This PR proposes the parameter(s) reassign_centroids in both methods impact and insured_impact.
  • The parameter were set to True wherever it seemed suitable throughout the code base

This PR fixes issue #515

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

Copy link
Member

@peanutfun peanutfun left a comment

Choose a reason for hiding this comment

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

Looking good! I mostly suggest cosmetic changes. In my suggestions for the comments I try to make clear to users what they gain by setting reassign_centroids to False, and when they can use it. Finally, by passing the force_reassign parameter to reassign_centroids, the method Forecast.calc can be simplified by quite a bit.

climada/engine/forecast.py Outdated Show resolved Hide resolved
climada/engine/impact.py Outdated Show resolved Hide resolved
climada/engine/impact_calc.py Outdated Show resolved Hide resolved
climada/engine/impact_calc.py Outdated Show resolved Hide resolved
climada/engine/impact_calc.py Outdated Show resolved Hide resolved
climada/test/test_calibration.py Outdated Show resolved Hide resolved
@@ -299,7 +299,7 @@ def test_calc_insured_impact_fail(self):
def test_minimal_exp_gdf(self):
"""Test obtain minimal exposures gdf"""
icalc = ImpactCalc(ENT.exposures, ENT.impact_funcs, HAZ)
exp_min_gdf = icalc.minimal_exp_gdf('impf_TC')
exp_min_gdf = icalc.minimal_exp_gdf('impf_TC', False)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe make it explicit here as well?

Suggested change
exp_min_gdf = icalc.minimal_exp_gdf('impf_TC', False)
exp_min_gdf = icalc.minimal_exp_gdf('impf_TC', reassign_centroids=False)

@peanutfun
Copy link
Member

Oh by the way, why is it called reassign_centroids and not simply assign_centroids? These methods behave exactly the same if centroids are assigned or not. So I think assign_centroids explains more exactly what's happening, and it's also equivalent to the Exposures.assign_centroids method. @chahank, @emanuel-schmid, what do you think?

@chahank
Copy link
Member

chahank commented Aug 4, 2022

I agree that the name should rather be assign_centroids. It is confusing to have reassign_centroids, when often there are no assigned centroids to begin with.

@chahank
Copy link
Member

chahank commented Aug 4, 2022

The methods in the module unsequa must also still be adjusted. I am not yet sure what is the right way to do it. In any case, the default should be to not reassign the centroids. The same is true for the cost_benefit module. It makes little sense to repeat this costly computation for repeated impact calculations for which the centroids do not change.

@emanuel-schmid
Copy link
Collaborator Author

If centroids are not assigned for that kind of hazard, they are going to be assigned regardless of the flag, hence, to me, reassign_centroids seems to be more accurate.

@emanuel-schmid
Copy link
Collaborator Author

the methods in the module unsequa must also still be adjusted. I am not yet sure what is the right way to do it. In any case, the default should be to not reassign the centroids. The same is true for the cost_benefit module. It makes little sense to repeat this costly computation for repeated impact calculations for which the centroids do not change.

You are right, I've noticed that too. And I'm not sure yet either about the right way. But in any case, I think the proposed changes here are independent and therefore follow-up PRs are the better way to deal with unsequa and cost_benefit.

@peanutfun
Copy link
Member

If centroids are not assigned for that kind of hazard, they are going to be assigned regardless of the flag, hence, to me, reassign_centroids seems to be more accurate.

True, but I think this is unexpected with regard to the new method signature. If I set [re]assign_centroids=False, I would expect the method to never assign centroids. I think in this case the method should throw an error like

RuntimeError: '[re]assign_centroids' is set to 'False' but no centroids are assigned.

@chahank
Copy link
Member

chahank commented Aug 5, 2022

the methods in the module unsequa must also still be adjusted. I am not yet sure what is the right way to do it. In any case, the default should be to not reassign the centroids. The same is true for the cost_benefit module. It makes little sense to repeat this costly computation for repeated impact calculations for which the centroids do not change.

You are right, I've noticed that too. And I'm not sure yet either about the right way. But in any case, I think the proposed changes here are independent and therefore follow-up PRs are the better way to deal with unsequa and cost_benefit.

I disagree that this can be done separately. With the current change, we essentially make unsequa not usable, and cost benefit partially not usable.

assign_centroids : bool, optional
indicates whether centroids are re-assigned to the self.exposures object
or kept from previous impact calculation with a hazard of the same hazard type.
Centroids assignment is an expensive operation; set this to ``False`` to save
Copy link
Member

Choose a reason for hiding this comment

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

I introduced trailing whitespace, which triggers new linter warnings. Sorry about that!

Suggested change
Centroids assignment is an expensive operation; set this to ``False`` to save
Centroids assignment is an expensive operation; set this to ``False`` to save

assign_centroids : bool, optional
indicates whether centroids are re-assigned to the self.exposures object
or kept from previous impact calculation with a hazard of the same hazard type.
Centroids assignment is an expensive operation; set this to ``False`` to save
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Centroids assignment is an expensive operation; set this to ``False`` to save
Centroids assignment is an expensive operation; set this to ``False`` to save

assign_centroids : bool
Indicates whether centroids are re-assigned to the self.exposures object
or kept from previous impact calculation with a hazard of the same hazard type.
Centroids assignment is an expensive operation; set this to ``False`` to save
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Centroids assignment is an expensive operation; set this to ``False`` to save
Centroids assignment is an expensive operation; set this to ``False`` to save

Comment on lines +264 to +265
exp.assign_centroids(haz, overwrite=False)
imp.calc(exposures=exp, impact_funcs=impf, hazard=haz, assign_centroids=False)
Copy link
Member

Choose a reason for hiding this comment

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

This is now a bit awkward, but it probably works fine. We should check whether the computation time remains stable. Have you already checked that on the test code? Shall I do some more testing?

I think the same change is needed for unsequa.calc_cost_benefit right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, same, same for calc_cost_benefit. I just checked it in.

And yes, I have checked the computational impact, not by computation time itself which is marginal for the test cases I can get my hands on, but by number of calls to assign_centroids with overwrite=True.

And no, thanks, that should be fine. You don't have to do more testing. Unless you object I'm going to merge.

@emanuel-schmid emanuel-schmid merged commit 7b634e8 into develop Aug 12, 2022
@emanuel-schmid emanuel-schmid deleted the feature/reassign_centr_bydflt branch August 12, 2022 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants