Open ericasaw opened 1 year ago
gully
commented
1 year ago 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
commented
1 year ago If my changes did cause the issue, try running it under this branch https://github.com/OttoStruve/muler/tree/fixing_igrins_snr from PR https://github.com/OttoStruve/muler/pull/127 where I went back and tried to fix all the issues in main and see if that fixes the problem or not.
ericasaw
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago I did a little investigating this morning and it looks like there is an issue with the uncertainty array turning into nan’s before kyles commit, probably something propagated from when I added in reading the rtell files. I’m trying to track down the exact area but Im not sure I’ll have it resolved today.
On Mon, Feb 20, 2023 at 4:27 PM kfkaplan @.***> wrote:
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 none are neither, there will be no uncertainty to read in and that could be causing the error.
— Reply to this email directly, view it on GitHub https://github.com/OttoStruve/muler/issues/128#issuecomment-1437622306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMC7LDM4EPLY7IQBWYIIBJ3WYPVTLANCNFSM6AAAAAAVCH7PAM . You are receiving this because you authored the thread.Message ID: @.***>
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.