Propagate trace_npoly in ech_findobj + minor X-Shooter tweaks

[freddavies]

Fixes a bug where the polynomial order for object trace fitting, [reduce] [[findobj]] trace_npoly, was not correctly propagated into ech_objfind_ineach_order, which lead to poor tracing in X-Shooter NIR. Fortunately, it is the only instrument that uses a higher order by default, so this bug probably did not affect many other reductions.

Additionally, I have updated a few parameters of the X-Shooter detectors to reflect the latest version of the manual, and have slightly reduced the order trimming of the NIR detector to keep some more pixels in the order overlap regions, based on visual inspection of bright object traces.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 0% with 14 lines in your changes missing coverage. Please review.

Project coverage is 38.22%. Comparing base (754cb17) to head (0966f40).

Files	Patch %	Lines
pypeit/spectrographs/vlt_xshooter.py	0.00%	13 Missing ⚠️
pypeit/display/display.py	0.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1832   +/-   ##
========================================
  Coverage    38.21%   38.22%           
========================================
  Files          208      208           
  Lines        48414    48419    +5     
========================================
+ Hits         18500    18506    +6     
+ Misses       29914    29913    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kbwestfall]

Thanks @freddavies ! I may be overblowing this, but the changes to the hard-coded detector parameters feel significant. We need to run the tests, but we should also log these changes in the doc/releases/1.16.1dev.rst doc.

I pointed to examples that have an approach to identifying lampoffflats (MOSFIRE) and how to pull detector parameters from file headers (KCWI). Is that something you have time to implement in this PR, or can we find someone that does?

[kbwestfall]

You could follow what @debora-pe did for MOSFIRE.

[freddavies]

I had forgotten that, actually, the lampoffflats were already being identified, but mistyped as dark frames (see the code block immediately above). So it was even easier than I was expecting!

[kbwestfall]

There are a few instruments that pull this kind of information from the header. The one that comes to mind is KCWI.

[freddavies]

I noticed that the binning was already being grabbed via a single line just above, so I followed that example. Let me know if you think it should be done differently.

[freddavies]

I have cleared out the TODOs that I left in the spectrograph file as requested, and have confirmed that the NIR, VIS_1x1, and UVB_1x1 setups in the dev suite pass. I will run the rest of the setups now and update once they are done.

I have added one additional change to set fwhm_fromlines = False to be the default for NIR, as one of the orders seems to often be lost otherwise due to a bad wavelength solution (the dev suite pypeit file also does this). The reason for the poor wavelength solution is unclear, since the automatically measured FWHM looks correct, but the wavelength solution in that order seems to have consistently high RMS. I think investigating that underlying problem is outside the scope of this PR, however.

[debora-pe]

@freddavies thanks for fixing this bug.
I am approving, but please take into account my one comment.

[debora-pe]

same here.

[kbwestfall]

Hi @freddavies. Thanks for adding the release comment, but I thought it would useful to have something more specific so that people don't have to try to look up the changes themselves by digging through the code.

I've started to do this, but in the process I realized that we may not be doing something correctly with the pixel scale. There is a pixel scale defined for each detector, but there is also the order_pixelscale function. Do these need to be consistent? And in some cases the order_pixelscale function doesn't account for the binning. Does that matter?

[freddavies]

@kbwestfall Good point about the order_platescale function -- it appears to be used in object finding for echelle spectrographs instead of the value in the detector dict. I have now made them consistent with the new plate_scale numbers; while they no longer have any order-to-order variation, the typical values seem to be different enough from before that it is probably better to use the new ones.