Obtain advection estimates in multiple sub-domains

[gewitterblitz]

Hi @feng045 ,

I was trying to obtain storm-relative winds using the advection estimates generated in the 'advection' netcdf file. While it works great, I noticed that certain sub-domains may have slightly different cell motions than the overall domain average. So, if I need to be more precise about storm-relative winds, I may need advection estimates within sub-domains.

When I change the advection_tiles: parameter in the config file from [1,1] to [2,2], I get advection estimates over a grid of nx times ny tiles with mean advection in the sub-domains but the ft_utilities/match_drift_times function used by tracksingle_driver.py script encounters an error when len(idx) != 1 (line 361 in ft_utilities.py). As a result, the code fails to track cells. I am also not entirely sure how to interpret (or retrieve the coordinates) of the sub-domains (or tiles) generated in the new advection file. The tile coordinates are just numbers with no latlon or x,y coordinates.

I noticed the PyFLEXTRKR preprint mentions expanding the existing codebase to have sub-domain functionality. Therefore, I was just curious to know if you have already started integrating it in the main branch.

Thanks!

[feng045]

Hi @gewitterblitz,

We have not implemented the multi-tile advection estimates for cell tracking yet. While the advection code can have multiple tiles, the advection outputs need to be coupled with the cell mask shifting tracksingle_drift.py, which has not been done yet.

Storm-relative winds maybe better estimated using individual storm motions. There are a couple different ways to do it:

1. Use the cell center location (cell_mean_x/cell_mean_y or core_mean_x/core_mean_y) differences [in kilometer] between two time steps divided by the time difference to get the cell movement speed/direction;
2. Use the cell center lat/lon (cell_mean_lon/cell_mean_lat or core_mean_lon/core_mean_lat) to compute distances using some formula (e.g., Haversine), divided by the time difference.

Hope this helps.

[gewitterblitz]

Thanks for your reply, @feng045! Yes, I was using the cell_mean_x/cell_meanlon approach so far but I realized that the motion estimate for some cells might be erroneous depending on how well the Steiner algorithm parameters define a cell boundary. Even if we discard the cells tracks that end by merging or start by splitting, we may still be left with big size cells that retain their track number while merging with smaller cells nearby. The mean coordinates for those cell tracks may end up looking like a zig-zag line and our motion estimates will depend on whether we use full lifecycle or part of it to calculate dx/dt and dy/dt.

You thoughts?

[feng045]

Yes, individual cell movements are affected by their shape/morphology, which depends on the segmentation method and further complicated by merging/splitting. There is no perfect way to estimate movements, it depends on your specific need.

Perhaps you could average the individual cell movements within a sub-region to get their "mean speed". Alternatively, you can use the multi-tile advection estimates to do something similar. You should be able to figure out which tile correspond to which if you give a different number in rows vs. columns (e.g., set advection_tiles: [2, 3] in the config), or take a look at the advection code advection_tiles.py.

[gewitterblitz]

Great, thanks again!