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 with_spectral_unit #1119

Merged
merged 15 commits into from
Feb 1, 2024
Merged

Fix with_spectral_unit #1119

merged 15 commits into from
Feb 1, 2024

Conversation

rosteen
Copy link
Contributor

@rosteen rosteen commented Jan 22, 2024

This has been needed for a long time - intended to fix #995 , #889 , #676. My current changes fix the behavior for a Spectrum1D initialized with a spectral_axis, but I think it needs a little more work to also fix it for one initialized with a wcs. Note that this also moves the SpectralGWCS out of gwcs_from_array so that it's actually accessible to check instances, since there are times we may want to do something different if that's the WCS type.

@rosteen rosteen added the bug label Jan 22, 2024
@rosteen rosteen added this to the v1.x milestone Jan 22, 2024
@rosteen
Copy link
Contributor Author

rosteen commented Jan 23, 2024

Ok, I realized the existing WCS-initialized spectrum case was just acting on the spectral_axis as well, so I didn't need the a special case for the spectral_axis-initialized case and handle both the same way. It would probably be more ideal to preserve as much of the original WCS as possible while changing the unit, but that can be work for another day. This at least restores the previous (intended) functionality.

@rosteen rosteen requested a review from dhomeier January 23, 2024 00:12
return super().pixel_to_world(*args, **kwargs).to(
self.original_unit, equivalencies=u.spectral())


Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps just copy [pun-trigger!] over
https://github.com/astropy/astropy/blob/97bf1e123feec3170e2244964b0df2852b8e54e1/astropy/wcs/wcs.py#L633-L644
ff here as well for compatibility and to fix CI failure?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Weird, I thought I ran the tests locally after adding that, guess not. Thanks for the link.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually the tests do pass locally, I must have the IERS files cached.

@rosteen rosteen changed the title Fix with_spectral_axis Fix with_spectral_unit Jan 23, 2024
@rosteen
Copy link
Contributor Author

rosteen commented Jan 23, 2024

Looks like the remaining failures are a (hopefully transient) download failure:

astropy.utils.iers.iers.IERSWarning: failed to download https://datacenter.iers.org/data/9/finals2000A.all: <urlopen error [Errno -3] Temporary failure in name resolution>

@dhomeier
Copy link
Contributor

Yes, seen those frequently, although they did not show up in the previous run; unlikely this was introduced by adding the copy methods. Can maybe check if astropy has done something to avoid these connection failures.

@dhomeier
Copy link
Contributor

Seems the last solution was just to wait till DNS is working again... astropy/astropy#15456

@rosteen
Copy link
Contributor Author

rosteen commented Jan 23, 2024

@dhomeier I switched to deepcopy and added a test to check that the stored copy of the original WCS has the original unit. If this looks good to you now would you approve so I can merge? Thanks!

@dhomeier
Copy link
Contributor

dhomeier commented Jan 23, 2024

The test I did locally to verify it really needs deepcopy was (kinda brute force) setting new_spec.wcs.cdelt (with an Astropy WCS) to different values and check if the original spec.wcs.cdelt was changed by this. But SpectralGWCS might not be modified that easily, so maybe that's overkill.
Just noted that the entire meta is copied as well; being a dictionary, this would probably need a deepcopy as well to ensure you have separate objects.

@rosteen
Copy link
Contributor Author

rosteen commented Jan 23, 2024

check if the original spec.wcs.cdelt was changed by this

Doesn't checking that the world_axis_units is different between the original WCS and new WCS confirm that they are different objects? I think this test is accomplishing the same thing as yours.

Just noted that the entire meta is copied as well; being a dictionary, this would probably need a deepcopy as well to ensure you have separate objects.

The meta is an OrderedDict, which doesn't seem to have deepcopy. I just confirmed that meta is self._meta returns False after the copy, so I think this is ok.

Copy link
Contributor

@dhomeier dhomeier left a comment

Choose a reason for hiding this comment

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

Tried to set up an example of the deepcopy tests I commented on – setting Spectrum1D.meta itself is not foolproof though, so one might argue it is the user's responsibility not to mess with (shallow-)copied instances.

specutils/spectra/spectrum_mixin.py Outdated Show resolved Hide resolved
specutils/tests/test_spectrum1d.py Show resolved Hide resolved
Copy link

codecov bot commented Jan 30, 2024

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (4723206) 70.89% compared to head (90f92c6) 70.93%.
Report is 2 commits behind head on main.

❗ Current head 90f92c6 differs from pull request most recent head 2e357c8. Consider uploading reports for the commit 2e357c8 to get more accurate results

Files Patch % Lines
specutils/spectra/spectrum_mixin.py 92.85% 1 Missing ⚠️
specutils/utils/wcs_utils.py 92.30% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1119      +/-   ##
==========================================
+ Coverage   70.89%   70.93%   +0.03%     
==========================================
  Files          64       61       -3     
  Lines        4501     4221     -280     
==========================================
- Hits         3191     2994     -197     
+ Misses       1310     1227      -83     

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

@rosteen
Copy link
Contributor Author

rosteen commented Jan 30, 2024

@dhomeier I did update the docstring already to explain what happens to the original WCS, is that enough to address the concern you brought up about documentation earlier today offline?

Copy link
Contributor

@dhomeier dhomeier left a comment

Choose a reason for hiding this comment

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

Thanks; leaving some final remarks on the docs, but this looks good now!

specutils/spectra/spectrum_mixin.py Outdated Show resolved Hide resolved
Co-authored-by: Derek Homeier <[email protected]>
@dhomeier
Copy link
Contributor

dhomeier commented Feb 1, 2024

Not sure – do we get

WARNING: py:class reference target not found: specutils.utils.wcs_utils.SpectralGWCS

because that version is not in the online docs yet, or actually because SpectralGWCS does not have a docstring yet?

But I am seeing other broken links into utils that apparently have not broken the build.

Copy link
Contributor

@dhomeier dhomeier left a comment

Choose a reason for hiding this comment

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

Original problem solved, new barrel opened!
And just seeing uncertainty.py has an overwhich typo copied all over.
At least the docs are getting a good overhaul now. :D

specutils/analysis/moment.py Show resolved Hide resolved
specutils/analysis/uncertainty.py Show resolved Hide resolved
specutils/analysis/uncertainty.py Show resolved Hide resolved
specutils/analysis/uncertainty.py Show resolved Hide resolved
specutils/analysis/uncertainty.py Show resolved Hide resolved
@rosteen
Copy link
Contributor Author

rosteen commented Feb 1, 2024

@dhomeier After some tinkering I couldn't get that doc link to work (I was breaking more things...) so I decided to just make the docstring a little more descriptive here for now as a compromise. I pointed those other utils doc links to the proper place, but they still seem to be broken rather than linking 🤔. I'll come back to that at some point but I have more pressing concerns at the moment.

@rosteen
Copy link
Contributor Author

rosteen commented Feb 1, 2024

@dhomeier As I commented above on one of your suggestions, you can see here that using the full path to SpectralRegion doesn't fix the broken links. If you want to debug that and open a follow-up PR that would be awesome, but I don't think it should hold up this one.

@dhomeier
Copy link
Contributor

dhomeier commented Feb 1, 2024

Sorry, was a bit too fast in committing then – maybe you should force-push again to revert.
Sphinx keeps puzzling me; I just noted that in the docs themselves the recommended path is

from specutils.spectra import SpectralRegion

but this can wait for another PR as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Spectrum1D.with_spectral_unit broken
2 participants