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

Fix unit conversion from flux to surface brightness #2888

Merged
merged 2 commits into from
May 29, 2024

Conversation

astrofrog
Copy link
Collaborator

@astrofrog astrofrog commented May 22, 2024

Description

While looking at issues with limits not updating when changing to certain units, I spotted an unrelated issue. In to_unit, the units on the original data should be irrelevant, and if glue asks for a conversion from e.g. Jy to MJy, we should ignore the original units on the data, since they might already have been previously converted to Jy which is why glue is asking for Jy to MJy. So looking at spec.unit.bases is not the right thing to do. A lot of the change here is indentation so be sure to check the diff ignoring whitespace.

I've expanded the test for to_unit.

There are other issues with the to_unit code as written currently, but I thought I'd break it up into conceptual chunks.

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

@gibsongreen
Copy link
Contributor

gibsongreen commented May 23, 2024

My reasoning for having the additional conditional statements for checking the original units on the data is because the data item from the data collection does not update (nor the units). The numpy array that makes up values in to_unit(), which is the array of values that get converted, come from the data item in the data collection, not what is currently displayed in the profile-viewer? If the data item doesn't update, and these are the values that are converted, each conversion or translation is starting from the original values of the data and the original units.

I did test this PR locally and the behavior does seem to function as expected. I did double check to see what happens to values once multiple conversions or translations occur (and it does match the original values of the data item). So I assume I am overlooking something? I will approve, but do you see what I am missing here that makes this updated logic work?

@astrofrog
Copy link
Collaborator Author

astrofrog commented May 28, 2024

The numpy array that makes up values in to_unit(), which is the array of values that get converted, come from the data item in the data collection, not what is currently displayed in the profile-viewer

This is not always true - in particular in the case of the min/max limits, glue will take the existing limits and convert them to the native data units and then to new units - which means that for one of the calls to to_unit, values will not be in the 'native' data units.

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.

Functionality is maintained with these changes, while simplifying to_unit(). Bearing additional changes in #2889 and #2890, discussed in tagup, the checks for the original units of the data item should not be needed post these 2 PRs.

Copy link

codecov bot commented May 29, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.69%. Comparing base (50ebc1e) to head (d19909a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2888      +/-   ##
==========================================
- Coverage   88.70%   88.69%   -0.01%     
==========================================
  Files         111      111              
  Lines       17125    17122       -3     
==========================================
- Hits        15190    15187       -3     
  Misses       1935     1935              

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

@gibsongreen
Copy link
Contributor

@kecnry per this comment related to CI, they are the 2 same failures here so I will also merge: #2897 (comment)

@gibsongreen gibsongreen merged commit c6e222d into spacetelescope:main May 29, 2024
18 of 19 checks passed
@pllim
Copy link
Contributor

pllim commented May 30, 2024

@astrofrog , this actually added 9 new failures to the devdeps failures galore. See https://github.com/spacetelescope/jdaviz/actions/runs/9292738683/job/25574299461

Ignore these 2:

  • jdaviz/core/tests/test_tools.py::test_stretch_bounds_and_spline
  • jdaviz/configs/imviz/tests/test_simple_aper_phot.py::test_annulus_background

@astrofrog
Copy link
Collaborator Author

@pllim - ok I'll take a look at these failures

@astrofrog
Copy link
Collaborator Author

@pllim - are you sure these aren't due to astropy/specutils#1141?

@astrofrog
Copy link
Collaborator Author

Yes the errors:

E       astropy.units.core.UnitConversionError: 'Jy m' (force) and 'Jy' (spectral flux density) are not convertible

seem to be related to astropy/specutils#1141 (cc @rosteen)

@pllim
Copy link
Contributor

pllim commented Jun 3, 2024

BTW yeah, not caused by this PR after all. Sorry for the noise! #2905

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working no-changelog-entry-needed changelog bot directive testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants