-
Notifications
You must be signed in to change notification settings - Fork 13
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
Applying barycentric corrections as a part of the DRP? #47
Comments
I believe we could offer this as a standalone method, but probably it won't be implemented in the master release. Thank you for your contribution! I will try to document it on the instruction manual. |
Sure, thanks. It should be added before background subtraction to avoid multiple interpolation of the data. Wavelength.apply_lambda_simple(maskname, band, obsfiles, waveops)
Wavelength.apply_lambda_sky_and_arc(maskname, band, obsfiles, 'Ne.txt', LROIs, waveops)
Wavelength_file = 'merged_lambda_solution_wave_stack_K_m131224_0354-0372_and_wave_stack_K_m131224_0135-0137.fits'
Wavelength.bary_corr(obsfiles, Wavelength_file, maskname, band, waveops)
Background.handle_background(obsfiles,Wavelength_file,maskname,band,waveops) |
Thank you!
|
Hi,
Following observations of same galaxies in different years/months we ran into an issue where the redshifts were off by ~50 km/s. We were gladly ignoring heliocentric/barycentric corrections to our data, forgetting the improved resolution of MOSFIRE + that values can range from positive to negative throughout the year.
This meant that for some of our galaxies, the emission line centroid could be offset by 1-2 pixels.
It took us a while to figure out why this happened, but once we did it was a quick fix.
One of the challenges is that, if you require to add data in 2D between different months, this offsets can produce additional smearing of emission lines, and apart from everything else would be disastrous for kinematic studies. The solution is to interpolate the 2D spectra to a common grid, which means that data will be interpolated at least twice (the first being during rectification). From what I understood from @csteidel in #42, interpolation itself might be problematic and could lead to differences between different algorithms.
So the best solution would be to apply these corrections at the end of the wavelength solution? The lambda_solution_wave_stack has the wavelength solution per pixel which will later be interpolated in to a common grid depending on the filter during the rectification step.
I've written a function within Wavelength.py to perform these corrections shown at the end.
This requires some minor changes to other functions as as well: https://github.com/themiyan/MosfireDRP_Themiyan/tree/master/MOSFIRE
Anyways, just wanted to check if anyone would notice any obvious flaws in doing this using this method?
The text was updated successfully, but these errors were encountered: