Docstoc

Keck Adaptive Optics Notes 257 Requirements and Guidelines for

Document Sample
Keck Adaptive Optics Notes 257 Requirements and Guidelines for Powered By Docstoc
					      W. M. KECK OBSERVATORY
CALIFORNIA ASSOCIATION FOR RESEARCH IN ASTRONOMY




   Keck Adaptive Optics Notes 257:
    Requirements and Guidelines
       for the AO Handover



 D. Le Mignant, A. Bouchez, R. Campbell, E. Chock, R. Goodrich.




                    Last updated: April 12, 2004




                      1
Requirements and Guidelines for the AO Handover


Table of Contents
1. Purpose of the Document ............................................................................................................................ 3
2. Timeline ....................................................................................................................................................... 4
3. Evaluation Process ...................................................................................................................................... 4
4. Top-level Requirements for the AOH ........................................................................................................ 5
5. AO uptime 95%........................................................................................................................................... 5
    5.1.    Operations............................................................................................................................................ 6
    5.2.    Reliability ............................................................................................................................................ 7
    5.3.    Training and Expertise (see Appendix I) .......................................................................................... 8
6. AO Performance:......................................................................................................................................... 9
    6.1.    AO correction performance ................................................................................................................ 9
    6.2.    Optics................................................................................................................................................... 9
    6.3.    Operational and observing efficiency............................................................................................... 10
7. Operational context : ................................................................................................................................. 11
    7.1.    User-friendly operations: .................................................................................................................. 11
    7.2.    Configuration Control ....................................................................................................................... 12
8. Main Tasks pertaining to the AO handover effort: .................................................................................. 13
    8.1.    Performance Documentation ............................................................................................................ 13
    8.2.    Faint star performance ...................................................................................................................... 13
    8.3.    Configuration Control Document..................................................................................................... 13
    8.4.    AO maintenance plan........................................................................................................................ 13
    8.5.    Rot slew automation.......................................................................................................................... 13
    8.6.    FSM/TSS non-faulty move............................................................................................................... 14
    8.7.    Improve operation software .............................................................................................................. 14
    8.8.    FSM positioning accuracy ................................................................................................................ 14
    8.9.    Operation Support Training .............................................................................................................. 14
    8.10.     System Checkup and Maintenance Training ............................................................................... 14
I      Classes of expertise: .................................................................................................................................. 16
II General Roles: ........................................................................................................................................... 16
III       Operational Expertise............................................................................................................................ 17
    III.1     OA (Observing Assistants) ........................................................................................................... 17
    III.2     (Support Astronomers) ................................................................................................................. 17
    III.3     Operation Support Group (ECC!) ................................................................................................ 18
    III.4     Summit instrument crew............................................................................................................... 18




                                                                            2
                                                              Requirements and Guidelines for the AO Handover



1. Purpose of the Document
This document introduces the effort to hand over Adaptive Optics Natural Guide Star science operations
from the Keck AO team to the operations group. This includes AO NGS science observing with NIRC2,
NIRSPEC and OSIRIS.
Note that the question of whether we should include IF operations (Keck I and II) remains open as of
April 2004.

1.1 Why an AO handover?
The Keck II AO systems have been used for science since Jan. 2000. Since 2001, the OAs operate the
system at night. Some of the SAs (RC, RG, PA and GH) have been trained to calibrate the system and
support AO nights. The AO team, particularly the AO instrument scientist, still provides a strong level of
support before and during AO science operations.
The AO team is aiming at other priorities (LGSAO development and integration, new generation WFC,
Keck Precision AO, etc). The team will be less and less available for support and improvement of NGS
science operation. The AO team plans include LGSAO science operations for FY05 as well as LGS AO
science handover in FY06. On the other hand, they are still a number of known problems that arise during
NGS AO operation. It would be a very beneficial process for the observatory to fix those and go through a
full NGS AO handover process before the LGS AO operations start.
Hence, we recommend in the present document a review process for the NGS AO science operations, as
of April 2004; providing new sets of requirements, allocating resource to work on improving the system
and meeting these requirements for operations, and training the Observatory staff to maintain the high
level of operations in the future.

1.2 Background
The first document that provided a set of requirements for AO operations was the KOR 208 "Adaptive
Optics for Keck Observatory – Chapter 5". The document lists a set of science requirements and goals:
          1. Broadcast to the instruments information that characterizes the achieved PSF versus time.
          2. Operate in the wavelength range of 0.8 to 5 microns
          3. Optimize for wavelength < 2.3 microns
          4. Provide the capability to optimize the control loop for either
                   a. The minimum rms wavefront error, or
                   b. The minimum 80% enclosed energy diameter.
Section 5.3 of the document includes a set of very General Goals and Requirements for the AO science
facility:
          5. Provide a safe environment for personnel and equipment
          6. Maximize the observing and observatory efficiency
 Section 5.3.2 “Observing and Observatory Efficiency” is particularly relevant to this document as it
details the requirements for the design of the facility; the design shall
     • Minimize lost observing time
     • Strive to minimize the time and personnel required for Preparation for an observing run, Start-up,
          Operations and Alignment and Calibrations.
     • Then follows a list of aspects of AO observing preparation, Calibrations and Operations. It is
          beyond the scope of this AOH document to discuss each of these aspects. Some of them apply
          very well to our present system, while other have not been included in the design at all. Yet, we
          have tried to include all relevant requirements from KOR 208 to the present AO handover
          document.

Later in September 1999, there has been an Acceptance Review Committee (see KAON 188). The
conclusion of this committee was that the Keck AO system was not ready for science operations. Yet they



                                                 3
Requirements and Guidelines for the AO Handover


recommended offering the system for science, as it would be capable of producing useful science. At that
time, they were many concerns concerning performance, operations, efficiency, etc. Some of these issues
have been addressed since 1999 and others remain open and are included in the present review.

1.3 Our goal:
The present action plan for the AOH does not mean handing over the AO systems as they are today to
operation groups.
The Keck AO systems were not designed and integrated like black-box systems. They have been ported
very early on the sky and produced very good science results. Year after year, modifications have been
implemented to the Keck AO systems to increase performance (EPICS-based WFC, observing tools, new
NIR science instruments, new calibrations tools, new reconstructor, automations, etc).
Particularly, some level of effort has been invested in the last few years to make the systems very
effective, operational and reliable. Even though the Keck AO systems are not and will not be push-button,
we have demonstrated very good on-sky efficiency (>45% of science time in some instances).
Yet, we plan to operate these systems in a highly effective, well controlled and user-friendly mode for a
few more years, and there still is a step ahead of us to complete our work.

In this document, we propose to increase AO performance, reliability and operation up to a level pre-
handover where we will operate the instruments for the next few years post-handover. We will not reach
these goals for NGS AO science operations unless the Observatory commits to this process.

We present the top-level requirements for the AO NGS handover (AOH) as well as the flow down of
tasks. The AOH effort includes various groups: optics, software, observing support, electronics and
mechanics. In Appendix I of this document, we present a draft of what should be the Operational Roles
and Expertise for the AO Handover.

2. Timeline
We hope to have all parties involved in this AOH agree on the content of this document by April
2004. The AOH could be complete by the end of the fiscal year 2004 (Oct. ‘04).

Adaptive Optics systems are complex instruments that require a lot of training and a lot of
experience with the instrument. Within Keck, more and more staff members are being exposed to
AO. We see the AOH effort as being a synergic effort between various groups. We define
together the requirements and we all work together toward achieving the goals. This is a
dynamic process that started at the beginning of the fiscal year 2004.

In Appendix I, we have drafted a set of Roles and Responsibilities for the technicians, engineers
and support astronomers involved in the AO handover. This document will likely evolve, as the
staff better understands AO and refine their role/tasks and responsibilities.

3. Evaluation Process
We plan to hold an AOH review by the end of September 2004. To be successful, we need to
meet the top-level requirements and achieve the goals defined for each of flow-down tasks. We
have not yet worked out the details for the evaluation process.




                                                  4
                                                              Requirements and Guidelines for the AO Handover


4. Top-level Requirements for the AOH
The items below represent the most important top-level requirements for AO operations. Again, the
goal is to achieve these goals before the AO handover and maintain them in the future.

    1. Provide at least 95% of uptime for the AO systems during nighttime operations.
    2. Provide a routine AO performance level that is at the level reviewed in Marcos et al. 2004, that is:
           a. Strehl ratio > 0.5 in K band for bright star (Rmag. < 9.5)
           b. Strehl ratio > 0.2 in K band for faint star (Rmag. < 13.5)
       These two requirements have to met under good seeing conditions: r0 ~ 20 cm
    3. AO throughput and emission values at least maintained at the level after K rotator re-coating
           a. We will collect NIRC2 Z0 values during the 31 March 2004 and they will be used for our
               baseline.
           b. We should measure K, Lp and Ms emissivity on NIRC2
    4. Optimize the science observing efficiency by reducing AO overheads for most observing modes
       by
           a. Optimizing the present acquisition scheme as to spend 60 sec or less for any AO
               acquisition
           b. Implementing new DCS/AO automation scripts (rotator slew, no-faulty-FSM/TSS-slew)
    5. Provide a reliable scheme for AO operations including
           a. Excellent level of configuration management (NGS vs. LGS, K1 vs. K2, etc.)
           b. Mechanisms for sensing and correcting problems and faults
           c. User friendly software (GUIs, Java tools, IDL)
           d. Adequate documentation (AO performance, software architecture, operation and
               troubleshooting docs)
           e. Training for AO operation, calibration, maintenance and troubleshooting

In the following sections, we detail the flow-down of requirements and the main areas of work. Different
people may have different opinions about under which category to classify the various flow-down items.
Please remind them that it is important that all items get covered, not where.

5. AO uptime 95%
This is a very strong requirement for AO activities and this number is higher that the one included in
KOR 208 – Section 5.3.5: “No more than 15% of the available observing time should be lost to AO
facility failures”.

The COPS team studied statistics on AO time losses between September 2003 and May 2004, as reported
by the nightlog tickets during NIRC2, NIRSPAO and IF nights. The total time was 7 hours, of which 30%
was due to WFC crashes (and improper training to recover), 23 % was due a problem with KAT, 10% to
FSMs faults and the remaining to communication problems, rotator faults, etc (see referenced document
http://www2.keck.hawaii.edu/optics/aohandover/ to access the exhaustive list of problem).

We want to provide at least 95% of uptime for the AO systems during nighttime operations. This
translates into less than half hour lost during a 10-hour night for technical reasons. A proper management
of the AO operations requires a highly reliable system. Thus, the prime area affected by this requirement
is Reliability. All AO sub-systems must be able to work without failure. We need to carefully control the
instrument version. Any change that could potentially impact NGSAO should go through an ECR
process. A second area of concern is Training and expertise: the Observatory staff should be trained to
check the instrument during the pre-observing period and anticipate problems before they happen. The
documentation for these actions should be adequate.



                                                  5
Requirements and Guidelines for the AO Handover




The Operation software needs to take this requirement into account: If a problem occurs at night, we need
to have scripts that immediately detect the problem and, whenever possible, auto-recover with minimum
intervention from the operator. We need to have the AO operators and SAs trained for troubleshooting.
Note that all these points were clearly mentioned in KOR 208.

Below we list the main flow-down items to achieve the goal of 95% uptime:

    5.1. Operations

    •    System startup
        The amount of time to turn on the system electronics, boot-up the computers and perform a self-
        check to determine proper functionality should be minimized. The KOR 208 gave a maximum
        time of 10min for these operations. This is not realistic with the current design of the AO system.
        During daytime, we propose to fix a goal of 1hour, including system check-up.
        Our present operation scheme includes enough daytime testing and stable power source, so we
        can avoid the restart of the system at night.

    •   System administration
        Nightly disk space, backup
        Network and system maintenance (control traffic and reboot)

    •   Implement an efficient mode for the AO alarm handler

    •   There is an AO alarm handler, but using it would add another screen to the multiple screens used
        for AO operations. Instead, we propose the following:
        Use of DCS channels
             We can use the DCS channels to pass AO errors to the DCS alarm handler.
        Implementation of audio alarm from the IDL tools
             We are in the process of implementing audio alarms for the IDL operations tools. These
             alarms are being defined and tested together with the OAs.

    •   Documentation
           Documentation includes here system startup, troubleshooting documentation, calibration
           documentation and operation documentation.

        System startup
                 The documentation to bring down and startup the system should be available to the
                 operation team. Particular attention should be paid to any difference between K1 and K2
                 and there should be two explicit documents: 1) to bring the system down and 2) to bring
                 the system up. The night operation team should be familiar with these documents as well.
        Valid troubleshooting documentation
                 The documentation for troubleshooting should include all AO problems listed in the 6-
                 month statistics on AO problems gathered by the COPS team. Troubleshooting
                 documentation should be written and reviewed by AOs and SAs.
        Calibration documentation
                 The AO team should provide the adequate documentation for calibrations. The SAs
                 should review the calibrations task s they will in charge of and review the corresponding
                 documentation.




                                                  6
                                                         Requirements and Guidelines for the AO Handover


    Regular updated (part of ECR)
            The AO ECRs should include a specific Documentation item: does the change require
            modification of the existing documentation? Who is responsible for modifications.

•   Implementation of Engineering Change Request
    Although only applied to NGS AO, ECR would affect LGSAO/IF-AO development. We would
           need to define roles and responsibilities for the AO ECRs.
    It is important to be flexible thru the ECR process, but it is as much important to communicate
           and check the changes planned for the system.

•   Software Control Management
    Define responsibilities and roles
            The AO team should define with the other groups the roles and responsibilities for AO
            operations. We present in Appendix I a draft for these definitions.

•   AO shutter under control of AO software
    The control of the AO shutter has been integrated by the IF software team. The channels are
         connected to IF channels. This is risky for science operations with future instruments (it
         also already happened that we could not open the shutter till we had the IF crates up and
         running). We should study this potential risk. An obvious possibility is to have the shutter
         software be included into the AO software.

•   Preventive Maintenance plan
    AO bench stages
        The AO team is responsible for putting together with the other group a plan for preventive
        maintenance on the AO bench. Scott Hartman could coordinate these tasks.
    Electronics
        The EE group should present a maintenance plan that includes checking spares, etc. need to
        talk to EE..

    AO checkup and servicing mission
       The AO team has the expertise to perform a complete system health checkup. We would
       recommend performing this task on a two-month basis.
       We propose that the AO Instrument Scientist coordinate with the SAs the system check-up
       before an NGSAO run starts. It has been found to be the best way to detect any problem prior
       to going to the sky and become confident with AO operations and troubleshooting.

        We also propose that the AO team be responsible for an AO servicing mission every year.
        The servicing mission could include checking optics alignment and coating, OBS devices,
        ACAM shutter replacement, etc.

5.2. Reliability
In this section, we cover the most common AO problems. These problems have existed for the
longest time, so we propose that the AO team spend some time to further troubleshoot these problems
and mitigate the impact by implementing a high-level auto-recovery script.




                                             7
Requirements and Guidelines for the AO Handover


    •   Mitigate impact from Rot fault
        Troubleshoot problem
        Implement fast auto-recovery script

    •   Mitigate impact from WFC crashes
        Troubleshoot problem
        Implement auto-reboot-re-init script

    •   Implement non-faulty FSMs and TSS moves
        This needs to be investigated, but a possible approach would be the following: FSMs/TSS moves
              are checked before the telescope moves; The FSM move is being simulated but not
              triggered. If the move goes beyond the FSM/TSS observing range, the telescope move is
              aborted, the loops remain closed, an error string is being returned.

    5.3. Training and Expertise (see Appendix I)

    •   Summit E-tech/swing tech AO-related tasks
        AO startup and power-down
                   Need to review the present documentation for powering up and down AO. Need to
                   train summit staff to perform this operation with hq help.
        Adjust Wyko fringes
                   The swing tech and e-techn should be trained to adjust the fringes on the Wyko
                   inteferometer.
        OBS stages troubleshooting
                   Summit staff should become familiar with AO bench devices and trained for the most
                   common problem arising on the AO bench (e.g. problem with an F850 actuator)

    •   Support Astronomers
        SAs work with the AOIS to check the system prior to a run.
        SAs are responsible for AO calibrations
        SAs are responsible for AO troubleshooting; this requires understanding well how OAs operate
             the AO system from the summit.
        SAs should work with the AOIS to follow up on AO problems and ensure that the
             troubleshooting section keep being updated.

    •   OAs (see Appendix I)
                   The OAs are responsible for AO operations and should be confident in addressing
                   most common AO problems during the night.
        Operate and understand operation schemes
        Practice AO troubleshooting

    •   Ops Software (see Appendix I)
                  The Ops Software work with the AOIS and SAs to check the AO system prior to a
                  run. The Ops Software and particularly the software on-call person should understand
                  AO operations and be able to address most common AO problems at night.




                                                  8
                                                             Requirements and Guidelines for the AO Handover


        Pre-run checkup list
        Training for AO software troubleshooting

6. AO Performance:

The term “AO performance ”could be too wisely interpreted, we will limit it here to AO correction
performance, optical performance and instrument efficiency.

    6.1. AO correction performance
          M. van Dam and D. Le Mignant, together with the Keck AO team, have been involved in a 2-
          year project to characterize and optimize the Keck AO systems. We have investigated into the
          AO error budget, implemented many changes to the systems, tested them and documented them
          (see AO characterization web page). We have submitted a paper to Applied Optics that
          summarizes the Keck AO performance. We have also presented our results to a review
          committee including the AO working group members, whose conclusions has been to
            • The AO error budget is now well-understood
            • Bright star performance has been optimized
            • Faint star performance could be increase by implementing the 1.0 arcsec plate scale
            • Further investigation effort into the AO error budget should focus onto understanding
                telescope and NIRC2 error budget.

          For the future, we want to maintain the performance level we have demonstrated and started to
          document for bright stars during the AO characterization effort. We would need to complete
          our work by addressing the following:

    •   Collect more data for documenting AO performance on bright/faint star

    •   Implement/characterize 1 arcsec plate scale for routine operations

    •   Implement auto-scaling of centroid origins

    •   Implement frame-rate optimizer

    •   AO performance documentation
        Strehl vs magnitude
        Strehl versus seeing (desirable)
        Strehl versus NGS separation

    •   Monitor AO performance
        Monitor image quality after image sharpening on the white light source.
        Monitor image quality from sky data.

    6.2. Optics

    •   Pupil alignment on NIRC2
              A set of requirement for the pupil alignment for NIRC2 has been proposed in KOAN 253.
              The peak-to-valley value for the pupil nutation should optimally be less than 10cm on the
              telescope primary.
              As of April 2004, this AO rotator has been re-aligned and meets these requirements (see
              KAON 254 & KAON 255).


                                                 9
Requirements and Guidelines for the AO Handover


    •   Image centering on NIRC2
             The location of the optical axis of the AO system on NIRC2 has been drifting over the 2
             years of operations by more than 8 arcsec. The origin for this drift is not yet well
             understood. We believe this could come either from a drift of the rotator mount, the TT
             mount or a drift between the AO bench and the NIRC2 instrument. The drift is mostly in the
             horizontal direction. We would need to mitigate this effect.
             As of April 2004, the AO rotator has been re-aligned. The AO bench optical-axis is now
             located 2arcsec from the center of NIRC2 field of view.
             Maintaining the optical-axis within 2 arcsec from the center of NIRC2 field-of-view
             contributes to easier AO acquisition.

    •   FSM field of view
        Reduce vignetting by the sodium dichroic.
        Although we know that the dichroic is partially obstructing the light beam for off-axis operations
              in the –Y direction, we need to check whether we could mitigate this vignetting and
              increase the available field-of-view for the FSMs.
        Investigate FSM limit range.
                 Check software limit versus available range and optimize the available field-of-view.
                 This operation should be documented and included in system health checkup.

    •   Throughput and AO bench emission
           The AO rotator K mirrors have been re-coated in March 2004. The photometric numbers as
           well as sky brightness for NIRC2 between 1 to 5 microns have been posted in KAON 256.

            After visual inspection, Tim S. reported that it would be necessary to perform a new coating
            for the deformable mirror. This action would have to be properly scheduled, and maybe
            difficult to handle by the end of September 2004.

    •   Documentation of optical performance.
            Documenting the performance is the best method to troubleshoot a problem such as pupil or
            image drift, throughput anomalies, etc.
            We propose that the NIRC2 instrument scientist checks for any drift of the pupil image on
            NIRC2 as well as for the image location of the AO optical-axis.


    6.3. Operational and observing efficiency
          The operational efficiency is another key aspect of Keck AO performance. The astronomer
          needs high Strehl ratio data but also needs an instrument efficient in collecting the data. The
          AO system, like any complex instrument needs to be adjusted depending on the observing
          parameters. These adjustments have to be highly accurate and fast. Some of them contribute to
          a fair amount of the observing overheads. We have included below more details for each of the
          items.
          Two other main contributors to AONGS observing overheads are the acquisition process
          (telescope pointing and guider) and NIRC2. It should be considered to optimize those as well.

    •   AO acquisition in less than 60 seconds.
            The AO acquisition takes actually 60 to 90 seconds. Recording a WFS background takes
            more than 20seconds (move telescope, record background, move telescope). Our goal is to
            do it faster than 60 seconds in photometric conditions.



                                                  10
                                                              Requirements and Guidelines for the AO Handover


    •   Field Steering Mirrors
        Slew time
                The mean slew time for the FSMs is 4 seconds for a move of 2mm with a peak time of 8
                seconds (200 data samples). If the FSMs move takes longer than 10seconds, it produces a
                time-out in the DCS-AO handshake during dither/nod. It is important to monitor
                regularly this performance.
        Positioning accuracy
                We need to position the FSMs with an accuracy of 10mas (not taking DAR into account).
                We have to check whether we reach this level of performance.

    •   FCS slew time
               The focus stage of the camera needs to be adjusted for each FSM move. This adjustment
               is required to account for the curvature of the focal plane. The tolerance on the
               positioning is of 0.01mm, which is accurate enough.
               On the other hand, it takes sometime more than 10 seconds for the device to move by
               0.02mm.
                    • We should implement a method where the FCS is not moved if the adjustment to
                        be made is less than 0.01mm.
                    • We should adjust the tuning so that it moves by 0.02mm in less than 3seconds.

    •   DCS/SC handshake during Rotator slew
              There exists a script within the DCS that checks for AO during rotator slew. Yet his
              script fails and has never been fixed. Any rotation has to be performed on-axis as of
              today, which is real loss of efficiency for most off-axis observations where the rotator
              angle needs to be adjusted. The implementation of automated DCS/SC handshake during
              rotator slews is required for efficient off-axis operations and will certainly be highly
              desirable for any LGSAO operations, as most of them will be performed off-axis.

7. Operational context :
Last, the operational context for the AO handover is an area with many details that would make AO
operations user-friendly and contributes to a better efficiency/reliability. Some of the items below are
very specific to Configuration Management Control which hardware, software and documentation and
should be addressed in a separate document.

Under operational context we list the following:

    7.1. User-friendly operations:
          The AOIS, Liz Chock and OAs have been working together on defining a set of requirements
          for the AO operations. We have proposed changes to the existing tools and are implementing
          those. These include:

    •   Startup of AO tools

    The process of starting AO tools should be made easier and there should be a better management of
    xterm and IDL windows (color, geometry, automatically iconified)




                                                   11
Requirements and Guidelines for the AO Handover


    •   AO audio alarms should be implemented

    •   The Wyko display should be available from the Polycom TV.

    •   A solution to merge IDL and Java launcher should be investigated and proposed in order to
        reduce the number of AO screens.

    •   All operation tools (IDL and Java) should be overhauled.

    •   OAs responsible for checking the documentation

    The OAs should check the operation and troubleshooting sections of the AO documentation and
       request changes if the documentation is not adequate.

    7.2. Configuration Control

    •   Modifications to existing operation tools for NGSAO (IDL, JAVA)
        The operation group should work with the AOIS to produce an ECR for the changes. Any
             modification should be thoroughly tested before sky-release. It is important to keep the
             AOIS in the loop for this process in order to best evaluate the risk of the change onto
             operations.

    •   Impact of development effort (LGSAO, NGWFC & IF) to NGSAO operations
           Changes required for LGSAO may impact on NGSAO operations. It is obvious that as we
        progress on the LGSAO integration, we will ask to have the new software versions available for
        science. This raises various questions:
           • How do the AO team keep track of changes between various versions? Is the information
               for changes available? How would the operation team know about the
               development/release plan?
           • What is the proper mechanism for releasing a new version? So far, the decision
               mechanism was mostly based upon the experience with the new version and whether the
               AO team, particularly the AOIS, would agree to release it.

                We could propose the following:
           •   There should be a good communication between the AO team and the operation team. We
               would recommend having monthly meeting between one representative of the operation
               team, one from the AO software and the AOIS to keep track of changes and progress made
               to the AO system.
                    o Any changes in the AO hardware to support LGSAO, NGWFC and IF
                       development should be included in an ECR where the impact on NGSAO is taken
                       into account. We have to evaluate whether using daylog entries would be
                       appropriate for this process.
                    o The AO team should communicate with the Operation Group its AO software and
                       hardware development plan. Particularly, the changes should be highlighted to
                       allow a full assessment of risk on NGSAO.
           •   The AOIS coordinates with the AO team and the ops group the AO configuration control,
               making the following information available. The table will contain the number for each
               version and the date at which it is checked or tagged;

                         Subsystem           OBS           SC          WFC           Docs        IDL/Java
                         K2/LGSAO            Dvlpt        Dvlpt        Dvlpt         Dvlpt         Dvlpt


                                                  12
                                                              Requirements and Guidelines for the AO Handover


                        K2/NGSAO           Tagged       Tagged          Tagged      Checked       Tagged
                        K1/NGSAO           Tagged       Tagged          Tagged      Checked       Tagged
           •    The operation group will only take responsibility for nights when the version running has
               been tagged and released for sky operation.

8. Main Tasks pertaining to the AO handover effort:

In this section, we emphasize the important tasks that are high priority on our list and will require some
development. We would need the Observatory (engineering and operation group) to review these tasks
and see whether they can commit on the first step, which is assessing the effort level required to complete
these tasks within the AO handover.

The Group Leaders at WMKO need to work on planning these tasks (team, task plan, level of effort,
timeline). Completing these tasks is seen as the most important step toward AO handover. We need to
find a way to schedule these with the lowest impact on other priorities. We could recommend assigning a
task lead for each task. The lead person would work with a small team on producing a work plan
including the team, task plan, level of effort, timeline [by the end of a time agreed upon].

    8.1. Performance Documentation
         Team                                               MvD, DLM, Randy C. and Antonin B.
         Engineering nighttime                              Yes – at least 1/2 night
         Estimated total effort                             8 weeks
         Output                                             Documentation of AO performance

    8.2. Faint star performance
         Team                                               MvD, DLM, RC and AB?
         Engineering nighttime                              Yes – at least 1/2 night
         Estimated total effort                             3 weeks
         Output                                             Documentation of AO performance
                                                            Implementation of 1arcsec plate scale

    8.3. Configuration Control Document
         Team                                               Liz C., DLM and PS?
         Engineering nighttime                              No
         Estimated total effort                             3 weeks
         Output                                             Guidelines for AO Configuration Control
                                                                  including ECR and dvlpt

    8.4. AO maintenance plan
         Team                                               SH ++??
         Engineering nighttime                              No
         Estimated total effort                             4 weeks
         Output                                             Plan for AO maintenance for K1AO and
                                                            K2AO including optics, electronic hardware


    8.5. Rot slew automation
         Team                                               DS, PS, Al C., RG ??



                                                 13
Requirements and Guidelines for the AO Handover


         Engineering nighttime                         Yes, also daytime
         Estimated total effort                        4 weeks?
         Output                                        Implementation of rotator slew including
                                                       pausing AO loops and repositioning FSM/TSS
                                                       at the correct location.

    8.6. FSM/TSS non-faulty move
         Team                                          DS, PS, Al C., RG??
         Engineering nighttime                         Yes, also daytime
         Estimated total effort                        6 weeks
         Output                                        Implementation of a scheme to not-move FSMs
                                                       and TSS if a fault is foreseen. Make sure the
                                                       impact on observing is minor.

    8.7. Improve operation software
         Team                                          DLM, LC
         Engineering nighttime                         No
         Estimated total effort                        2 weeks
         Output                                        Following discussion with OAs, the operation
                                                       software has been improved to increase
                                                       reliability, performance and user-friendly
                                                       aspects.

    8.8. FSM positioning accuracy
         Team                                          RC, AB, RG, PS, DLM
         Engineering nighttime                         Yes
         Estimated total effort                        3 weeks
         Output                                        Document actual level of performance
                                                       (internal, on-sky), with and without DAR

    8.9. Operation Support Training

         Team                                          RG + DLM
         Engineering nighttime                         No
         Estimated total effort                        X weeks
         Output                                        The operation group has been trained to
                                                       perform AO operations and system
                                                       troubleshooting.

    8.10.       System Checkup and Maintenance Training

         Team                                          JC + Rich M. + Electronic Group
         Engineering nighttime                         No
         Estimated total effort                        X weeks
         Output                                        The operation group has been trained to
                                                       perform AO checkup, maintain the system for
                                                       operations and perform troubleshooting.




                                                  14
                                                         Requirements and Guidelines for the AO Handover


9. References:

   •   KAON 188, Acceptance Review Committee Report : Keck II NGS AO facility, Sept. 1999.
   •   KOR 208, Adaptive Optics at Keck Observatory, Sept. 1994.
   •   M. van Dam et al. 2004, Performance of the Keck Observatory AO systems, submitted to Applied
       Optics
   •   KAON 253, “Requirement for the pupil alignment on NIRC2”, April 2004
   •   KAON 254, “Image rotator and NIRC2 alignment”, April 2004




                                             15
Requirements and Guidelines for the AO Handover



                     Appendix I:
  Operational Roles and Expertise for AO Handover
    I    Classes of expertise:

         •    Observing Support Group:
                 o Observing Assistant (OA)
                 o Support Astronomer (SA)
         •    Operation Group from software, electronic and mechanics group (OPSG)
         •    Summit instrument crew
         •    AO team


    II    General Roles:

         The AO team (particularly the AO instrument scientist), the Observing Support group and the
         Operation group (OPSG) are responsible for
         a. Making sure the system is running its science version prior to any science run.
         b. Making sure any change on the AO system applicable to NGS or IF modes goes through
            an ECR process and is reviewed by both AO team plus observing support team (ECC/RC).
         c. Making sure any change on the AO bench applicable to LGS mode is submitted to and
            reviewed by the AO instrument scientist (and observing support group?) to assess the
            possible impact/risk on AO operations.
         d. Checking the AO system functionalities at a start of an AO run. This is likely to include some
            nighttime support.
         e. Starting/checking the system after a power-down.
         f. Keeping K1 & K2 AO as similar as possible and identical from the operator point-of-view.

         How do we deal with IF (Keck I and IF specific requirements)??

         The AO operators and support persons (OA, SA, AO team) should be expected to understand
         (Keck) AO concepts
            • Why use AO on large telescope?
            • Basic knowledge about atmospheric physics.
            • How it works – NGS / LGS ?
            • What are the main limitations for AO?
            • The general layout of AO (feeding the instrument)
            • The various sub-system (OBS/WFC/SC and UIs)
            • Items that are specific to AO instruments (rotator, FSM, guiding, focusing)
            • Where to find the documentation about AO
            • Keck AO knowledge/expertise tree

         The OA, SA and part of the AO team should be familiar with the nighttime AO operations (roles
         of players and their level of expertise for the various AO tools), e.g., no one should expect an OA
         to startup and calibrate AO after OBS accidental reboot.




                                                  16
                                                           Requirements and Guidelines for the AO Handover


      The AOIS will work with all parties involved in AO operations and development on keeping a
      very high level for system efficiency and for ease of use. The OA, SA, and operation group
      should be active players for suggesting improvements to the AO operations (this is even after the
      AO handover period).


III       Operational Expertise

III.1 OA (Observing Assistants)

      The OAs should be expected to:

      1. Be familiar with all AO observing software options under workspace pulldown including:
              a. Starting AO tools in two-clicks (including reconstructor and acquisition widget)
              b. Stopping AO tools in two-clicks
              c. Restarting all and a given sub-component of the AO observing tools during an
                  science integration, without interfering with the loop states.
      2. Point to new targets and center in ACAM.
      3. Run automatic AO tool (aka “AO auto setting tool”).
      4. Initiate AO lock on target using various FSM pointing origins.
      5. Be able to adjust frame rate and setup AO manually to lock on a star (e.g. PSF star or any star
         for which the observer would like to a given setup)
      6. Diagnose common problems with AO system or observing parameters. These include:
              a. Target too faint or too bright
              b. Binary target
              c. Target too extended
              d. AO/DCS communication problems
              e. Variable sky background (start of the night, clouds)
              f. Vignetting of pupil (dome vignetting or FSM close to limits)
      7. Be familiar with the AO troubleshooting documentation and perform troubleshooting
         recovery steps that include:
              a. Rebooting AO WFC crate
              b. Re-establishing DCS communications
              c. Recover from FSM “out-of-limit” crashes.
              d. Recover from AO rotator problems.
      8. Provide observers with pointers to significant information sources (AO Web pages, NIRC-2
         and OSIRIS Web pages, etc.)


III.2 (Support Astronomers)

The SAs should be expected to:
   1. Assist OAs to check the system performance at the start of the night.
   2. Assist OAs for operations (case of complex observing, bad seeing recommendations, etc) and
       troubleshooting
   3. Be very familiar with AO observing tools (IDL & java tools) and be able to operate the
       lower-level software tools (AUs, SCGUI)
   4. Start-up the AO system (with AO support)
   5. Perform system check-up and afternoon AO calibrations
           a. Go through the AO sanity check



                                              17
Requirements and Guidelines for the AO Handover


               b. Calibrate the AO system
               c. Diagnose any AO problems.
        6. Aid observers with AO planning, including:
               a. Use of planning tools such as FSMView
               b. Advice on appropriateness of AO lock stars (too faint, too bright, etc.; see OA bullet
                  point 5)
               c. Instrument-specific help


    III.3 Operation Support Group (software)
    The OPSG group should be familiar with the following operations:
    • Check and reverse the default link for all released version for each AO sub-system in the AO
        /kroot/ tree
    • Work with the SA and AOIS to perform minor changes in the observing tools (as part of an ECR
        process)
            o Update of the IDL and java tools as to include new options
            o Release of the new version after adequate check-up
    • Monitor system load and backup AO files on nightly at least every week.

    III.4 Summit instrument crew
    The summit crew should be able to perform the following operations:

        1. Follow appropriate clean-room procedure
        2. Power down and power up the AO bench and check with the AO and Observing Support
           team at hq when doing so.
        3. Perform 4-month routine maintenance tasks (mechanics and electronic tune-up) on
           mechanisms such as SFP, FCS, TSS, FSMs
        4. Change filters on the K2 AO warm filter wheel (KFC)
        5. Clean AO optics (emphasis on the K mirror)
        6. Work with the SAs and the AO team to perform the above tasks and ensure a controlled
           configuration for the AO instrument (tasks properly scheduled, task plan communicated, risk
           on operations clearly assessed and system checked-up performed after every operation)




                                                  18

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:8/28/2011
language:English
pages:18