LongSlit reduction

[KeckDRP]

I have implemented a new Driver file and a new reduction strategy for the LongSlit reduction.

In summary, most of the changes are in Flats.py. Rather than trying to determine the slit edges, Flats.py assumes that the parameters manually entered by the user in the driver file are correct, and compiles a slit_edge.npy file based on it. Instead of calling the procedure find_and_fit_edges, handle_flats calls find_longslit_edges For the rest, the driver file is exactly the same as the standard driver file, and does not require a special Longstlit driver.

The new system can deal with full ABBA sequences, because it uses the standard Background and Rectify routines, rather than the special Longslit.py routines.

The limit, at the moment, is that the Offset files must contain observations for only one target, otherwise they will all be combined. I reduced a standard star observation automatically with excellent results.

To see the new longslit pipeline, please clone the Longslit branch here on github. You will find the modified driver in the proper location.

It has only been tested on one set of data, so I am not claiming that it is ready, but I welcome comments and idea.

[csteidel]

Luca- Just for clarification, how does your new implementation know where it should be looking (and how many bars long) the slit should be? Often the longslit calibrations are taken with the full long slit but the actual cal star data are taken with only a subset of the full slit length, near the center of the field, with all of the other bars left wherever they had been for the prior setup. Will your implementation work for the long_2pos configuration (even if one does one of the slits at a time)?
Thanks, Chuck

[lucarizzi]

Chuck

I followed the original scheme devised by Nick.

In the original Longslit driver file, Nick was asking the observers to specify a range of y lines where the slit it, after visually looking at the images.

longslit = {'yrange': [700, 1250], 'row_position': 910}

The row position is a clean part of the spectrum, devoid of science objects, to use for wavelength calibration.

My implementation right now does not work for the long2pos but it is very easy to extend to that: I just have to create another subroutine that generates the appropriate slit_edges.npy file and after that everything should proceed as usual.

I will work on it soon and demonstrate.

Luca

On Jan 14, 2015, at 7:19 PM, csteidel notifications@github.com wrote:

Luca- Just for clarification, how does your new implementation know where it should be looking (and how many bars long) the slit should be? Often the longslit calibrations are taken with the full long slit but the actual cal star data are taken with only a subset of the full slit length, near the center of the field, with all of the other bars left wherever they had been for the prior setup. Will your implementation work for the long_2pos configuration (even if one does one of the slits at a time)?

Thanks, Chuck

— Reply to this email directly or view it on GitHub https://github.com/Mosfire-DataReductionPipeline/MosfireDRP/issues/10#issuecomment-70041051.

[monodera]

I've tried to use the Longslit branch (commit:7e7c06b9d975dd4d7f49df8c3abdcc6398d1920f). My primary interest is the modification to look for usable data for wavelength calibration other than y=1024.

I have a few comments so far.

• As I've commented here, modifying average to sum in Rectify.py could result in incorrect eps by a factor of number of frames. (I saw your reply when I was editing this post. Thanks a lot. I leave it here for a record for others)
• In my dataset (AB pair with Slit Nod by +/-3 arcsec), Rectification introduced in Longslit_driver_new.py produced one negative at the center and two negatives on both sides. Apparently it would multiply the frames by -1 in the opposite way (not sure if it's from the same commit above).

• Maybe this is not relevant here as it's not specific to this branch, but let me ask this question. In Longslit.go(), the default is not to apply flat fielding. Is there any good reason to make this as default? This might be a relatively minor issue compared to other systematics, but it confuse me as making a flat is implicitly set to default in the Longslit driver.

Best, Masato

[KeckDRP]

Dear Masato thank you for taking the time to test the longslit reduction.

On Mar 2, 2015, at 8:24 AM, monodera notifications@github.com wrote:

I've tried to use the Longslit branch (commit:7e7c06b9d975dd4d7f49df8c3abdcc6398d1920f). My primary interest is the modification to look for usable data for wavelength calibration other than y=1024.

I have a few comments so far.

As I've commented here https://github.com/Mosfire-DataReductionPipeline/MosfireDRP/commit/95b9919cce1b11b6b9f64aa1f08bf7e3cd231e2c, modifying average to sum in Rectify.py could result in incorrect eps by a factor of number of frames. (I saw your reply when I was editing this post. Thanks a lot. I leave it here for a record for others)

Indeed, noted and will not be committed as it is.

In my dataset (AB pair with Slit Nod by +/-3 arcsec), Rectification introduced in Longslit_driver_new.py produced one negative at the center and two negatives on both sides. Apparently it would multiply the frames by -1 in the opposite way (not sure if it's from the same commit above).

https://cloud.githubusercontent.com/assets/90394/6447320/a48a744e-c111-11e4-818c-c9586115ce41.png

As you correctly point out, this is a result of my testing and a left over from the long2pos modifications. Look at line 374 in Rectify.py and you will notice that the sign has been changed from -1 to +1. Please change it back on your code and try to rectify again: you should get the right result.

Maybe this is not relevant here as it's not specific to this branch, but let me ask this question. In Longslit.go(), the default is not to apply flat fielding. Is there any good reason to make this as default? This might be a relatively minor issue compared to other systematics, but it confuse me as making a flat is implicitly set to default in the Longslit driver

I don’t actually know about this, as we are no longer using Longslit.go().

. Best, Masato

— Reply to this email directly or view it on GitHub https://github.com/Mosfire-DataReductionPipeline/MosfireDRP/issues/10#issuecomment-76769705.

[monodera]

Hi Luca,

After making changes as you mentioned, it worked for me.

Thanks, Masato

[lucarizzi]

9e3d95634bb25a7151a7ec097e4545715d65a346 takes care of the issues mentioned by @monodera

[KeckDRP]

Implemented