Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor unit conversion messaging #3192

Merged
merged 22 commits into from
Sep 26, 2024

Conversation

kecnry
Copy link
Member

@kecnry kecnry commented Sep 12, 2024

Description

This pull request refactors and simplifies the messaging within unit conversion. This currently is branched off of #3156, so should be moved onto main after that is merged.

TODO

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)?

@kecnry kecnry added this to the 4.0 milestone Sep 12, 2024
@github-actions github-actions bot added cubeviz specviz testing imviz plugin Label for plugins common to multiple configurations labels Sep 12, 2024
@kecnry kecnry changed the title refactor unit conv messaging refactor unit conversion messaging Sep 12, 2024
@kecnry kecnry force-pushed the unit-conv-messaging branch 8 times, most recently from 405a11d to cee44db Compare September 16, 2024 15:43
Copy link
Contributor

@pllim pllim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't grok most of the stuff. Just a general review. Thanks.

jdaviz/app.py Outdated
@@ -86,7 +86,16 @@ def equivalent_units(self, data, cid, units):
'erg / (s sr cm2)', 'erg / (Hz s sr cm2)',
'erg / (Angstrom s sr cm2)',
'ph / (Angstrom s sr cm2)', 'ph / (Hz s sr cm2)'
])
]
+ [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need the + operators to chain multiple static lists here? This introduces unnecessary list math, no?

jdaviz/configs/cubeviz/plugins/parsers.py Outdated Show resolved Hide resolved
# If unit is flux per pix2, the type will be 'unknown' rather
# than surface brightness, so have to multiply the pix2 part out
# and check if the numerator is a spectral flux density
if check_if_unit_is_per_solid_angle(unit, return_unit=True) == u.pix*u.pix:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move PIX2 higher up and re-use it throughout the package instead of u.pix*u.pix?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll do this after all these PRs are merged to avoid conflicts

jdaviz/tests/test_utils.py Outdated Show resolved Hide resolved
jdaviz/utils.py Outdated Show resolved Hide resolved
jdaviz/utils.py Outdated Show resolved Hide resolved
@@ -89,6 +89,12 @@ def slice_values(self):
take_inds = [2, 1, 0]
take_inds.remove(self.slice_index)
converted_axis = np.array([])

# Retrieve display units
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just confirming, this was moved because the slice display units don't depend on layer?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, I moved this above the for-loop since it isn't needed to be called repeatedly

Copy link
Contributor

@cshanahan1 cshanahan1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good! left a few comments. This is a great improvement that makes it a lot clearer when unit changing messages are sent.

Could you explain briefly what the changes to slice are doing?

@kecnry
Copy link
Member Author

kecnry commented Sep 23, 2024

Could you explain briefly what the changes to slice are doing?

Sure! Changes to slice do the following:

  • handle the changed order in which the unit gets populated by not even attempting to pull the slice values from a viewer without set units
  • improved cache management to insure that slices are retrieved in the correct units
  • future-proof by separating the unit conversion into its own method so it can be overridden when different equivalencies are needed. This might eventually want to call the more general shared-logic for handling unit conversion app-wide.

@kecnry kecnry force-pushed the unit-conv-messaging branch 2 times, most recently from 235fe11 to 23fcaa6 Compare September 24, 2024 15:18
@kecnry
Copy link
Member Author

kecnry commented Sep 26, 2024

re lag - there actually isn't more lag (as far as I can tell), but rather the attribute display limits are being updated before the spectral y units, and since the y units are what is the most visible immediate change, it feels like more lag. I'm working to try to optimize setting the display limits, since deferring changing those until last would require additional muddy logic.

@kecnry
Copy link
Member Author

kecnry commented Sep 26, 2024

I was actually able to get the y-unit to be updated first and optimize attribute_display_unit - hopefully tests still pass 🤞. Let me know if you still see any noticeable difference in responsiveness between this and main.

Copy link
Contributor

@cshanahan1 cshanahan1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested this again, the issues I commented yesterday are resolved, looks good!

Copy link
Contributor

@gibsongreen gibsongreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through unit_conversion.py one more time and generally retested along with the comments from yesterday. Everything looks good to me, nice work!

@kecnry kecnry merged commit c9425b8 into spacetelescope:main Sep 26, 2024
25 checks passed
@kecnry kecnry deleted the unit-conv-messaging branch September 26, 2024 18:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cubeviz imviz plugin Label for plugins common to multiple configurations Ready for final review specviz testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants