Large spatial jumps in MCS tracks from INSAT-3DR Tb data - seeking guidance

[IshwaryaKV]

@feng045

Dear PyFLEXTRKR team,
I am using PyFLEXTRKR to track MCS from INSAT-3DR (Indian Geostationary Satellite) TIR-1 brightness temperature data (30-minute resolution) for my MSc project on Indian monsoon convection.
Problem: I'm observing large spatial jumps (150-500+ km) between consecutive timesteps, which seem physically unrealistic for MCS propagation. Some tracks show zigzag patterns with movement speeds exceeding 100 m/s.
What I've tested:

• Various overlap thresholds: othresh = 0.50, 0.70, 0.80
• Different smoothing: smoothwindowdimensions = 3, 20, 30
• Area thresholds: area_thresh = 100, 150, 300 km²
• Time gap settings: timegap = 0.6, 0.75, 1.0 hours

Track counts change, but large jumps persist across all parameter combinations.
Observations:

Input data are temporally continuous with no gaps
Individual cloud centroids look reasonable in cloudid frames
My domain typically has 300-600 clouds per timestep
When examining cloudid files, I notice clouds with the same ID at different timesteps are sometimes at very different locations (e.g., Cloud ID=2 moves 109 km in 30 minutes)

Question:
Are there specific configuration recommendations for high cloud-count scenarios?
Could you help me understand what might be causing these large jumps?
I've attached my configuration file and a visualization showing the spatial jumps. I'm happy to provide additional diagnostics or sample data if that would help.
Thank you very much for developing this excellent tool and for any guidance you can provide!
Attachments:

Configuration file (YAML)
Track visualization showing jumps
INSAT_tb.yml

[IshwaryaKV]

please replay

[feng045]

I'm assuming you're referring to the large spatial "jumps" based on the center location of MCS (are you using meanlat and meanlon) to make that plot example?
The center position (not a particularly well defined quantity for MCS) is calculated by averaging the pixel lat/lon values within each MCS cloud mask. Therefore, it is quite prone to changes of the shape of the MCS masks. Over tropical West Pacific where there are lots of deep convection, merging/splitting of clouds frequently occur, which would significantly change the cloud masks between different time steps, hence affecting the center position. You could take a look at the merge_ccs_area and split_ccs_area in the mcs_tracks_final_*.nc file for this particular track to see if that's indeed the case.

PR #114 added smoothing to the center location, with two additional variables added to the track stats file: meanlon_smooth and meanlat_smooth. The smoothing is applied when a pre-defined max_speed_for_trajectory_smoothing in the config is exceeded. It may help with visually reducing the large jumps, but it does not change actual tracking, because the 2D masks used for overlap calculation remain the same.

Further, I highly recommend plotting animations to overlay the track paths on the Tb images & MCS masks to visualize the tracking output. For Tb-only MCS tracking, you can use this script: Analysis/plot_subset_tb_mcs_tracks_demo.py