SITCOMTN-029

LATISS Filter Change Procedure#

Abstract

This document explains the required procedures when replacing or adding a new, previously uninstalled, filter or grating to LATISS. These steps are required before any data is taken, in order to guarantee the data is correctly handled by the acquisition and ingestion system.

Introduction#

Replacing a filter or disperser in LATISS requires a few steps to ensure that the instrument is properly configured and that data ingestion is working correctly. When adding a new, previously uninstalled filter or disperser, there are a few additional steps that span both DM and T&S subsystems. Some of these steps may take some time to be ready to be rolled out to the summit and should be done well in advance to prevent delaying operations

Important

When adding a new, previously uninstalled filter, the most time critical step is updating the filters definition file (see below) and having it be built in a regular weekly that is accessible from the summit environment. The DM weeklies are built on Wednesday nights and are generally available Thursday morning, the T&S container then builds on top of that, adding several hours. Performing last-minute filter additions is high risk and puts strain on personnel. Therefore, any new filter or grating names should be added as early as possible, preferably weeks in advance.

Procedure#

  1. Make a ticket on the SUMMIT project that dictates which filter should be removed and which should be added. Use a previous ticket as a reference. Roberto Tighe and Mario Rivera are trained in performing the physical filter change.

  2. Create a DM ticket (Team = Telescope and Site) to update the config file in the ts_config_latiss repository. Use the previous configs as the reference for the correct values of filter names and focus offsets. Follow the OSW development process to tag and release a new version of the ts_config_latiss package once the changes are merged.

  3. If you are installing a new, previously unused filter, you will also need to open a PR to update the the filters definition file. Follow the DM development process of making a ticket, making the change, running the CI tests, and getting it reviewed and merged. The changes will be available in the next DM weekly. If you are installing a known filter, you can skip directly to step 10.

  4. Using the new DM weekly with the changes to the filters definition file, register the new filter definitions in all of the different standard butler repositories using the command below. Note that $OODS_REPO_PATH needs to be replaced with the appropriate path depending on where you are running the command.

    butler register-instrument $OODS_REPO_PATH lsst.obs.lsst.Latiss

    Currently, the repo paths are:

    • At USDF: /repo/embargo and /repo/main

    • At Summit: /repo/LATISS

    • At BTS: /repo/LATISS

    • At TTS: /repo/LATISS

  5. Rebuild the following OSW containers using the current cycle build on jenkins

    • deploy_lsstsqre

    • build_scriptqueue

    • build-sciplat

    • build-sciplat-recommended

    • build-oods

#. The rapid analysis pods and rubinTV services will also need to updated to use the new weekly. A request for this update can be submitted on the #rapid-analysis slack channel.

#. Once the container builds are complete, they are ready to deploy and test on the BTS. At a minimum, you should test that images can be acquired in all of the newly deployed filters, that the images are ingested in the Butler repo at BTS, and that the images and their metadata are properly displayed on RubinTV. Once these tests are complete, you are ready to request deployment authorization at the Summit.

  1. Once the deployment at the summit is authorized, redeploy the ATOODS container and ATQueue pods.

  2. The USDF embargo Butler auto ingestion service must also be restarted with the appropriate weekly, after registering the instrument in the embargo Butler repo (and also the main Butler repo). This can be requested on the #usdf-data-curation channel on Slack.

  3. After the filter is physically installed, and before taking any images, update the ATSpectrograph CSC to use the tag (or branch) containing the new config. This needs to be done either inside the container (temporary) or by updating the cycle.env file, then rebuilding and redeploying the ATSpectrograph CSC (which is the proper way).

  4. Once the new version of the ATSpectrograph CSC is deployed you are ready to enable the spectrograph and take a few test images with the new configuration.

  5. During the filter change process, it is possible the grating stage itself was moved out of its nominal position, so be sure to start by running the latiss checkout procedure to check the position of this stage.

  6. Check that the images are properly ingested in RubinTV by looking for the filter and grating and ensure that the values are correct. If the values for filter and grating are correct, you are finished.