PyWiFeS / pipeline

The Python data reduction pipeline for WiFeS
6 stars 26 forks source link

Auto extraction and splice #52

Closed felipeji closed 3 months ago

felipeji commented 3 months ago

This PR adds routines to automatically extract and splice spectra from the reduced data cubes. It also includes a routine to splice the reduced data cubes so that a single spliced cube is produced from the two observed arms (when available). The main changes and additions are as follows:

New file src/pywifes/extract_spec.py with new functions that will perform the extraction of both blue and red spectra from the data cubes. We have defined different auxiliary functions in extract_spec.py, for example, to automatically detect the three brightest sources, or to plot the field showing the detected sources and the apertures considered for extracting the spectra.

New file src/pywifes/splice.py. The module includes functions based on previous scripts available within the team to splice the extracted spectra, i.e., to join the blue and red spectra into one single spectrum, interpolating the overlapping region. Based on the same function, we wrote a function to splice the entire cubes, so in addition to a blue and a red cube, we obtain a single cube covering the entire wavelength range observed.

We have also included a new function in src/pywifes/data_classifier.py for matching cubes coming from the same observation but different arms (blue/red).

New routines added in the reduction_scripts/reduce_data.py file to classify the resulting reduced spectra for pairing them accordingly and automatically extracting the source and splicing the spectra and the cube (when possible).

Finally, in the reduction_scripts/reduce_data.py, I have implemented a 'try' statement within the loop over the arms, allowing the reduction process to proceed even if data from only one arm is present.

felipeji commented 3 months ago

I have implemented most of your (useful!) comments. I have also run some tests for checking everything still running properly. On one of those test I found a error when more than one aperture is detected. The error come from handling header instead of a copy of it, so the changes in the header produced when operating for one aperture remains in the header variable and trigger and error when try to change the header again for the next iteration (aperture). I fixed by doing (splice.py, line 192):

hdulist[0].header = redSpec.header -> hdulist[0].header = redSpec.header.copy()

I tried to implement most of the changes in the (now called) a_lanczos function. As I commented along the review, I feel not too confident on change it further without testing it carefully, so prefer to do that in a future refactoring.

timothyfrankdavies commented 3 months ago

I have implemented most of your (useful!) comments. I have also run some tests for checking everything still running properly. On

Good work! Hadn't realised the headers were getting overwritten and reused and such. Leaving some refactors to later makes sense to me. Provided the code's in a state where it's easy enough to follow, they can even wait until the code is hit by other PRs making functional changes.

I'll give your updates a look today, then should be good to go!