Conflict of FastMarching velocity tree between searches

[sedearr]

In qseek.0.2 When running a search using the FastMarcher ray tracer in a region after having ran a successful previous search in a different region, if one of the stations of the new search was already present in the previous one I run into this error:

File "/mnt/Digivolcan1/Qseek/qseek_0-2/lib/python3.12/site-packages/qseek/tracers/fast_marching.py", line 286, in add_travel_time_table
raise ValueError(
ValueError: travel time table fm:P for lat=XX.XXXXX lon=-XX.XXXXXX east_shift=0.0 north_shift=0.0 elevation=721.0 depth=0.0 network='C7' station='PML2' location='' already exists

The existing value in the velocity map from a previous run stops this one from proceeding. Clearing qseek cache, killing all qseek processes, and deactivating and activating the environment did not solve the issue.

Proposed workaround: in the class FastMarchingTracer defined in fast_marching.py I modified the method add_travel_time from

    def add_travel_time_table(self, table: StationTravelTimeTable) -> None:
        """Add a travel time slice to the tracer."""
        key = (table.station.location_hash(), table.phase)
        if key in self._travel_time_tables:
           raise ValueError(
           f"travel time table {table.phase} for {table.station} already exists"
           )
        self._travel_time_tables[key] = table

To

    def add_travel_time_table(self, table: StationTravelTimeTable) -> None:
        """Add a travel time slice to the tracer."""
        key = (table.station.location_hash(), table.phase)
        if key in self._travel_time_tables:
            logger.warning(
            f"Overwriting existing travel time table for {table.station} {table.phase}"
        )
        self._travel_time_tables[key] = table

Also, for the prepare() method of the same class forced the initialization of an empty travel time table:

self._travel_time_tables = {}

After these changes the search seemed to proceed without issue, but I don't know how they might affect performance for successive searches.

[miili]

This should not happen. When you run it with your fix, are all stations' travel time tables overwritten, or just some?

How can I reproduce this?