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

Masking Spectra #128

Open
ericasaw opened this issue Feb 20, 2023 · 6 comments
Open

Masking Spectra #128

ericasaw opened this issue Feb 20, 2023 · 6 comments

Comments

@ericasaw
Copy link
Collaborator

I've been playing with the apply_numpy_mask function in utilities.py today since I ran into some issues masking my spectra with the specutils extract_region function (and it's just super slow) but I was running into an error I don't fully understand. I mask my spectra so that I only have a super narrow region plotted and apply the mask (which works). Then I attempt to plot the normalized masked spectrum and run into the following error:

ValueError: Flux axis ((1,)) and mask (()) shapes must be the same.

It looks like it is coming from line 405 in spectrum1d.py where it is checking two shapes against each other. However, this line is kind of strange to me since the mask should be the length of the unmasked spectrum and the flux values of the new masked spectrum should only be the length of where the mask == 1. Unless the object is still referencing the original unmasked values when trying to plot? I'm not really sure what is happening here.

@gully
Copy link
Member

gully commented Feb 20, 2023

This friction stems from the use of masked arrays in specutils. We don't use those, so we've tried to ignore them, but it looks like it might be off here. A workaround would be to override the mask with something like mask=np.ones(len(output_flux)), wherever the output flux is getting masked in apply_numpy_mask.

@kfkaplan
Copy link
Collaborator

kfkaplan commented Feb 20, 2023

If my changes did cause the issue, try running it under this branch https://github.com/OttoStruve/muler/tree/fixing_igrins_snr from PR #127 where I went back and tried to fix all the issues in main and see if that fixes the problem or not.

@ericasaw
Copy link
Collaborator Author

ericasaw commented Feb 20, 2023

Tried running it with the new branch but I end up with the same error @kfkaplan

Good to note this error is not on a rtell file but on just a normal spec_a0v file

@kfkaplan
Copy link
Collaborator

kfkaplan commented Feb 20, 2023

Is there an accompanying .variance.fits or .sn.fits file in the same directory as the spec_a0v.fits file? Muler will look for one then the other. If neither are found, there will be no uncertainty to read in and that could be causing the error.

@ericasaw
Copy link
Collaborator Author

ericasaw commented Feb 20, 2023

both the .variance and .sn files are in the same directory as the spec_a0v file

another note is that if I revert commits the band math no longer works :-(

@ericasaw
Copy link
Collaborator Author

ericasaw commented Feb 21, 2023 via email

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

No branches or pull requests

3 participants