tc_forecast hazard check fails due to identical event names

[elianekobler]

I used the TCForecast class to fetch ECMWF forecast data and generate a Climada hazard. The forecast data consists of 51 ensemble members. However, hazard.event_name is the same for all 51 members. This leads to a failure of the hazard.check() function.
I expected the hazard.check() function to suceed.

fcast_all = TCForecast()
fcast_all.fetch_ecmwf()
tc_fcast = TropCyclone.from_tracks(tr_fcast, centroids_sel)
tc_fcast.check()

`ValueError Traceback (most recent call last)
Cell In[18], line 1
----> 1 tc_fcast.check()

File ~/climada_workspace/climada_python/climada/hazard/base.py:261, in Hazard.check(self)
254 def check(self):
255 """Check dimension of attributes.
256
257 Raises
258 ------
259 ValueError
260 """
--> 261 self._check_events()

File ~/climada_workspace/climada_python/climada/hazard/base.py:799, in Hazard._check_events(self)
796 self.orig = u_check.array_default(num_ev, self.orig, 'Hazard.orig',
797 np.zeros(self.event_id.shape, dtype=bool))
798 if len(self._events_set()) != num_ev:
--> 799 raise ValueError("There are events with same date and name.")

ValueError: There are events with same date and name.`

I am using the newest Climada 5.0 version on macOS 14.5 and the Python 3.10.14.

[peanutfun]

Hazard.check() is a somewhat outdated method. I don't think repeated dates and names are actually an issue. The Hazard object should still work fine 🤔

[manniepmkam]

The Hazard object created by TropCyclone.from_tracks() indeed works fine. However, I think having a unique event_name for the TC hazard can be beneficial.

Here I propose the solution and would be great to have a second opinion before starting the pull request. @peanutfun @ThomasRoosli

The event_name in the TC hazard directly takes the sid from TC track objects. Currently, the sid is the ECMWF tracks id in for format of 2 digits number and a letter denoting the basin (e.g. 04L).

Here, I propose to change the sid attribute in TCForecast to {TC_name/ecmwf_id}_ens_{ensemble_number}, and adding a new attribute ecmwf_sid to keep the unique id from ECMWF. The TC_name/ecmwf_id depends on whether the storm is already a named storm at the time of the forecast.

Let me know if the solution sounds good. If so, I can start working on the pull request.