Fix specviz2d model fit linking

[pllim]

Description

This pull request is to fix modeling fitting linking in Specviz2D so that fitted model does not appear weird over x=0 and would instead plot properly on 1D spectrum viewer. We do not support 2D model fit, so it will never have to display in 2D spectrum viewer.

With this patch:

Change log entry

• Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
  list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
  should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• Do the proposed changes follow the STScI Style Guides?
• Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• Did the CI pass? If not, are the failures related?
• Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)? 🐱

[pllim]

Without this patch, this test would fail on main as such:

>       assert elink.data1.label == "Spectrum 1D" and elink.data2.label == "model", (elink.data1.label, elink.data2.label)  # noqa: E501
E       AssertionError: ('Spectrum 2D', 'model')
E       assert ('Spectrum 2D' == 'Spectrum 1D'
E
E         - Spectrum 1D
E         ?          ^
E         + Spectrum 2D
E         ?          ^)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.53%. Comparing base (2ed942d) to head (ab36fe0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3434   +/-   ##
=======================================
  Coverage   87.53%   87.53%           
=======================================
  Files         128      128           
  Lines       19962    19962           
=======================================
  Hits        17474    17474           
  Misses       2488     2488           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pllim]

Question for @gibsongreen , is this still needed after #2736 ?

[gibsongreen]

Question for @gibsongreen , is this still needed after #2736 ?

I tested on main a bit and was having trouble reproducing the original bug. I just tested on the commit prior to merging said PR and saw y ~= 0 (horizontal line) instead of a vertical line of x = 1 (in essence the same issue). #2736 definitely positively impacted the modeling fitting, let me test a few more spectra and see if I can still find the bug on main.

[gibsongreen]

I tested a few more spectra on main and still haven't been able to reproduce the bug, if you and @cshanahan1 see the same thing then maybe the app.py logic can be scrapped, but it is still beneficial to merge the additional test coverage added here.

[pllim]

@gibsongreen if you run just that test on main, it still fails. So 🤷‍♀️

[kecnry]

can we just try removing the code changes from this PR but keeping the regression test? If that passes, then we know the previous PR fixed the problem as well and we can get the test in here, right?

[pllim]

removing the code changes from this PR but keeping the regression test?

I did that locally. It fails without the patch. But I also don't grok specviz2d linking.

[gibsongreen]

We could look at the mark that was created for the model and calculate the min/max for y and x, get the min and max values also for the spectrum, and see if the model mark is within the bounds of the spectrum. It would be somewhat similar to the test here only would also have to account for y:

jdaviz/jdaviz/tests/test_subsets.py

Line 772 in 4cfa7a1

subset_drawn_2d = viewer_1d.native_marks[-1]

[pllim]

Since the original bug I am trying to fix is no longer reproducible and the test I added here becomes irrelevant, I motion the following action items:

1. Close this PR without merge.
2. Archive the associated JIRA ticket.
3. Open a follow up ticket to add this test that Gilbert came up with.