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

Make line/continuum fitting work in the mask case (and other mask-related tests) #519

Merged
merged 10 commits into from
Jan 4, 2020

Conversation

eteq
Copy link
Member

@eteq eteq commented Sep 19, 2019

This is the PR I promised in #516. It fixes the line-fitting machinery to ignore any masked parts of the spectrum when doing a fit.

Note this also includes a couple of tests I added in process of the above to ensure the masks behave correctly for arithmetic and spectral regions.

cc @brechmos-stsci @camipacifici @nmearl

(This may particularly benefit from a review by @brechmos-stsci who did a fair amount of the fitting stuff)

Copy link
Contributor

@keflavich keflavich left a comment

Choose a reason for hiding this comment

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

I left a few specific suggestions that are almost entirely stylistic, not content. The changes look fine, but I haven't tried to assess the machinery being modified.

specutils/fitting/fitmodels.py Outdated Show resolved Hide resolved
specutils/fitting/fitmodels.py Show resolved Hide resolved
specutils/fitting/fitmodels.py Outdated Show resolved Hide resolved
# TODO: really the spectral region machinery should have the power
# to create a mask, and we'd just use that...
index_spectrum = Spectrum1D(spectral_axis=spectrum.spectral_axis,
flux=np.arange(spectrum.flux.size).reshape(spectrum.flux.shape)*u.Jy)
Copy link
Contributor

Choose a reason for hiding this comment

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

is the Jy unit addition needed? That adds a small performance hit and is weird for what should be an integer array to begin with (on which note, should this be arange(..., dtype='int')?)

Copy link
Member Author

Choose a reason for hiding this comment

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

The reasoning for this is that Spectrum1D expects flux inputs to be quantities - i.e., you can't give something that's unitless. The choice of Jy is arbitrary, as really any quantity will do, but it seemed safest to use an actual flux. But you're right it makes sense to keep it as an int so I can switch to the explicit u.Quantity(arr, u.Jy, dtype=int)

As the "HACK WARNING" indicates this is defintely a hack, though I think it's probably better just to try to do the "TODO" ASAP instead beyond optimizing this any more.

specutils/tests/spectral_examples.py Outdated Show resolved Hide resolved
specutils/tests/test_fitting.py Outdated Show resolved Hide resolved
@eteq
Copy link
Member Author

eteq commented Dec 24, 2019

I think I've addressed everything, so this should be good to go once the tests pass if @keflavich or @nmearl are willing to approve/merge it.

@nmearl
Copy link
Contributor

nmearl commented Dec 29, 2019

Looks like there's a hold over from the recent MexicanHat model name switch.

@eteq eteq mentioned this pull request Jan 2, 2020
@eteq
Copy link
Member Author

eteq commented Jan 2, 2020

@nmearl - Re the mexicanhat failure: I don't think it's related to this PR. I was about to added it but I realized we should treat it separately because I think we may want to leave the "old" name in for the Astropy 3.x compatible version. So I made a separate PR #564 to address that and propose this be merged separately.

@nmearl
Copy link
Contributor

nmearl commented Jan 2, 2020

Just to clarify: this PR would be in for the astropy 3.x release, but the PR #564 would be included in the astropy 4.x release?

@eteq
Copy link
Member Author

eteq commented Jan 3, 2020

@nmearl - yep, exactly!

@eteq
Copy link
Member Author

eteq commented Jan 4, 2020

(since the test failure is unrelated I think this is good to go, as I'm guessing from the comments that @nmearl has looked at it already)

@eteq eteq merged commit 73f184a into astropy:master Jan 4, 2020
@pllim
Copy link
Member

pllim commented Sep 5, 2024

This PR actually introduced a bug that is being fixed at #1164 . FYI

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

Successfully merging this pull request may close these issues.

4 participants