[PIPE2D-1122] Investigate poor detectorMap adjustment in r1 Created: 02/Dec/22  Updated: 03/Feb/23  Resolved: 09/Dec/22

Status: Done
Project: DRP 2-D Pipeline
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Normal
Reporter: price Assignee: price
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File pipe2d-1122.ipynb    
Reviewers: hassan

 Description   

Satoshi Hamano reports that the detectorMap adjustment of 80906r1 has very poor quality.
Running with w.2022.46, I get the following summary stats:

reduceExposure.adjustDetectorMap INFO: Final result: chi2=107354.909901 dof=44438 xRMS=0.063492 yRMS=0.234515 xSoften=0.040791 ySoften=0.049777 from 34832 lines
reduceExposure.adjustDetectorMap INFO: Stats for OH: chi2=60810.024394 dof=19260 xRMS=0.081180 yRMS=0.234515 xSoften=0.000000 ySoften=0.345114 from 9630 lines
reduceExposure.adjustDetectorMap INFO: Stats for OI: chi2=0.000000 dof=0 xRMS=nan yRMS=nan xSoften=0.000000 ySoften=0.000000 from 0 lines
reduceExposure.adjustDetectorMap INFO: Stats for Trace: chi2=46544.885507 dof=25202 xRMS=0.060551 yRMS=nan xSoften=0.051768 ySoften=0.000000 from 25202 lines

The "Final result" line looks like it might be acceptable at first glance, judging from the xSoften and ySoften values being ~ 0.05; though the yRMS value of 0.23 is concerning, one might think that it's just reflecting measurement errors. But when looking at the stats for OH lines, we see ySoften=0.345 and that's just unacceptable.

The expected position of lines using the adjusted detectorMap do not visually coincide with the lines on the image.

 Comments   
Comment by price [ 02/Dec/22 ]

I've become dissatisfied with the current sky linelist, and believe it's the main reason we're having trouble adjusting the detectorMap in this case. The main reason is that it merges the Osterbrock and Rousselot lists in an unprincipled manner. The Osterbrock list is linked to observations, while the Rousselot list is a theoretical list without line strengths (the original paper was focussed on NIR observations, and the linelist in the optical appears to have gotten tagged on for use by ESO). Merging the two lists without regard to the line identifications or strengths means that the wavelength of the merged lines can be inaccurate. Furthermore, by merging lines indiscriminately, it becomes difficult to identify lines that are blended.
I'd like to replace the current sky linelist with a new one that I have constructed solely from the Osterbrock list (at least for the wavelength range it covers). I've only merged lines when they are within 0.1 nm and I believe there is reason to expect them to have the same strength (e/f and P1/P2, etc.).
With the current linelist, running on 80906r1, I get (after a variety of fixes):

reduceExposure.adjustDetectorMap INFO: Final result: chi2=2483923.321630 dof=38826 xRMS=0.055762 yRMS=0.643215 xSoften=0.000000 ySoften=0.510687 from 19425 lines

Notice that the ySoften value of ~0.5 pixels is telling us that there are severe systematic problems with the fit in the spectral dimension (the fit in the spatial dimension is excellent). This is running with an exclusion radius of 3 pixels, so blends should be ignored (but they aren't). The new linelist gives:

reduceExposure.adjustDetectorMap INFO: Final result: chi2=25275.377851 dof=23700 xRMS=0.057707 yRMS=0.062246 xSoften=0.000000 ySoften=0.000000 from 11862 lines

There are fewer lines (11k vs 19k) used in the fit because we have much more reliable blend identification, and that makes the fit much better: ySoften=0, which means that any errors in the fit are caused by the statistical noise in the data rather than systematics.

Comment by price [ 02/Dec/22 ]

Attached the notebook that I used to merge the Osterbrock lines and measure the (merged) line intensities. It also contains code to do a cross-correlation of the image and linelist for various detectorMap offsets, which might be helpful in the future.

Comment by hassan [ 03/Dec/22 ]

I think all the suggested changes and revised linelist look fine to me.

Comment by price [ 07/Dec/22 ]

Taking this back after review to work on additional detectorMap adjustment updates.

Comment by price [ 08/Dec/22 ]

Made a few additional changes based on the DRP technical meeting of 2022-12-05 to protect some lines from the exclusion zone.

Ready for new review.

Comment by hassan [ 09/Dec/22 ]

Additional changes look fine. Might need to re-phrase one commit comment for drp_stella. See my comments in the pull request. 

Comment by price [ 09/Dec/22 ]

Reworded that commit, and merged.

Comment by price [ 03/Feb/23 ]

Origin of the oh.dat file with the Osterbrock lines: https://cdsarc.cds.unistra.fr/viz-bin/cat/III/211

Generated at Sat Feb 10 16:03:03 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.