Lucifer videocon

- Lucifer mentions a requirement by Arcetri some time ago to access Lucifer images during calibration to optimize the PSF.

- Armando resumes the reasons for this access (Psf optimization in different conditions, elevation, field position because of the lucifer windows, etc)

- how is master in transferring these images? AO would be ideal because we are actually moving the DM and we can coordinate

- need to bypass the TCS because there is no API for this

- other use case is the recentering (during observation!) to correct for psf displacement due to AO flexures etc. Goes slow (10 minutes)

Use cases:

- Infrequent calibration: non common path aberrations. Engineering GUI, once or twice per year

- fequent calibration: registering focus: scripted by the Instrument using IIF. Once or several times per night

- continous operations: recentering of the FoV during integration.

AI 1: define a sequence of operations to find out the non-common path aberrations
AI 2: explain the command sequence for focus offset (though the IIF)
AI 3: recentering: need to define a procedure to measure a LUT of the differential flexure (psf movement on lucifer wrt. elevation/rotation). Instrument sends a command every X minutes to offset the pyramid.

offsets: ask Lucifer to quantify the amount and frequency offsets foreseen for typical observations.

ask Dave Thompson which data he wants in the lucifer FITS header about the AO system for data reduction. Arcetri will suggest which parameters are available.

AI:think about a performance estimator

Non-common path aberrations calibrations

Non-common path aberrations may arise from several sources (misalignments, optics, etc). The main contributor is foreseen to be the Lucifer entrance window, that will inject different aberrations depending on the FoV position.

Calibration of these aberrations is assumed to be will be an infrequent operation (one or two times per year?). Calibration can be done in daytime if on-axis, and in nighttime when the AO system is working off-axis.

Use case

Operation will coordinated by the AO system software. The typical use case is foreseen as:

  1. close the AO loop on the calibration source
  2. Take an image using the Lucifer camera
  3. apply an offset to the AO loop using slope offsets
  4. iterate until a good PSF is obtained
or
  1. close the AO loop on the calibration source
  2. apply a series of pre-determined offsets to the AO loop
  3. acquire an image using the Lucifer camera at each step
  4. post-process the images and determine the best PSF
The previous sequences will be repeated for different FoV position of the AO reference star, and possibly for different telescope conditions (elevation, rotation, etc), still TDB.

In any case, the following is required:

  1. a way for the AO system to start the image integration on Lucifer. This must be done outside the TCS scheme. Could be a process starting on the AO workstation that will trigger an integration on the Lucifer workstation? Or the AO system connecting to some server on the Lucifer system and sending a command? This must be defined by the Lucifer team.
  2. a way for the AO system to read the image. If the image is saved as a FITS file on an NFS shared disk, the command in the previous point can just return the filename and the AO software can read from the NFS disk.
Since the minimum exposure time on Lucifer is about 2 seconds, no time-critical processes are required.

AI: Lucifer team will provide an interface to trigger an image acquisition on Lucifer and make the resulting FITS file available on a shared disk.

Focus correction

Focus and possibly other aberrations might be need to be corrected each observing night and possibly several times during the night. This operation must be done by the instrument. The AO system makes available via the AOS the following commands:

Both commands are only available in closed loop.

An example sequence to adjust the focus could be:

  1. Close the loop in the standard way using a bright star (PresetAO, AcquireRefAO, StartAO)
  2. Acquire an image on Lucifer
  3. Change the AO focus with the OffsetZ by a small amount
  4. Repeat steps 2) and 3) exploring a likely range of focus deviation
  5. process the images searching for the one with the highest peak and/or the smallest FWHM
  6. give a final OffsetZ command to bring the system into the best measured position.

FoV recentering

During long exposures, the FoV on the scientific camera will suffer from small offsets due to differential flexures between the AO system and Lucifer. It is not clear whether these flexures will be exactly repeatable. Several ways of detecting these flexures are possible:

  1. if both the AO system and Lucifer have their own flexures lookup tables, each one can apply the correction independently
  2. an overall lookuptable can be built closing the AO loop and measuring the PSF displacement of Lucifer while the telescope is changing elevation and rotation
  3. feedback from Lucifer during acquisition can provide sufficient information to correct the flexures.
The AO system should be stable enough that no corrections will be needed during a single (about 10 minutes) spectroscophic exposure. After that, a correction may be needed.

Use case to measure the overall flexure lookup table

  1. Close the AO loop on a bright star
  2. Wait for the telescope to change elevation and/or rotation by a given amount
  3. Acquire an image on the Lucifer camera
  4. Iterate points 2) and 3) as needed.
  5. Measure PSF displamements on the various images to build the lookup table.

Use case to use the flexure lookup table during observation

  1. Close the AO loop
  2. center star on Luficer slit
  3. start single exposure (10 minutes)
  4. Compute the amount of offset needed using the lookup table (inputs should be: telescope elevation and rotation)
  5. Issue an OffsetXY command to the AO system.
  6. Repeat from point 3) as needed.
In case the lookup table cannot be measured, the following is an alternative use case:

  1. Close the AO loop
  2. center star on Lucifer slit
  3. start single exposure (10 minutes)
  4. Remove grating from the Lucifer camera and take an image
  5. Compute the offset from the measured PSF and send an OffsetXY command to the AO system.
  6. Put back grating
  7. Repeat from point 3) as needed.

Offsets

The AO system allows three different kinds of offsets:

  1. small closed loop offset: if less than 1 arcsec, offsets can be done with an OffsetXY command while in closed loop, without opening the loop. Execution time is one or a few seconds
  2. big closed loop offsets: offsets up to about 2 arcminutes will be processes by the OffsetXY command in steps, keeping the loop closed and waiting for the hexapod offload mechanism to recover the DM tilt. This offset can be very slow (about one seconds for each arcsecond of offset).
  3. open loop offsets: the instrument can coordinate a fast big offset in the following way:
    1. Pause the AO loop
    2. Offset the telescope pointing
    3. Offset the AO system by the same amount
    4. Resume the AO loop

      before resuming, the AO system checks whether the reference star is again in the pyramid FoV and may refuse the command if the incoming light level is too low (in case there was an undetected problem with the previous offsets commands).

The instrument can choose any of the three methods available. If a description of the typical offsets during an observation is available, the AO team can optimize the current offsets procedures.

AI: Lucifer team to provide description of the typical offsets to be employed during observation

AO closed loop data

The AO system makes available on the TCS Data Dictionary several status variables about the closed loop. These values are currently displayed on the AOS GUI and can be read from the Lucifer system is needed. Some of this data may be useful to have in the Lucifer FITS headers.

AI: Arcetri team will provide a description of the AO data currently available on the DD.

AI: Ask Dave Thompson which kind of AO data will be useful to have in the Lucifer FITS headers.

AO closed loop performance estimator

The AO system could estimate the closed loop performance based on internal diagnostic data, and provide this information to the TCS to be displayed and/or saved along the images. Details are still TBD.

-- AlfioPuglisi - 09 Nov 2010
Topic revision: r2 - 09 Nov 2010, AlfioPuglisi
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback