[PIPE2D-1135] Ring lamp needs to be recognised as a lamp Created: 18/Dec/22 Updated: 08/Feb/23 Resolved: 23/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: | rhl | Assignee: | hassan |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | 2DDRP-2023 A |
| Reviewers: | price |
| Description |
|
The pipeline helpfully assumes that if there are no lamps turned on, then the exposure's on the sky and OI, NaI, and OH lines should be present: reduceExposure.readLineList INFO: No lamps on; assuming sky. Unfortunately, the quartz lamps aren't checked when making this guess. Please make sure that we don't look for sky lines when extracting spectra from quartzes (which is a useful check of e.g. fibre normalisations) |
| Comments |
| Comment by price [ 20/Dec/22 ] |
|
The requested behaviour has been implemented for a very long time. ReadLineListTask.getLampInfo calls getLamps, which returns "Quartz", and therefore the "No lamps on; assuming sky." log message and associated behaviour should not fire. You didn't provide information on how to reproduce your problem, but I suspect you may be looking at an exposure that requires a header fix. Perhaps the header fix has been implemented (in pfs_utils) but your corrections database (in obs_pfs) hasn't been rebuilt? |
| Comment by price [ 20/Dec/22 ] |
|
hassan points out that there are some exposures which are "dome flats" using the top-end ring lamps, which apparently is a separate mode from the "Quartz" lamps. It looks like we can recognise these through the W_TFFnVC (commanded) and W_TFFnVV (measured) header keywords (for n = 1..4). I'll add support for that now. |
| Comment by hassan [ 20/Dec/22 ] |
|
Sorry, Paul, but cloomis mentioned to me that he was thinking of adding a summary card for such exposures. Maybe we should discuss with Craig before implementing anything for now? |
| Comment by rhl [ 20/Dec/22 ] |
|
Ah, OK. So the problem is that we're not setting the quartz header card (W_AITQTH). Closing as invalid (except I can't; closing as won't fix); cf. INSTRM-1766 |
| Comment by cloomis [ 20/Dec/22 ] |
|
Those W_TFF cards are the "internal" cards which were added for the 2022-11 run, and we did not understand their actual behavior. We now do and can add the summary `W_AITQTH`. |
| Comment by price [ 20/Dec/22 ] |
|
I understand that cloomis will set W_AITQTH when the ring lamp is on, and that's good enough for future data, but we need to set W_AITQTH for the existing dome flats taken with the ring lamps. |
| Comment by hassan [ 21/Dec/22 ] |
|
200 domeFlat visits were identified from the opDB and header fix code added accordingly. |
| Comment by hassan [ 23/Dec/22 ] |
|
As suggested by Paul, an additional convenience method rangeIncl() added to generate inclusive visit ranges. Code updated to use that method. |
| Comment by hassan [ 23/Dec/22 ] |
|
Merged to master. |