Skip to content

QACITS observation procedure

Practical use of QACITS for HCI centering is described in https://arxiv.org/abs/1607.05497 "The QACITS pointing sensor: from theory to on-sky operation on Keck/NIRC2" by Huby et al. 2016.

They describe a three-step procedure:

  1. calibration sequence:
    • Measure the PSF of the star off-axis.
    • Measure the center of the mask by observing the sky behind the mask and fitting a Gaussian (keeping the star close).
    • Moving the star to the mask.
  2. optimization sequence:
    • Rapid (subsecond dit, low ndit) observations to precisely point the star.
  3. science acquisition sequence:
    • One or more actual science observations (longer dit and ndit).

Step 2 and 3 seems to be an application of the QACITS algorithm, step 2 to get the star behind the mask before observation and step 3 to keep it there during observation.

For this they define five types of observations, performed in sequence:

  • 1 skp: Sky image for the off-axis PSF
  • 1 psf: Off-axis PSF image
  • 1 sky: Sky image for the science and optimization images (with the mask it seems)
  • N opt: Image taken during the optimization sequence
  • M sci: Science image

This raises some questions / thoughts:

  • Do we need an explicit PSF measurement? Or can we get that from elsewhere, e.g. PSF-r? I guess we should have this, and we kinda get this with STAROFFSET already.
  • Do we need specific datatypes for all of the above, with their own DPR.CATG/DPR.TECH/DPR.TYPE? I guess so, because those keywords are the only thing to distinguish data.
  • Does different DPR keywords mean they each need their own template? I guess so, because those keywords are defined in the template as far as I know. But maybe a single template can generate different types of data.
  • These templates should then all be ran in succession, so this would be our first real need to define standard Observation Blocks.
  • However, all this processing will essentially be done online for a single observation run, so from that perspective it might be simpler to keep everything in one template if possible.
  • All readouts need to be stored for persistence determination, so we cannot throw them away.
  • The QACITS algorithm produces several nice plots. Keeping the data will allow us to recreate these plots offline.

@verdoes what do you think?

For now I'll

  • define these as having different DPR keywords
    • which currently require them to have their own templates. This is fine for now.
    • Maybe I'll just number them so it is clear that they belong together.
  • define recipes for each template;
    • STAROFFSET seems to be the processing of the psf and sky image (together), should perhaps be split up
    • STARCENTER seems to be the processing of the opt and sci images (each individually)
    • It is not clear to me how skp (the sky image for the PSF derivation) is actually used, probably as background subtraction or so.
Edited by Hugo Buddelmeijer