paullric
commented
1 year ago How would you handle it if maxgap is greater than 1 and there is a candidate which is closer but is not present at the immediately previous timestep?
Would it be beneficial to do forward projection of the traj so as to allow mergedist to be smaller?
On Aug 28, 2023, at 2:33 PM, zarzycki @.***> wrote:
Currently, StitchNodes takes a candidate node and then marches forward in time, gluing nodes together to form a trajectory. If successful, these nodes are removed from being available to potential "future" cyclones.
This can lead to problems like the below where an earlier storm (e.g., traj 1 on left) can merge with a nearby vortex that is part of a subsequent storm (traj 2 on right). TE still provides two trajectories, but the "merge" of the overlapping points is added to traj 1 when it should be added to traj 2. This causes unphysical movement with traj 1 and can also lead to discontinuity (here, traj 2 is much stronger than traj 1 and traj 1 "jumps" in its intensity time trace, watch the X denoting storm center on the left).
https://user-images.githubusercontent.com/10341827/263839227-5cf74a81-8ae0-40cf-afa9-188a4c0d3243.gif This can be partly alleviated by reducing --range, although this can then arbitrary break trajectories that are "real" if one reduces range too much.
Ideally, if a candidate at a given time N can be claimed by two trajectories, we should prioritize the one that is closest (either in space or as measured by some quantity like PSL) and assign the candidate to that trajectory. I can envision three ways to do this. One would require trajectories to be built up in parallel in StitchNodes (i.e., traj 1 and traj 2 are both incrementally built, then when we get to time N and a candidate is claimed by both traj, we make a decision). Two, we do not remove candidates from the pool of future trajectories and then eliminate "overlapping" points after one pass of the stitching is done. Three, we perform a pass after StitchNodes is completed to rearrange tracks if it's obvious that the end of traj 1 should belong to the end of traj 2, for example.
— Reply to this email directly, view it on GitHub https://github.com/ClimateGlobalChange/tempestextremes/issues/62, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIVPZCYLUDWJHHIYHOK7PLXXUFDJANCNFSM6AAAAAA4CABRLU. You are receiving this because you are subscribed to this thread.
zarzycki
Currently, StitchNodes takes a candidate node and then marches forward in time, gluing nodes together to form a trajectory. If successful, these nodes are removed from being available to potential "future" cyclones.
This can lead to problems like the below where an earlier storm (e.g., traj 1 on left) can merge with a nearby vortex that is part of a subsequent storm (traj 2 on right). TE still provides two trajectories, but the "merge" of the overlapping points is added to traj 1 when it should be added to traj 2. This causes unphysical movement with traj 1 and can also lead to discontinuity (here, traj 2 is much stronger than traj 1 and traj 1 "jumps" in its intensity time trace, watch the X denoting storm center on the left).
This can be partly alleviated by reducing --range, although this can then arbitrary break trajectories that are "real" if one reduces range too much.
Ideally, if a candidate at a given time N can be claimed by two trajectories, we should prioritize the one that is closest (either in space or as measured by some quantity like PSL) and assign the candidate to that trajectory. I can envision three ways to do this. One would require trajectories to be built up in parallel in StitchNodes (i.e., traj 1 and traj 2 are both incrementally built, then when we get to time N and a candidate is claimed by both traj, we make a decision). Two, we do not remove candidates from the pool of candidates available to future trajectories and then eliminate "overlapping" points that occur in multiple trajectories after one pass of the stitching is done. Three, we perform a pass after StitchNodes is completed to rearrange tracks if it's obvious that the end of traj 1 should belong to the end of traj 2, for example.