Native methods for filtering mode data

[tomflexcompute]

A user reported that they spend a lot of time on either filtering modes manually or implementing their own filters. What could help them:

1. a flag to automatically filter out modes that are marked as "not decayed at the boundary".
2. filter by the loss, i.e. provide a threshold for how much of loss is allowed and remove all modes above that.
3. filter by mode volume: similarly, provide a threshold value for mode volume.

And thanks @dbochkov-flexcompute for collecting the information from the user.

[momchil-flex]

From discussion, few possible ways:

1. Define frontend post-processing methods that can be e.g. ModeSolverData.filter(filter_what) -> FilteredModeSolverData, where FilteredModeSolverData also keeps the indexing into the original mode solver data so that a user can e.g. select a mode for injection in a ModeSource. Pros: easier to implement and use directly, including different filtering in post-processing. Cons: a bit more confusing how to find modes in the original data; harder to incorporate in the GUI post-run viz.
2. Extend the filtering definition in ModeSpec (currently only filter_pol, convert to a filter dictionary or a FilterSpec that defines various filtering options) such that the produced modes are directly filtered as requested. Pros: better-defined, smaller chance to mistake definitions in a mode source or mode monitor, easier to incorporate in GUI. Cons: less flexible, requires a new mode solver for every filtering spec.
3. A combination of the two? But it can make things confusing.

I'm kinda leaning towards option 2. still - @dbochkov-flexcompute @tomflexcompute @xin-flex what do you think?

[dbochkov-flexcompute]

yeah, I agree, I think option 2 is good. Are you thinking of filtering as elimination of modes (threshold for loss, threshold for volume, etc) or reordering of them (order by loss, order by volume, put non-decayed modes to the end, etc)?

[momchil-flex]

yeah, I agree, I think option 2 is good. Are you thinking of filtering as elimination of modes (threshold for loss, threshold for volume, etc) or reordering of them (order by loss, order by volume, put non-decayed modes to the end, etc)?

This is the biggest question... Filtering in the sense of elimination probably makes more sense from the point of view of the user. The biggest issue though is that in our current workflow if a mode source is created with a filtering spec that reduces the number of modes, and mode_index is set to a higher value than what's available after elimination, we need to error. But generally so far we have no workflow that errors by design, we try to catch everything in advance and if an error happens it's something we need to look at. Because of that, it's tempting to go with rearranging. On the other hand, again from user experience, if the mode_index is pointing to some of the filtered out modes, it's likely that something's wrong and the user probably does want the simulation aborted. I'm just not sure how to set it up though.