Issue in reduced master dome flats and striped features throughout final data cubes after running through red arm reduction pipeline

[chloeneufeld]

I am trying to reduce the red side data for one of my objects and am running into an issue where I’m getting weird stripes/edge effects throughout parts of the final reduced object frame (which makes it near impossible to analyze any emission line features), as well as several calibration frames. For context, this is the large slicer with the RH2 grating and CWAVE = 6689.98, and the calibrations were done in the morning.

From the same night, I have also reduced another object from a different configuration (again large slicer with RH2 grating; only difference is the central wavelength and that cals were done in the evening), and the resulting reduction looks fine (i.e., no weird vertical stripes throughout the reduced object cube).

I have checked several steps throughout the pipeline, including master flats/arcs and slice/wavelength/position maps, all of which look normal (compared to the well-reduced object). The weird thing in the calibration reductions that I have noticed is that the stacked dome flats (frame kr_sdome.fits, which are the stacked, but un-merged dome flats) looks fine; it is the master dome flat (frame kr_mdome.fits) that looks a but wonky. This I believe is causing the final reduced object frame to have the weird features. Below I compare the stacked dome flats of the “good reduction” calibrations on the left vs. the “bad reduction” calibrations on the right — they both look fine.

Then I compare the master dome flats, and this is where the issue arises: the master dome flat for the good reduction (left) looks normal, but the bad reduction (right two frames showing different scalings) has a weird edge effect and extremely high counts here. So something is happening when the pipeline goes from the stack of dome flats to the “master” dome flat; I am not sure what steps are between, but I think it has something to do with solving the arcs/geometry for the final data cubes.

If helpful for troubleshooting, the first frame I noticed looking off is one named kr*_icube_2d.fits, which I think is created after creating the master arcs and then extracting and solving the arcs/geometry to then generate this cube. Below compares the object that is well reduced on the left, with the object that has weird features in the final reduction on the right. I’m not exactly sure what/where this frame comes from in the pipeline, but it really highlights the difference between the reduction of these two objects/configurations.

Any help in solving this issue would be appreciated!

[gannonjs]

Hi Chloe,

in the video at the top much of the striping looks like the usual junk at the start/end of the data cube and the cosmic rays floating through the red.

Something we've found with RH2 is that sometimes the lamps have different power levels so the standard calibration exposure times night to night can have very different S/N. Have you compared the S/N levels in the arcbars and check to see they are saturating/not underexposed. Alternatively have you tried just using cals in the same setup from a different night?

[chloeneufeld]

Hi Jonah, thanks for responding!

The striping also occurs throughout the data cube (not just at the start/end), which is why I am concerned that something is not right. Also, the master dome clearly has something wrong with it. Unfortunately, we only took cals in this configuration on the first night, so I don't have another night to compare to.

The other configuration that I compared to in the github issue that was successfully reduced was also RH2, just at a different central wavelength. The arcs have roughly the same counts in both of these RH2 configurations, and there is no other issue that I can see in the raw calibration frames between these two; for some reason, one RH2 configuration reduces fine, while the other has a bad master dome reduction and bad overall object reductions.

On Wed, Nov 20, 2024 at 8:29 PM Jonah Gannon @.***> wrote:

Hi Chloe,

in the video at the top much of the striping looks like the usual junk at the start/end of the data cube and the cosmic rays floating through the red.

Something we've found with RH2 is that sometimes the lamps have different power levels so the standard calibration exposure times night to night can have very different S/N. Have you compared the S/N levels in the arcbars and check to see they are saturating/not underexposed. Alternatively have you tried just using cals in the same setup from a different night?

— Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/KCWI_DRP/issues/178#issuecomment-2489878946, or unsubscribe https://github.com/notifications/unsubscribe-auth/A25OFAQFB6IVFRX5BTLXMM32BUZPTAVCNFSM6AAAAABRU2R62WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBZHA3TQOJUGY . You are receiving this because you authored the thread.Message ID: @.***>

[gannonjs]

No worries, happy to help if I can. Have you tried getting some cals for the same configuration from someone else and running the reduction with them? e.g. I can provide some medium/RH2/6750 central cals if needed. Otherwise, I have heard of people piggybacking off other KCWI observers to take a set of cals as theirs were corrupted.

Note: to get the pipeline to run with cals from a different night you will need to edit the header of cals so that they get put in the same grouping for reduction. I forget which items, but certainly the name of the configuration and the observation date to start.