Science Data File Headers
ATC Document number AOW/SOF/AJL/3.1/11/99/ Science Data File Headers
wht-naomi-36 Version Date: 23/11/99
Science instrument data from Adaptive Optics (AO) observations will need a larger than usual number of parameter stored with the file headers. The main reason for this is the need to be able to estimate the point spread function from WFS residuals to use as extra information in data analysis. Also the AO system can be configured in many different ways and these configurations will need to be recorded with the data. Knowing the configuration parameters such as off-axis guide star angle, WFS integration times and system order will be essential in helping the astronomer assess the expected level of AO correction. This requirement applies both to the original ‘owner’ of the data and at least as much to anyone wishing to assess the suitability of the archived data for a particular use.
The AO observing ‘system’ must be able to bring to together information from the science instrument, the telescope and the AO system and attach it unambiguously to the appropriate instrument data. This document describes the final requirements for the data headers. It does the not address the means or the architecture for allowing such a procedure to occur. However where it is already known it attempts to identify the source of each parameter.
Note that these have not yet been set to a priority or an ‘appearance’ order. The next steps of the definitions will be to confirm sources and timings for the data and to agree any groupings in the structures.
Instrument configuration: instrument dependent but likely to include most or all of the following.
1. Instrument Name (may be picked up from instrument or from telescope overall observing system?).
2. Observer (comment as above).
3. Observing Programme Reference Number (comment as above).
4. Filter(s).
5. Camera module.
6. Cold stop aperture.
7. Grating ID.
8. Grating angle setting.
9. Detector / chip ID.
10. Chip (CCD or IR array) read-out configuration (size, binning).
11. Chip readout mode (e.g. non-destructive read, overscan etc).
12. Detector gain (e.g. electrons per data number)
13. Chip focal plane scale (x, y arcsec/pxl).
14. Chip orientation (e.g. angle of rotation relative to a nominal instrument direction).
15. On-chip integration time.
16. Number of integrations co-added in saved data frame.
17. Total exposure time.
18. Bits per pixel.
19. Number of axes (for hierarchical data including spectroscopy).
20. The data array itself!
21. Data array history (if any further processing has been carried out).
22. Science Object name (source could be either instrument or telescope system but perhaps is most likely to be telescope).
23. U.T. Date and Time of observation (nominally start time and either end time measured directly or calculated from total exposure time - possibly both but at least the measured end time in case any interrupts invalidate the calculated value).
24. Comments (source could be from any or all of instrument, telescope or AO system ? Probably best to have separate Comment area for each of the above - this will be taken as the requirement).
25. Unique observation number
26. Number in a particular sequence (e.g. within a jitter pattern).
27. Expected total number in sequence (unique ‘other’ number or ID if this number is not defined).
28. Type of observation (e.g. Object, Standard, Sky, Dark, Bias, NCU Flat Field…)
29. Other relevant instrument parameters (array temperature, bias voltages, read rates etc)
30. Bad pixel identification method (if any)
31. Instrument accessory information (some accessories may be used simultaneously)
(a) FP x, y, z
(b) Polarimetry waveplate information
(c) Coronagraph information
(d) IFU information (scale, field split (Yes/No), split angle)
32. NAOMI Observing port on which instrument is sited (Optical/IR).
1. Telescope
2. Base Right Ascension or Actual Right Ascension (see 5 - 7 below) (start & end RA for non-sidereal rate object?)
3. Base Declination or Actual Declination (see 5 - 7 below) (start & end Dec for non-sidereal rate object?)
4. Reference Epoch for above numbers
5. RA offset from reference or ‘zero’ position (arcsec on sky)
6. Dec offset from reference or ‘zero’ position (arcsec on sky)
7. (Note: most telescopes already provide the above information, but not always in the same way; for example during jitter maps the file may record the actual telescope position and the offset from the centre of the jitter pattern or the jitter pattern centre itself and the current position as an offset. This document assumes the Base RA,Dec and offsets therefrom will be recorded. Units should be compatible with WCS if these are standardised.)
8. Altitude (for start, middle and/or end of observation ?? Assume start and end.)
9. Azimuth (for start, middle and/or end of observation ?? Assume start and end.)
10. Air mass at start of observation
11. Air mass at end of observation.
12. Guide Star Identification
13. Guide star nominal position.
14. Guide star magnitude
15. Guide Star colour (nominally V-R ?)
16. Nasmyth Derotator angle at start of observation
17. Nasmyth Derotator angle at end of observation
18. Nominal field angle on instrument, relative to N up = 0, angles through E positive.
19. Telescope focus (i.e. secondary mirror focus position).
20. Air temperature
21. Dome temperature
22. Other telescope temperature(s): truss, top-end,… as available
23. Humidity
24. Windspeed (km/h or m/sec)
25. Wind direction (azimuth, degrees)
26. Comments
1. DM type (ELECTRA or Xinetics)
2. AO Instrument Setup (ELECTRA or NAOMI)
3. Lenslet order (8x8, 4x4)
4. Lenslet focal length (Long or Short or ID number or Actual Length,mm)
5. WFS filter + ND combination.
6. WFS on-chip integration time.
7. WFS binning mode (needs options for the known modes and an indicator if the mode was changed during the integration because an optimisation algorithm was in use).
8. WFS gain (obtained from RTCS as this is a software parameter within the feedback loop).
9. WFS Offset vector.
10. WFS-DM Loop status (Open, Closed).
11. FSM Offset Null Method (None, To Pick-off, To TCS). Normally To TCS.
12. Focus Offload WFS-TCS status (On, Off).
13. Optimisation algorithm (Options: Off or one of list of Types) (probably only one type initially).
14. Reconstruction Algorithm ( None / Zonal /Modal). For Zonal include gain. For Modal include gains vector and order.
15. 1-CCD or 2-CCD mode.
16. Carriage stage positions (?)
17. Pick-off x position
18. Pick-off y position
19. Flag as to how the position was set (options: pick-off used to define offset from guide star; centre science object on detector for 0 FSM mean offset; blind pointing on given science co-ordinate then pick up a guide star; self-reference science object).
20. DM x position.
21. DM y position.
22. DM temperature.
23. Other relevant AO component temperature.
24. Mean FSM offset ? (should be 0 unless off-load is set to ‘None’)
25. Science-exposure-averaged WFS residual data for duration of integration, for each of up to 64 sub-apertures.
26. RTCS WFS Processing option settings (not defined at present, but could include for example Fast (or un-commented), Slow (commented); Centroid algorithm used.
27. NCU Light Power Settings (Off, On)
28. NCU Attenuator Setting
29. NCU Mask Position (In, Out)
30. NCU Tip-tilt Mirror Power (Off, On)
31. NCU Tip-tilt mirror position (Stationary at Reference, Stationary at Offset position, Moving).
32. Comments
33. Possibly required for later upgrades: Conjugation Lens Status and ID.
34. Identity of any associated GP (diagnostic) or Python configuration files associated with the observation. These would be uniquely tagged, dated filenames.
35. Laser Guide Star system information (for future reference). This could include many parameters, but most important would be On/Off, Offset from Science Object. Probably too early to worry about this at present.
1. File type (FITS, NDF…)
2. Information on FITS extensions
3. Comments
1. Which error messages, if any, (e.g. WFS-DM loop opened at time hhmmss.s) should be written automatically into file headers.
2. Should all changes introduced by on-the-fly optimisation be logged into file headers?