[PIPE2D-1244] Plan for data acquisition for July 2023 run Created: 01/Jul/23 Updated: 30/Aug/23 Resolved: 30/Aug/23 |
|
| Status: | Done |
| Project: | DRP 2-D Pipeline |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | arnaud.lefur | Assignee: | arnaud.lefur |
| Resolution: | Done | Votes: | 0 |
| Labels: | EngRun | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | 2DDRP-2023 A | ||||||||
| Description |
|
Here is the list of calibration that we need to reduce the data properly based on experience from previous runs :
|
| Comments |
| Comment by rhl [ 01/Jul/23 ] |
|
Can we add a few more details? Which lamps, and what do we want to do about persistence? What does "can be non-simultaneous" mean? That we can take sub-exposures to reach 30k counts (meaning photons not DN?)? Do we need brn to be all taken at the same time? For item 2 (fiber configuration allHome) how many counts do we need (peak and near the dichroics)? Do we need all of brn, or can we do br and rn separately if needs be? Maybe the best way to be sure that we know exactly what we need would be a list of exposures, albeit with unknown exposure times. |
| Comment by price [ 07/Jul/23 ] |
|
I believe "non-simultaneous" means that b/r/n exposures may be taken at different times. The goal of item 1 is measurement of the profile in each arm, for which we do not need to be able to compare fluxes across arms. Item 2 is for the normalisation measurement (hence the need for simultaneous exposures so we can compare fluxes across arms). This behaves in our pipeline like a flat-field (divides every science exposure), so it needs to have good signal-to-noise everywhere we care about. For a starting proposal, how about a minimum total across exposures of 10k electrons (S/N ~ 100) at the dichroic crossover points, with a minimum of 3 exposures? Item 2 must be simultaneous b/r/n. Please do not do b/r and r/n separately, because that would produce separate normalisations for r (maybe we could deal with that in software if we had to, but in my opinion it's not worth the loss of time or loss of confidence in the result). |
| Comment by rhl [ 11/Jul/23 ] |
|
We should also take data to see how the flat non-uniformity depends on the instrument rotator. In particular, we expect the pattern from the ring lamps and the JEG lamps to be fixed in dome coordinates. It'd be good to investigate the twilight sky as a function of rotator angle too, but that's harder. Maybe take different rotator angles on different nights? |
| Comment by price [ 12/Jul/23 ] |
|
To characterise the backgrounds, we want to observe a variety of input spectra and measure the background.
There are no timing or sequence requirements on any of the above observations, except that it would be good to get an allHome observation for every corresponding mod32 observation (but they needn't be back-to-back, just take some effort to try to get the same input spectrum). |
| Comment by price [ 14/Jul/23 ] |
|
For commissioning n3, we will need a full set of calibs:
For all arms (brn and m), we need
May as well get some good biases for b/r to track any changes. |
| Comment by price [ 14/Jul/23 ] |
|
For dithered flats, we want 3 exposures at each dither position (so we can remove image artifacts), observed back-to-back. Apart from that requirement, dither positions may be obtained at different times. I'm curious about the repeatability of the hexapod. Can we take an arc at the home hexapod position, move the hexapod around a bunch, then return to the home hexapod position and take the arc again? |
| Comment by arnaud.lefur [ 15/Jul/23 ] |
|
price about hexapod repeatability, it's an interesting study but we can use DCB / IIS for that matter. |
| Comment by price [ 15/Jul/23 ] |
|
I'm not worried about persistence. While I'm sure it's an important effect, it doesn't seem to be debilitating (I didn't worry about it last time) and so I'm tempted to suggest we simply skip the interleaved darks so we can get a product which will be good-enough until we figure out how to deal with the persistence properly. |
| Comment by yuki.moritani [ 18/Jul/23 ] |
|
arnaud.lefur Could you confirm that data in red and orange are must-to-take at the beginning of the run?
Following the previous run, are 3 frames per line OK? We may need to optimize exposure time for n band. In regard to quartz for detectorMap, it it OK to use 60s? Or should we take longer? |
| Comment by arnaud.lefur [ 18/Jul/23 ] |
|
That's right, highest priority. |
| Comment by Wilfred Gee [ 21/Jul/23 ] |
|
Sorry if you got an alert, I pressed some key command that assigned this to me by mistake but switched it back. |
| Comment by rhl [ 27/Jul/23 ] |
|
I don't think we need twilight m-band. The only difference from r is the grating, so we can measure the throughputs using quartz in rm and r-band on-sky data. Actually, I don't think we need twilight data in more than one band, but it comes for free. And, of course, comparing the three sets of arms will be interesting as a sanity check. |
| Comment by arnaud.lefur [ 30/Aug/23 ] |
|
Run12 is now over, calibration data can be found here . |