Minor issues with forecast classes #1169

Activity

1. peanutfun

   added a parent issue on Dec 8, 2025

   • E1S1: Impact calculation with forecast data structures #1119
2. peanutfun

   added the

   Task

   issue type on Dec 8, 2025
3. peanutfun commented on Jan 12, 2026

   

   peanutfun

   on Jan 12, 2026

   Member

   More actions

   Check that the frequency of the events is equal to 1/#ensemble memebers in the HazardForecast Class.

   This is not generally enforced by the class, but from_xarray_raster currently sets it so.
4. peanutfun commented on Jan 12, 2026

   

   peanutfun

   on Jan 12, 2026

   Member

   More actions

   The init of the ImpactForecast class should set the eai_exp to an empty array of length equal to coord_exp and aai_agg to a non-definit value.

   The init of ImpactForecast does not implement that, but ImpactCalc does when computing the impact from a HazardForecast.
5. peanutfun commented on Jun 10, 2026

   

   peanutfun

   on Jun 10, 2026

   Member

   More actions

   @chahank Does this resolve the issues you raised? Could you add the requested comment to the base classes?
6. peanutfun

   added

   enhancement

   user-friendliness

   documentation

   on Jun 10, 2026
7. peanutfun

   changed the title [-]Collect small issues for forecast classes[/-] [+]Minor issues with forecast classes[/+] on Jun 10, 2026
8. peanutfun

   removed a parent issue on Jun 10, 2026

   • E1S1: Impact calculation with forecast data structures #1119
9. chahank commented on Jun 11, 2026

   

   chahank

   on Jun 11, 2026

   MemberAuthor

   More actions

   The init of ImpactForecast does not implement that, but ImpactCalc does when computing the impact from a HazardForecast.

   hmmm but then this means that the ImpactForecast object at initialization is not consistent right?
10. chahank commented on Jun 11, 2026

    

    chahank

    on Jun 11, 2026

    MemberAuthor

    More actions

    This is not generally enforced by the class, but from_xarray_raster currently sets it so.

    Any reason for this? This is a potential (in)consistency trap imho.
11. peanutfun commented on Jun 11, 2026

    

    peanutfun

    on Jun 11, 2026

    Member

    More actions

    hmmm but then this means that the ImpactForecast object at initialization is not consistent right?

    Same behavior as Impact base class. We could, however, remove the two parameters from the ImpactForecast initialization and set them inside the class. This might be a more elegant solution for ImpactCalc, but it might have some unexpected consequences. ImpactForecast.from_impact(imp) would then ignore the two attributes from imp and not copy them into the new object.

    This is not generally enforced by the class, but from_xarray_raster currently sets it so.

    Consistency between values of the different hazard/exposure/impact attributes is never enforced anywhere in CLIMADA. HazardForecast currently checks if member and lead_time have the right size, the base class does not even check that (during init).