Extend compute_damage to accept rainfall-driven inundation#17
Merged
Conversation
Damage now consumes either kind of inundation depth — the static
InundationDepth (user-supplied scalar water level) or the new
RainfallInundationDepth (per-cell depth field driven by Manning's
normal-depth + HAND broadcast). Same numerics either way; the
DamageMap's metadata records which scenario produced it via a new
`scenario` string field plus the existing `water_level`, which now
holds the per-cell maximum depth as a one-number summary for the
rainfall path.
- floodpath/damage/models.py: DamageMap gains `scenario: str = "static"`,
defaulted so the existing 35 damage tests pass unchanged.
- floodpath/damage/compute.py: `depth` argument typed as
`InundationDepth | RainfallInundationDepth`. Inside, branch on type to
set scenario string ("static water level X m" vs "rainfall-driven
(source, T, method)") and water_level (input scalar vs per-cell max).
Tests: 9 new for the rainfall path:
- scenario string content (precip source, duration, method)
- water_level == max(values)
- numerical equivalence between rainfall and static paths at same depth
- upsample-preserving-total still works with rainfall depth + coarser exposure
- end-to-end pinned: 100 mm × 6 hr on Robit Bata fixtures yields
7,355 m^2 damaged built-up — much smaller than the hypothetical static
5 m scenario's 69,199 m^2 (consistent with rainfall flood being a
narrow channel ribbon vs static water level flooding broad valleys)
Smoke test gains stage 17: applies JRC residential to the stage-16
rainfall flood, prints both totals side-by-side for direct comparison
with the existing stage 8 static damage.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
`compute_damage` now consumes either kind of inundation — the static `InundationDepth` (user scalar water level) or the new `RainfallInundationDepth` (per-cell field driven by Manning + HAND). Same numerics either way; only the scenario metadata differs.
Why
After the routing chain landed (PR #15 + #16), the rainfall-driven flood is a first-class output but the existing damage chain only knew about static-water-level inundation. This closes the last consumer gap: `apply_scs_cn → accumulate_runoff → peak_discharge → compute_water_level → compute_rainfall_inundation → compute_damage` now runs end-to-end on a single curve evaluation, and the resulting DamageMap carries provenance back to the precip source.
API change (backward compatible)
The `scenario` field on DamageMap holds either:
Test plan
Notes