TO DOs and Ideas - GeminiDRSoftware/DRAGONS GitHub Wiki

Tile amps per array early on instead of keeping them all separated until the mosaic step.

The amps need to be separated for bias correction, overscan correction, noise calculation, conversion to electrons (apply gain). After that it would be more useful to have the amps tiled per CCD, eg. for GMOS.

• What are the advantages?
• What are the implications?
• Any relevant background/historical information?
• Suggestions for primitive and new recipes if we were to do this?

The idea is to remove the static BPMs from the DRAGONS code base and move them to the archive. This would require adding BPM association rules to the archive code (and therefore to GeminiCalMgr).

• What are the advantages?
  • Much smaller code base. The GMOS BPMs are huge and will just continue to multiply.
  • With association rules, it would be easier to select the most appropriate BPM, especially for those Hamamatsu CCDs with artifacts that change frequently.
  • Nicer user experience for user-created BPMs, like for NIRI. The BPM is created, then added to the calibration DB, and automatically associated instead of having to be specified on the command line. This is raises the issue of what to do when there's a user and a static BPM available.
  • ...
• What are the implications?
  • What do to with the association when there's a static and a user BPM available?
  • Requires new version and deployment of the public archive.
  • Requires new conda package for GeminiCalMgr.
• Any relevant background/historical information?
  • ...
• Description of the work:
  • New `getBPM` and `storeBPM` (?) primitives
  • New calibration association rules.
  • ...

The different QEs and color terms of the GMOS CCDs mean that combining mosaicked data can affect the photometry because the same source can have different count rates on different CCDs. There is no solution to this problem but treating each CCD as a separate image will preserve the photometric accuracy. The existing recipe for bias, flat, and fringe correction is probably OK (we need to think about whether the flatfield normalization is correct for this method, which might also depend on whether photometric standards are taken for each CCD).

There are two possible reduction paths:

1. If absolute astrometry is not required, then the WCS of CCDs 1 and 3 needs to be constructed from the WCS of CCD2 and the geometry
2. If absolute astrometry is required, then either:
   1. the astrometry can be derived from CCD2 alone and option (1) performed
   2. the data can be mosaicked and then the WCS for each CCD determined

We also need:

• A primitive to split a multi-slice AstroData into multiple single-slice AstroData objects (probably also useful for spectroscopic data where multiple spectra are in a single AD)