Align flash_response_index labels with filtered FRI coordinate order

[Copilot]

EnsembleView.flash_response_index() could pass user-requested cell_types as labels while plotting FRI values in xarray’s filtered coordinate order, causing mislabeled violins when the two orders differed. This change keeps data-label mapping consistent and still preserves caller-defined display ordering.

• Behavioral fix in EnsembleView.flash_response_index

  • When cell_types is provided, the method now uses fris.cell_type.values (post-filter coordinate order) as the label array passed to plot_fris.
  • The original requested list is retained as sorted_type_list (unless already provided) so display sorting can still follow caller intent.

• Regression coverage

  • Added a focused unit test in tests/test_ensemble_view.py that reproduces a mismatched requested-vs-filtered order and asserts:
    • plotted labels match filtered FRI coordinate order
    • requested order is preserved via sorted_type_list

if cell_types is not None:
    requested_cell_types = cell_types
    fris = fris.custom.where(cell_type=cell_types)
    cell_types = fris.cell_type.values
    kwargs.setdefault("sorted_type_list", requested_cell_types)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>flash_response_index() data-label misalignment when filtering by cell type</issue_title>
<issue_description>## Bug

EnsembleView.flash_response_index() produces misaligned data and labels when a subset of cell types is requested via the cell_types parameter.

Root cause

In ensemble_view.py, flash_response_index() filters the FRI DataArray with fris.custom.where(cell_type=cell_types). This preserves xarray's internal (alphabetical) coordinate order for the data values. However, the original cell_types list (in the caller's order) is passed directly to plot_fris() as the label array. When the caller's order differs from alphabetical coordinate order, the plotted violin data and x-axis labels become misaligned.

Example

Requesting cell_types=["Mi1", "Tm3", "Mi4", "Mi9", "CT1(M10)", "Tm1", "Tm2", "Tm4", "Tm9"] for TmY3 inputs:

• fris.custom.where() returns data ordered by coordinate: CT1(M10), Mi1, Mi4, Mi9, Tm1, Tm2, Tm3, Tm4, Tm9
• But the label list passed to plot_fris is still Mi1, Tm3, Mi4, Mi9, CT1(M10), Tm1, Tm2, Tm4, Tm9
• Result: violins are visually mislabeled (e.g., CT1(M10) data appears under the Mi1 label)

Workaround

After filtering, extract the actual coordinate order and pass it as the label list:

filtered = fris.custom.where(cell_type=cell_types)
actual_order = list(filtered.cell_type.values)
plot_fris(
    filtered.values,
    actual_order,
    sorted_type_list=desired_display_order,
    ...
)

Suggested fix

In EnsembleView.flash_response_index(), either:

1. Reindex the filtered DataArray to match the requested cell_types order before extracting .values, or
2. Pass list(fris.cell_type.values) (the actual coordinate order) as the cell_types argument to plot_fris, with cell_types (the user's order) as sorted_type_list.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes flash_response_index() data-label misalignment when filtering by cell type #17

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes a data-label misalignment bug in EnsembleView.flash_response_index() that occurred when filtering by cell types. The issue arose because xarray's custom.where() returns data in alphabetical coordinate order, but the original user-provided cell_types list was passed as labels, causing mismatched violin plots when the orders differed.

Changes:

• Fixed EnsembleView.flash_response_index() to use filtered coordinate order for labels while preserving caller-defined display order
• Added regression test to validate the fix

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
flyvis/network/ensemble_view.py	Fixed data-label alignment by extracting actual coordinate order after filtering and passing original order as sorted_type_list
tests/test_ensemble_view.py	Added unit test that reproduces the bug scenario and validates both label alignment and display order preservation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.