Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Large Binocular Telescope ARGOS Advanced Rayleigh Ground layer adaptive Optics System Software Preliminary Design Doc. No. Issue Date ARGOS PDR 012 1.0 2009/02/01 Prepared W. Gaessler Name 2009/02/01 Date Approved L. Busoni Name 2009/01/03 Date Released S. Rabien Name 2009/01/03 Date © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 2 of 65 TABLE OF CONTENTS Change Record ................................................................................................................................................ 3 1 Scope ...................................................................................................................................................... 4 2 Applicable documents ............................................................................................................................ 4 3 References .............................................................................................................................................. 5 4 Introduction ............................................................................................................................................ 6 5 General Requirements to the Software ................................................................................................... 6 6 ARGOS in a nutshell .............................................................................................................................. 8 7 Use Cases.............................................................................................................................................. 11 7.1 Actors ........................................................................................................................................... 11 7.2 Observation Modes ...................................................................................................................... 12 7.3 Observation procedures ............................................................................................................... 13 7.4 Setup procedures .......................................................................................................................... 28 8 Operating Environment ........................................................................................................................ 32 8.1 Current Hardware layout of FLAO .............................................................................................. 32 8.2 Current SW layout of FLAO........................................................................................................ 32 8.3 Current interface to TCS .............................................................................................................. 33 9 Software Structure and Functional Specifications ................................................................................ 36 9.1 Common Software ....................................................................................................................... 38 9.2 Laser and Launch System Software (LLS) .................................................................................. 42 9.3 LGS Wavefront Sensor System Software (LGSW) ..................................................................... 44 9.4 Wavefront Data Handling System Software (WDHS)................................................................. 46 9.5 Tip Tilt and Truth (T3) Sensor Software ..................................................................................... 48 9.6 DM Diagnostic Software (DMD) ................................................................................................ 48 9.7 Real-time reconstructor software (RTR)...................................................................................... 49 9.8 PSF reconstruction software ........................................................................................................ 51 9.9 Observation Preparation Software ............................................................................................... 55 10 Computer Architecture ......................................................................................................................... 57 11 Network Architecture ........................................................................................................................... 59 APPENDIX (1): ............................................................................................................................................ 63 List of acronyms ............................................................................................................................................ 63 © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 3 of 65 Change Record Issue Date Section/ Paragraph Affected Reasons / Remarks Name 0.1 2008/08/11 All Created gaessler 0.2 2008/11/24 All Moved to new template gaessler 0.3 2008/12/16 All PDR refinement gaessler 1.0 2009/02/01 All PDR for approval gaessler © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 4 of 65 1 Scope This document presents the preliminary design of the software, including definition of computer hardware and network architecture. 2 Applicable documents No. Title AD 1 AD 2 AD 3 AD 4 AD 5 AD 6 AD 7 AD 8 AD 9 AD 10 AD 11 AD 12 AD 13 AD 14 AD 15 AD 16 AD 17 AD 18 AD 19 AD 20 AD 21 AD 22 AD 23 AD 24 AD 25 AD 26 AD 27 AD 28 AD 29 AD 30 AD 31 Number & Issue LBT Laser Phase A study report Executive Summary Science Case Study Management Plan LBT Implementation Plan ICD System Design Laser System Design Launch System Design Wavefront Sensor Design Tip-Tilt Tracker Design Software Design Calibration Unit Design Site Characterization Report Upgrade Path Plan LBT ASM Functional Description FLAO Subsystem Functional Description AOS Functional Description FLAO WFS software ASM Software Components Integration of the AdOpt Software into TCS AOS Functional Description LN Common Software LN Software Overview LBTO-AO Software Architecture ASM Basic Computational Unit Design Report LBT AO Real Time Software LBT Specifications Skycat manual LBT common software description LBT software subsystem descritpion © ARGOS Consortium 1.0 ARGOS-PDR-000 ARGOS-PDR-001 ARGOS-PDR-002 ARGOS-PDR-003 ARGOS-PDR-004 ARGOS-PDR-005 ARGOS-PDR-006 ARGOS-PDR-007 ARGOS-PDR-008 ARGOS-PDR-009 ARGOS-PDR-010 ARGOS-PDR-011 ARGOS-PDR-012 ARGOS-PDR-013 CAN-486f007a LBT-AdOpt.001 CAN-486f006c LBT-SW workshop 2006 LBT-SW workshop 2006 Soft-002, Version 1.2 AdOptSW.005, Version 2.1 LN-MPIA-SWDR-ICS-001, 1.1 LN-MPIA-SWDR-ICS-001, 2.1, LBT-SW workshop 2006 CAN-640a009a LBT AO meeting February 2005 LBT spec 1998 481s501a 1.0 July 13 2006 481s008a 1.0 July 13 2006 Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 5 of 65 3 References No. Author, Year, Journal. Vol., Name RD 1 Wilson 2002, MNRAS, 337, SLODAR: measuring optical turbulence altitude with a Shack -Hartmann wavefront sensor RD 2 Britton 2006, PASP, 118, The Anisoplanatic Point-Spread Function in Adaptive Optics RD 3 Gavel 2004, SPIE, 5490, Tomography for multiconjugate adaptive optics systems using laser guide stars RD 4 Gendron 1994, A&A, 291, Astonomical AO: I. Modal control optimization RD 5 Gendron et al. 2006, A&A, 457, New algorithms for adaptive optics point-spread function reconstruction RD 6 Jolissaint 2006, JOSA, Analytical modeling of AO of the phase spatiial power spectrum approach RD 7 Jolissaint, submited, OPERA , an automaitc PSF reconstruction software for SH AO systems: application to Altair RD 8 Peter 2008, PhD, RD 9 Veran et al. 1997, JOSAA, 14, Estimation of the adaptive optics long exposure pointspread function using control loop data RD 10 Wilson 2002, MNRAS, 337, SLODAR: measuring optical turbulence altitude with a Shack- Hartmannwavefront sensor RD 11 Whiteley 1998, ApOpt, 37, Incorporating Higher-Order Modal Measurements in Tilt Estimation: Natural and Laser Guide Star Applications RD 12 Whiteley et al.1998, JOSAA,15, Temporal properties of the Zernike expansion coefficients of turbulence- induced phase aberrations for aperture and source motion RD 13 Whiteley et al. 1998, JOSAA,15, Optimal modal wave-front compensation for anisoplanatism in adaptiveptics © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 6 of 65 4 Introduction The software design and implementation lives from the requirement gathering. Therefore, we extended the work of the Phase A study with more detailed procedures and functional specifications. After mentioning the basic requirements for the software design in chapter 5 a short overview of the ARGOS system and possible software component structure is given (chapter 6) – ARGOS for dummys, so to say. The real desing starts with discussing the use cases in chapter 7. Here, we want to learn who wants to do what with ARGOS and how this is sequenced in time. In chapter 8 we have a look at the environment and existing software at LBT, which sets certain constraints to us, before we then define the software structure and discuss the functional specification of software packages in detail in chapter 9. Finally we break down the computer architecture and network architecture in chapter 10 and chapter 11, respectively. All the section are constructed that they are selfconsistent. It is not an absolute must to follow the given outline but it is helpful to do so. The idea of the chapter ‘ARGOS in a nutshell’ at the beginning is to give a short summary and a glimps of where all will end already in the beginning. 5 General Requirements to the Software Requirements and general rules are described, which are baseline to the following design description. The code implementation should follow this rules in all software layers. The software is divided into packages that consist of several modules providing certain functionalities. In first order, a package reflects a hardware system, i.e. the wavefront sensor, the deformable mirror or the laser launch system. Some packages are logical systems, unrelated to hardware, which are needed to structure a task, i.e. a wavefront data handling system for extracting information from sensor data and optimizing parameters. Each package should be able to run standalone, in parallel without interaction to other packages or in parallel together interacting with other packages, therefore it has to fullfill following requirements: 1. Independence – each package should be usable also if no other computer or package of ARGOS is available. This capability is needed for testing and maintenance. Exception is the common software that provides a common layer to all sub-system software. Any package should be based on the common software. 2. Standalone - all devices and related SW services of a package should be under control of the package itself. This needs to resolve all the hardware interferences and assign an unique package to it from which it is operated only. The package must be able to start servers, switch states and handle configuration on its own. All services such as configuration, logging, sampling, scanning, storing, etc. have to be handled within this package on one computer or distributed computers. 3. Efficiency – each package should use parallel command processing and device setup as much as possible. It should also be able to execute commands in parallel with other packages without interference. 4. Hierarchical control – The command structure has to be hierarchical. Commands can only go top-down the hierarchy, never up. For each command status replies are sent back. Therefore exception cases have to be defined if a sub-system fails and timeouts have to be handled and defined. The hierarchical control is an exception since it only requests status and thus do not change anything on a sub-system. To fulfill the independence and standalone requirement, a possibility to interact with the sub-systems from engineering GUI or command line has also to be allowed. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 7 of 65 5. Failure tolerant – Each package should be fault-tolerant to failures as much as possible. This involves also recovery strategies and configurations to allow locking of broken hardware, offline or simulation modes and using alarms as notification. So far safety allows, the program should not be stopped. All communication has to be non blocking. 6. Transparency – The status should be available online and update asynchronously. Therefore event channels can be used. Each server has to update its parameters at the latest after execution of a command. Status information has to be provided also in a horizontal way between sub-systems of the same software layer. Error messages have to be in such way that the operator is able to undestand where the error happened and what failed. 7. Command safety – A GUI should provide separate command buttons to the selection of components and values. Changes of parameters have to be activated through a separate button executing the command. This does not allow having an entry widget that automatically starts a command by changing the contents. 8. Automatization – All user interaction should be automated as much as possible to minimize mistakes. Automatization should be done with scripts in a simple interpreter language. So they are easy to understand and can be changed rapidly. However, it must also be possible to set parameters interactively to a GUI and overrule automatic procedures. All automated procedures should have a reasonable size and breaks. In case something fails it must be possible to execute sub-sequences or only parts of the procedure. 9. Minimize Impact on existing systems – As the LGS system is implemented in an already established environment and might use an already existing WFS for different purpose, the impact on such systems have to be minimized and their current functionality only extended but not removed or disturbed. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 8 of 65 6 ARGOS in a nutshell The optomechanis of ARGOS can be divided into three major components, which are taken over as component in the software structure: LLS: The laser launch system, which consist of the laser system and the launch optics. LGSW: The LGS wavefront sensor, which includes the dichroic. T3S: The tip tilt and truth sensor, which is based on the existing First light AO System (FLAO). The deformable mirror diagnostics and the real-time reconstruction built an additional software component, as the first is already one separate part in the existing FLAO and the latter is based in dedicated electronics. Further we define a wavefront data handling system, which takes care of automatic optimization and offloading between different optical elements. Therefore, we have three further components: DMD: Deformable mirror diagnostics, which monitors the DM data and does the housekeeping of the DM unit. RTR: The real-time reconstructor software. WDHS: The wavefront data handling system, which optimizes the AO loop and handles all the off-loading and slow steering control loops of the system. All these components have to interface with each other and the Telescope Control Software (TCS) provided by an communication interface. The communication to the DM is defined by the ASM interfaces from Microgate. Figure 1: Component overview of ARGOS software. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 9 of 65 Figure 2: The scheme shows the control architecture with all interactions and the optical paths (ultra fine dashed lines) for the LBT LGS GLAO system The ARGOS system contains several control and off-loading loops as can be seen in Figure 2. The control loops will be now shortly discussed separately. Laser Launch control loops Field control: The second mirror of the laser launch periscope controls the outgoing laser field positions and differential initial settings for each laser separately. The position is measured with the field diagnostic camera on a high sample rate. Pupil control: The first mirror of the laser launch periscope controls the outgoing laser pupil position for each laser separately. The position is measured with the pupil diagnostic camera on a low frame rate. The optical entaglement of the two periscope mirrors on field position and pupil position is divided by the different sampling rates of the field control and the pupil control. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 10 of 65 Launch stabilization: Accelerometers and off-loading from the WFS field stabilization will be taken as input for the launch stabilization, which is done with the launch pupil mirror. Focus control: The launch focus is controled with look up tables in feed forward using an objective on a stage. Focus refinement can be done with help of the WFS data. Laser Guide Star WFS control loops LGSW field steering: A patrol camera in the WFS monitors and positions the laser on the LGSW initially. The LGS WFS tip tilt is controlled with a periscope mirror system within each sensor path. WFS pupil tracking: Evaluation of the outer subaperture intensities are used to set and track the pupil position. A lens in front of the Pockels cells is moved compensating pupil flexure. High order loop: The LGS WFS corrects the atmospheric turbulence with the Adaptive Secondary. Tip Tilt modes are excluded. Gating: The altitude and gating range is defined with the master clock and delay generators. Tip Tilt control loop and Truth sensing Natural Guide Star TT loop: The tip tilt measurement of the First Light AO (FLAO) system is sent to the LGS WFS and added asynchroniously to the next LGS WFS command. Truth sensor: The FLAO is used for truth sensing. Comparing LGS WFS measurement to NGS measurements and refining slope offsets or calibrating modes. Wavefront Data Handling System off-loading and arbitration The WDHS collects all the WFS measurements of the LGS WFS and TT WFS/Truth Sensor. The offloading scheme can be summarized as follows: Long term atmospheric TT to hexapod. Tracking TT to mount. Telescope Flexure to hexapod. Launch Flexure to the entrance pupil mirror of the launch system (see launch stabilization above). Differential tip tilt at the WFS side to laser steering mirrors in launch. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 11 of 65 7 Use Cases In this chapter we define the overall instrument use cases. This requires first to understand the users, in software slang Actors. After that we define the observation modes and describe the sequences one has to follow to get the instrument into operation. . 7.1 Actors There are three different actors identified, which will use or operate the LGS system. 7.1.1 Astronomer The astronomer is the actor requesting the use of the LGS system either in advance through her/his observation proposal or at the site interactively because of promising conditions to use the system. She/he might not be operating the system on his own. The astronomer needs software to prepare his observation and define observation relevant parameters in advance and at the site. 7.1.2 Operator The operator is the actor running the LGS system. She/he starts the hardware and software and then handles the system - mainly through GUI. In cases of simple errors she/he is allowed to take the action to recover. Therefore the operator should have a good knowledge of the system in order to be able to carry out these tasks. In case of errors, which are not easy to recover she/he should be able to identify and contact the right engineer to fix the system. The operator, as defined here, should not be confused with telescope or instrument operator. It can be the telescope or instrument operator but it could also be i.e. a support astronomer, visiting astronomer or any other person fulfilling the profile above. The operator needs software to handle and control the system like status GUI and command GUI as well as scripts and servers to run the overall system. He must also be able to take over the pre-prepared observation defined by the astronomer. 7.1.3 Engineer The engineer is the actor who must be able to run the system on all levels. She/he needs ability to control single hardware components standalone, as well as the possibility to change the debugging and logging levels to evaluate the individual parts and the overall system. She/he is also the only one allowed to install and remove the software and parts of it. The engineer needs software to communicate with the hardware even on lowest level and over command line. She/he needs evaluation and debugging tools on all system levels. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 12 of 65 7.2 Observation Modes In principle, one would distinguish observation modes in spectroscopy, imaging, etc. However, the LGS system is more integrated with the telescope than with the instrument. It will be used with LUCIFER just with one side or with both sides together. Maybe in the future there will be further sensors on other instruments making use of GLAO. The system provides a nearly homogeneous PSF over the field and behaves as seeing reducer. In such case it might be irrelevant to the astronomer to know if it is running or not, as the scientific data outcome looks close to one obtained w/o GLAO but under better atmospheric conditions. Therefore, the observation modes of LGS-GLAO system define themselves less from the view of spectroscopy or imaging but from the way how the system is operated: with or without preparation, with or without TT-star, etc. Therefore we define following observation modes. 7.2.1 Pre-prepared The astronomer has prepared the observation in advance by defining LGS and instrument relevant parameters like the reference TT star, constraints on atmospheric conditions, etc. Depending on the Target the observation can be with or w/o TT star. 7.2.2 Interactive The astronomer decides on the spot to turn on the LGS system to improve the current seeing condition. The TT-star is selected interactively through a selection GUI if one is available within the FoV. Figure 3: Use case diagram1 of the ARGOS observation modes. The two modes have different requirements to the software design, while the Pre-prepared demands an Observation Preparation Software (OPS) the interactive modes demands GUIs which allow for simple and fast interaction with the system.In the following we will support both ways with no further mentioning the two different modes explicitely. Further design drivers due to the mode analysis: Observation Preparation Software for pre-prepared mode, which can be used at home and at site. Graphical User Interface to select TT guide star interactively. 1 For all who are not so familar with Use case diagrams: An ‘extend’ is a form of interaction, the relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The ‘include’ is another form of interaction, the given use case may include another. The first use case often depends on the outcome of the included use case.. (Courtesy to Wikipedia for wording inspiration.) © ARGOS Consortium Doc: Issue Date Page Software Preliminary Design ARGOS PDR 012 1.0 2009/02/01 13 of 65 7.3 Observation procedures The observation procedures define the tasks to be done with an observation. In non-optimal case they are expanded by setup procedures to optimize the telescope and wave front sensor performance. Two major procedures could be identified. The first one is preset the telescope and the second one is offset over a large or a small distance, nodding or dithering respectively. Depending on the distance the procedure will use different hardware. Each observation procedures should be automated and parallized as much as possible but also splitted in sub-procedures in such way, that not everything has to be repeated in case of an error. Figure 4: Use Case Diagram of the ARGOS observation procedures. 7.3.1 Preset The preset procedure acquires the observation target and gets the telescope and GLAO system in a state such that the instrument can start the observation. The preset is divided into the Telescope, Launch, LGSW and T3WFS parts of the preset which are following in sequence. The expected maximal and average duration of each part and the sum for the full preset is given in Table 1 for the different observation modes. Details on the calculation can be found in the following description of each part of the preset. The maximal execution time is estimated to be less than 15min (interactive mode), while the shortest execution time is estimated with 4min (Preselected mode). Table 1: Estimation of the maximal and averge execution time for the preset in different observation modes. The light green adds to usual AO observations as LGS overhead. Preset Telescope Launch LGSW T3WFS Sum LGS overhead Preselected Max. 380s 60s 80s 100s 10.3 min/620s 140s Preselected Av. 130s 17s 43s 50s 4min/240s 60s © ARGOS Consortium Interactive Max. 380s 60s 80s 340s 14.3min/860s 140s Interactive Av. 130s 17s 43s 170s 6min/360s 60s Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 14 of 65 7.3.1.1 Telescope The goal within this part of the preset is to point the telescope and start the tracking. All mechanical units which have long moving times should be set to their nominal start positions so all further actions will not be delayed too much. The telescope preset is common to all observation modes but stated here to verify the complience with the existing implementation. Preconditions: The selection of the instrument is done in advance and with that the Tertiary mirror is set to the required angle. The instrument hardware is switched on and ready to use (state: online). The target must be cleared from space command. A launch delay should be considered. Procedure: The Preset moves the telescope to the object positon and starts tracking. Therefore, the telescope slews in azimuth and elevation until the object coordinates are reached. In parallel, also the rotator angle of the instrument and AGW Unit is set. In case a TT star is pre-selected, the sensor moves to the corresponding position. If not already in, the ARGOS dichroic is moved into position.The Primary shape and Secondary shape is applied according to the collimation table parameters for the given target position and ambient temperature. After arrivial at the target position the telescope starts open loop tracking. Refinement of the collimation is not performed as this is done in closed loop with permanent offload to the mount control and primary control. The defined open loop tracking requirements of [AD 28] are sufficient to setup the system further, therefore, no guiding is needed before closing the AO loops. Figure 5: Activity diagram descsibing the tasks during telescope preset. Time Estimate: The time dominating part will be the setting of the elevation and azimuthal drives. From the telescope slew rate of 1.5deg/s [AD 28] the preset is expected to take not longer than 380s. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 15 of 65 Action Set azimuth Set elevation Set primary Set secondary Set rotator Set TT-stages Set dichroic Start tracking Procedure Max/Avg. Maximal time Error scenarios Telescope doesn’t reach target position: Coordinates out of range Telescope HW problem Resolving If the target coordinates are out of range, i.e. below horizon, the observation has to be stopped. To avoid such error the coordinates should be checked for consistency before sending to the telescope. In the case of HW problems, the HW has to be fixed or set in simulation by interacting directly through the telescope interface not through the LGS software. After the problem is resolved the Preset has to be started from the beginning. As the rotator has more than 360 degree rotation capability it is either a software or a hardware problem of the rotator but not a problem of beeing not able to reach the position at all. This problem has to be resolved directly through the rotator interface. After the problem is solved the rotator can be set manually and the sequence can continue The LGS system can be operated without TT star with paying the expenses in performance degradation. The dichroic must be in place for LGS operation. The problem must be manually solved in engineering mode. Such error is recognized by making an image with the science camera. This might reduce efficency, especially in the case of spectroscopy when slits have to be moved. Alternatively the FLAO acquisition camera could be used. This camera is always available, but the FLAO has to be set properly and a position calibration between WFS and instrument is required. After the pointing mismatch is measured an offset with the correct size is applied to the telescope. Depending on the reason, the feedback is either through the command reply or the error is recogniced with an image of the science camera or the acquisition camera of the WFS (exposure time ~1s). Start tracking manually after the reason is resolved. TBD unsufficient. Resolve mirror problem manually with direct interaction. After that continue sequence Resolve mirror problem manually with direct interaction. After that continue sequence. TBD unsufficient Rotator doesn’t reach target angle TT stages do not reach position Dichroic does not reach position Pointing off target position Tracking doesn’t start Tracking performance unsufficient Primary mirror fails Secondary mirror fails Collimation unsufficient Expected average time Counted 120s x 64s parallel 13s parallel 13s parallel 120s parallel 60s parallel 60s parallel < 20s 10s x 380s 130s < 360s < 127s parallel < 25s parallel < 25s parallel < 360s parallel < 120s parallel < 120s parallel © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 16 of 65 7.3.1.2 Laser Launch The laser is projected on sky. The launch position is set to a nominal value and stabilized. Preconditions: Before launch of the laser, the telescope has to be on position and the target has to be cleared by space command. Aircraft spotters or an aircraft avoidance system can hold the launch at any time. The lasers are switched on in the beginning of the night to bring them to temparture. Procedure: With launch, the laser status goes from “Online” to “Working” (description of these states in chapter 9.1.1) and the internal laser shutter opens. The gating range is pre-defined by the clocking but can be changed at any time. The pupil control starts and stabelizes the pupil by moving the launch periscope. The field control starts setting the individual laser spots to each other on the proper sky position using the launch periscope. Focus position gets adjusted with help of a LUT (temperature dependent). The field stabilization starts to reduce the LGS common jitter on sky, using the launch pupil mirror. This loop gets fed with accellerometer measurements and WFS off-loads and defines the relative position of all three LGS to the telescope pointing. Figure 6: Activity Diagram showing the launch procedure. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 17 of 65 Time Estimate: So far this tasks can be fully automated the execution time should be quite fast. However, error cases of certain sub-tasks and manual interactions might extend the execution time. The tasks which go into the preset time calclulation are opening the shutter and setting the various components to the nominal positions. Action Open shutter Set nominal positions Keep positions (until loops are stable) Procedure Max/Avg. Maximal time Error scenarios Laser fails Resolving The system must be tolerant against individual laser failures. It must inform all other systems about the individual laser failures but should not stop the launch at all. It must be possible to resolve individual laser failures manually and restart the laser loops separately. It must also be possible that the system runs with an incomplete number of lasers. This requires simulation modes in several levels. Similar to laser failures individual treatment for each shutter must be possible. Such failure could be a following error of a shutter failure or result from rejected clearance or interlocks. The different sources must be made transparent. Shutter failuers can be resolved manually and after that the launch restarted. In case of clearence failure it must be easily possible to get the information if and when clearence is given for the object. In case of an interlock failure it must be possible to find the blocking interlock. Depending on the reason the interlock should be kept, released or overwritten. This might be related to harware failure or the camera is powered off. It must be possible to resolve the problem manually and start the pupil tracking loop individually without restart from beginning. This might lead to oscillations at the periscope mirrors. It must be possible to reset the pupil position. This might be related to hardware failures or wrong parameters. It must be possible to change gain of the loop and the pupil position. It must be possible to restart the pupil tracking loop individullay without starting the launch from beginning. This might be related to hardware failure or the camera is powered off. It must be possible to resolve the problem manually and start the position tracking loop individually without starting the launch from beginning. This might lead to oscillations at the periscope mirrors. It must be Laser shutter fails Laser shutter not open Laser pupil camera read fails Laser pupil position wrong Laser pupil loop fails Laser field camera read fails Laser field position wrong < 20s < 20s < 20s 60s © ARGOS Consortium Expected average time Counted 3s x 7s x 7s x 17s Software Preliminary Design Laser field loop fails Launch focus movement fails Launch focus movement wrong position Launch field stabilization fails Launch field stabilization unsufficient Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 18 of 65 possible to reset the pupil position. This might be related to hardware failures or wrong parameters. It must be possible to change gain of the loop and the field position. It must be possible to restart the field tracking loop individually without starting the launch from beginning This might be related to hardware failure or limitation in range. The first problem has to solved manually. The latter problem would involve a reset of the focus position on sky. This has also to be communicated to the WFS, as the pockle cell delay might need to change. This can only be seen on the WFS. A procedure to get the proper focus position is needed. It must be possible to run this procedure separately. A new set point must be the result and the focus has to move to the new position. This might due to hardware failure or wrong parameters. It must be possible to check the accelerometer measurements. The problem has to be solved manually and the loop is started individually. TBD unsufficient. Such error can be only understood with help of the WFS. It must be possible to change gain and set points of the stabilization loop. 7.3.1.3 LGS Wavefront Sensor The LGS is acquired and the loop is closed. The LGS high order loop is closed before the TT loop. Preconditions: Before closing the loop the telescope preset must be finished and the laser must be launched. The dichroic must be in place. The WFS sensor and the ASM is switched on in the beginning of the night and running in open loop. Procedure: The WFS Tip Tilt steering mirrors are set to their nominal positions. The common mispointing of all laser launch positions are refined with feed forward of the WFS patrol camera field diagnostics and WFS tilt measurements to the launch pupil mirror. Individual mispointings will be compensated with the WFS Tip Tilt steering mirrors. The steering loop of the WFS Tip Tilt mirrors are closed with help of the patrol camera to compensate for remaining sensor flexure and launch flexure, the TT signal of the LGS WFS is used for the fast launch steering. The WFS pupil tracking loop is closed with use of the ShackHartman pattern. The LGS-WFS parameters like modes, gain, frame rate, etc. are set depending on the results of open loop measurements. The WFS focus is set. The loop gets closed and continiously optimized. Any launch interrupt will stop the loops or the loops end with finishing the observation. . Time Estimate: Starting the LGS WFS will be dominated by the iterations, which are needed of each step to converge to an optimized situation. Also errors and repeates because of wrong parameters (bad slope offsets, etc.) might extend the LGS WFS startup tremendously. In the normal case most of the actions have similar impact on the overall execution time. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 19 of 65 Figure 7: Activity Diagram showing the LGS WFS preset. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 20 of 65 Action Set steering mirrors Set pupil Start steering loop Start pupil tracking Set loop parameters Set LGS WFS focus Start LGS loop Procedure Max/Avg. Maximal time Error scenarios WFS patrol camera fails Resolving This might be related to harware failure or the camera is powered off. In case the camera can be fixed a procedure should exist to do the acquisition without the patrol camera using only the WFS detector. The launch steering mirror can be used to get the LGS into the patrol field. Than the usual procedure can be followed. The launch power has to be checked and increased or the patrol camera has to extend the exposure time. Due to temperature and focus the platescale can vary. TBD TBD unsufficient. Such error might increase the spot size in the WFS. If the hardware cannot be fixed a slope offset can be applied, which is compensating in case of de-focus. A separate focus routine must exist to measure the WFS focus and reset the position. There must be a possibility to create BCU parameter files and upload them fom command line. The BCU must be reconfigured. The current configuration of the BCU must be transparent and visual to the operator. It must be possible to create a new reconstruction matrix on the fly, either from existing measurements or new measurements on sky or with a calibration source. Tools for visualization and comparison of reconstruction parameters should be available. Same as for reconstruction matrix. The current image quality should be available in Zernike or other modes. Depending on the amplitudes and modes optical elements will be reconfigured in position or shape. It must be possible to set the gain manually overwritning the automatic optimization. It must be possible to set the gain manually, overwriting the automatic optimization. The laser power must be increased or exposure time extended. Reajustment of optical elements to compensate. Laser not in the patrol field Not enough flux for detection Platescale mismatch WFS Steering loop unsufficient WFS focus motor fails Wrong WFS focus position Parameter upload to BCU fails Switch BCU misconfigured Bad reconstruction matrix Bad slope offsets Bad collimation Gain to low Gain to high Not enough flux for detection Wrong platescale < 20s < 20s parallel < 20s < 20s parallel < 10s < 20s < 20s 80s © ARGOS Consortium Expected average time Counted 10s x 10s parallel 10s x 10s parallel 3s x 10s x 10s x 43s Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 21 of 65 7.3.1.4 Tip Tilt and Truth (T3) Sensor The TT sensor is acquired and the the TT loop is closed. The TT sensing requires binning of the CCD. For truth sensing also higher order information is provided, if requested. After substitution of the current FLAO CCD with a L3CCD [AD 11] one could do permanently higher order truth sensing without readout penalty and its resulting decrease in sky coverage. Preconditions: The sensor must be switched on in the beginning of the night. Before closing the T3 loop the telescope preset must be finished. The LGS WFS loop should be closed, but there should also be the possibility to close the T3 loop without LGS WFS loop closed. Open loop read of wavefront aberrations should be possible at any time. Procedure: It must be possible that if no T3 star is available the LGS system runs without TT corrections. In case the T3 star is not preselected and given with the preset it must be possible to interactively select a T3 star from a user interface. Such interface has to visiualize the available stars with their magnitude from a guide star catalog. It must also be possible to show an acquisition image of the T3 WFS acquisition camera together with the guide star catalog data, similar to the functionality of the skycat tool [AD 29]. Figure 8: Activity Diagram showing the T3 WFS preset. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 22 of 65 The T3 sensor re-rotator is started, in the interactive mode after the T3 WFS is set to position or in preselected mode immediately with start of the T3 WFS part of the procedure. Than the WFS position can be refined interactively or automatically with the help of the acquisition camera. In parallel the pyramid modulation starts and the loop parameter like modes, gain, frame rate, etc set. Now the TT loop closes until the observation is finished sending a signal to stop the T3 loop. The telescope focus can be refined with the AO TT data if necessary. Time Estimate: Starting the LGS WFS will be dominated by the iterations, which are needed of each step to converge to an optimized situation. Also errors and repeates because of wrong parameters (bad slope offsets, etc.) might extend the LGS WFS startup tremendously. In the normal case most of the actions have similar impact on the overall execution time. Action [Select from catalog] [Set T3 WFS] Start re-rotation Refine acquistion Start modulation Set T3 loop parameters Start T3 loop Procedure Max/Avg. Maximal time Error scenarios Re-rotator fails Resolving If it is a hardware problem, which can not be fixed the system might not suffer if the change in parallactic angle is small over the observation time. In addition one could imagine to follow the star with the T3 WFS support stages and re-rotate the pupil in software. TBD unsufficient. No interactive acquisition is possible and the refinement has to be done with the pyramid directly using tilt signals. Manual interaction using the pyramid pupil images and the T3 support stages. An algorithem is needed to catch the star. Switch to interactive mode and select different T3 guide star. If no suffient bright star is available run the system without T3 star. It was demonstrated, that the pyramid system could in princip run with natural seeing without modulation [RD 8]. TBD unsufficient. There must be a possibility to create BCU parameter files and upload them from command line. The system is run without TT correction. It must be possible to create a new reconstruction matrix on the fly, either from existing measurements or new measurements on sky or with a calibration source. Tools for visualization and comparison of reconstruction paramters should be available. Same as for reconstruciton matrix. It must be possible to set the gain manually overwriting the automatic optimization. Rerotation unsufficient T3 acquisition camera fails T3 guide star out of field T3 guide star to faint Pyramid modulation fails Pyramid modulation unsufficient Parameter upload to BCU fails TT signal does not arrive to LGSW Bad reconstruction matrix TT Bad slope offsets TT Gain to low Expected average time Counted [60s] [x] [60s] [x] 10s x 30s x 10s parallel 3s parallel <20s 10s x 100s [340s] 50s [170s] [<120s] [<120s] <20s <60s <20s parallel <10s parallel © ARGOS Consortium Software Preliminary Design Gain to high Not enough flux for detection Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 23 of 65 It must be possible to set the gain manually overwriting the automatic optimization Reacquire new T3 star with sufficient brightness interactively or run the system without TT correction. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 24 of 65 7.3.2 Offset The background in the NIR is varying over time. The technique to reduce later on such background fluctuations is to move the target on the science detector from one to another exposure. Depending on the target, smaller or larger offsets are needed. On the other hand depending on the offset size different schemes are needed to do such movements. We divide the offsets in two classes. Offsets up to 2” are called dithering and offsets larger than 2” are called nodding. The division at 2” is due to limits of the ASM Tip Tilt range. 7.3.2.1 Dithering – offset ≤ 2” Dithering moves the field of observation up to 2” on sky. In such case the telescope mount is not moved at all but the ASM is used to do such offset. Dithering with TT star: Preconditions: The observation is using a TT guide star for correction. The LGSW and the T3WFS loops are closed and stable. Figure 9: Action diagram showing the dithering sequence using the T3WFS to drag the ASM. Procedure: After it is acknowledged that the last science exposure is done and no new one is started, the gains of the LGSW loop and the T3WFS loop are reduced and fixed, means no optimization during dithering. This is done for safety reasons to avoid overreaction of the control system. Than the T3WFS © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 25 of 65 sensor is moved with a speed slower than 1”/s to the offset position, which leads to an even slower reaction of the ASM because of the loop gains. The goal is to move the target with about 0.2”/s. The slow speed gives the controller enough time to react to the changes without to much disturbance. The movement drags the ASM with it and introduces an offset in the science image and a tilt on the LGSW system. The flexure compensation loops of the LGSW system will counteract this tilt and remove it. After the control systems are stabelized the next science exposure can start. Time Estimate: This is the fastest offset possible. It will take in worst case a bit more than one minute. All actions need similar fractions of time on the full amount. Action Reduce gain LGSW Reduce gain T3WFS Drag T3WFS Increase gain LGWS Increase gain T2WFS Procedure Max/Avg. Maximal time Expected average time Counted 10s x 10s parallel <30s 15s x <20s 10s x 10s parallel <70s 35s <20s <20s parallel <20s parallel Dithering without TT star: Preconditions: The observation is not using a TT guide star for correction. The LGSW loop is closed. Figure 10: Action diagram showing the dithering sequence using no TT star and moving the ASM directly. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 26 of 65 Procedure: After it is acknowledged that the last science exposure is done and no new one is started the gain of the LGSW loop is reduced and fixed, means no optimization during dithering. This is done for safety reasons to avoid overreaction of the control system. Than the ASM is tilted with 0.2”/s. The tilt can be introduced through the LGSW sensor. The small steps give the LGSW system and launch system time to react to the tilts. The LGSW field stabilization loop and the Launch field stabilization loop will correct for the tilts with the periscope Tip Tilt mirrors. After the control systems are stabelized the next science exposure can start. Time Estimate: The time estimate is the same as for the mode with TT star. Action Reduce gain LGSW Drag ASM Increase gain LGWS Procedure Max/Avg. 7.3.2.2 Maximal time <20s <30s <20s <70s Expected average time Counted 10s x 15s x 10s x 35s Nodding – offset > 2” Nodding moves the field of observation when the offset is larger than 2” on sky. In such case the telescope mount is moved and loops must be opened. Preconditions: The observation might use a TT guide star for correction. The LGSW loop is closed and the T3WFS might be used. Procedure: If the observation is without TT star the part of the T3WFS can be skipped. The LGSW loops and the T3WFS loop will be stoped for safety. The T3WFS support stage will be moved and the telescope will move, both of the offset amount. The LGSW acquisition and the T3WFS acquisition will be refined automatically. In case of the LGSW the field diagnostic camera is used and for the T3WFS the acquisition camera is used for this task. In case the automatic refinement is not sufficient an manual refinment can be added. The LGSW loops are started again and after they are running stable the T3WFS loops are started. The next science exposure can start. Time Estimate: The estimated execution time for nodding is 1min in average and up to 4min in case of the interactive mode. In the case of interactive mode the refinement will be sequential, what increases the execution time tremendously. Action Stop T3WFS loop Stop LGSW loop Move T3WFS Move telescope Refine LGSW acquisition [Manuel refinement LGWS] Start LGSW Refine T3WFS acquisition [Manuel refinement T3WFS] Start T3WFS loop Procedure Max/Avg. Maximal time <10s <10s parallel <20s parallel <30s <40s [60s] <20s <40s parallel [<60s] <20s 120s [240s] © ARGOS Consortium Expected average time Counted 5s x 5s parallel 10s parallel 15s x 20s x [30s] [x] 10s x 20s parallel [30s] [x] 10s x 60s [120s] Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 27 of 65 Figure 11: Activity diagram showing the nodding procedure. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 28 of 65 7.4 Setup procedures Setup procedures define the tasks to be done to get the telescope and ARGOS system ready for operation or optimize its performance. Figure 12: Use Case Diagram of the ARGOS Setup Procedures. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 29 of 65 7.4.1 Startup It must be possible to startup all the systems individually and independent. 7.4.1.1 Select instrument There must be a procedure to select the instrument. Such operation includes the setting of the tertiary, which selects intrinsically the focus. The focus has to be locked. 7.4.1.2 Start-up T3WFS The Start-up TT-WFS procedure powers the TT-WFS on and initializes all motors and devices. More atomic actions, which one should be able to execute individually are: Read acquistion camera Read open loop data 7.4.1.3 Start-up LGSW The Start-up LGS-WFS procedure powers on the LGS-WFS and initializes all motors and devices. More atomic actions, which one should be able to execute individually are: Switch on the power Move Dichroic in and out Set ADM switch BCU to the LGSW Read diagnostic cameras Read open loop data 7.4.1.4 Start-up LLS The Start-up LLS procedure powers on the laser and laser launch system and initializes all motors and devices. More atomic actions, which one should be able to execute individually are: Power on Lasers for heat up. Read diagnostic cameras of the launch system. 7.4.2 Measure laser position Such procedure needs the lasers and the diagnostic cameras switched on. The pupil and the field position are measured for a certain elevation and the set points for the pupil and field position are defined. 7.4.3 Measure focus There are several foci to adjust in the ARGOS system, the T3WFS focus, the LGSW focus and the focus of the Laser on sky. All the measurements can be made independently. 7.4.3.1 Measure T3WFS focus The Focus T3WFS runs a focus routine for the T3WFS. Therefore, the T3WFS has to run and a guide star must be acquired beforehand or an artificial source is inserted into the light path. Several images at different focus positions are made and the minimum FWHM is determined in the WFS acquisition unit. Alternative or in parallel to the observation the focus term can be measured with the WFS at the different focus positions and the position of the minimal focus term can be calculated. Finally the sensor is set to the optimum focus position taking slope offsets into account. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 30 of 65 7.4.3.2 Measure LGSW focus The laser must be launched or an artificial light source inserted into the light path. The LGSW sensor must be switched on. The focus of the LGS-WFS is determined by moving the focus unit of the sensor. The focus term from the WFS open loop measurement is calculated. The focus unit is set to the optimum position taking slope offsets into account. 7.4.3.3 Measure LLS focus The laser must be launched and the LGSW sensor must be switched on. The LGSW has to be set first. The spot size on the LGSW is measured and the focus unit of the launch system moved. The smallest FWHM defines the optimal LLS focus. The focus unit is set to the optimum position. 7.4.4 Measure slope offset Slope offsets correct for static aberrations within the common and non-common optical paths between sensor and instrument. The slope offsets are measured to optimize the delivered image quality on the science detector. Therefore the shape of the DM is changed until the best image PSF is achieved on the science detector. After that the shape is stored and subtracted in closed loop from the nominal mirror shape. The strategy to measure non common path abberations between the systems is detailed in [AD 13] but can be summarized here as follow: a. Optimize the on-axis position and image quality on the science detector b. Measure non common path aberrations on the T3WFS and the LGSW c. Minimize aberrations in T3WFS and LGSW by using non common path optics d. Set slope offsets of T3WFS and LGSW 7.4.4.1 Measure PSF on science detector Before measuring the non-common path abberations in the WFS the image on the science detector should be optimized. This can be done with a bright star on sky or with an artificial light source. The science case must be turned on and ready to take imags. A sky source must be acquired or the artificial light source must be inserted and switched on. The spot on the science detector is measured and optimized using phase diversity or focal plane reconstruction techniques. The shape of the ASM is changed to optimize the spot on the sience detector. 7.4.4.2 Measure slope offset T3WFS A bright point source on sky must be acquired or the artifical light source must be inserted and switched on. The image quality on the science detector must be optimized. The wavefront abberations on the T3WFS is measured in open loop. Non common path optics of the T3WFS is operated to reduce the measured abberations. The remaining abberations are stored as slope offsets, defining the new set point of the sensor. 7.4.4.3 Measure slope offset LGS-WFS The laser must be launched on sky or the artifical light sources for off-axis calibration must be inserted and switched on. The image quality on the science detector must be optimized. The wavefront abberations on the LGSW is measured in open loop. Non common path optics of the LGSW is operated to reduce the measured abberations. The remaining abberations are stored as slope offsets, defining the new set point of the sensor. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 31 of 65 7.4.5 Measure interaction To create a reconstruction matrix, which is needed to close the loop, the influence of the mirror on the WFS have to be measured. The reconstruction is finally done with one matrix and one slope vector, which consist of the high order LGSW measurement and asynchroiously added TT information from the T3WFS. However, the measurement on both sensors to get the interaction can be done separately. 7.4.5.1 Measure T3WFS interaction The Create TT-WFS control matrix procedure measures the influence of the DM on the wavefront sensors. Therefore, the calibration unit has to be inserted and started. Then the mode to be measured is applied to the DM and the influence of the WFS is recorded. This is repeated for each mode. After measuring the modes the matrix is inverted, i.e. with a SVD algorithm, and the control matrix is calculated. Finally the control matrix is loaded to the wavefront reconstruction computer. In the case of the TT-WFS this will be only a few modes (less than 10). There can be further schemes to create the control matrix on sky. 7.4.5.2 Measure LGSW interaction The Create LGS-WFS control matrix procedure measures the influence of the DM on the wavefront sensors. Therefore, the calibration unit has to be inserted and started. Then a mode to be measured is applied to the DM and the influence of the WFS is recorded. This is repeated for each mode. After measuring the modes the matrix is inverted, i.e. with a SVD algorithm and the control matrix is calculated. Finally the control matrix is loaded to the wavefront reconstruction computer. There can be further schemes to create the control matrix on sky. 7.4.6 Measure background The detector background is a sum of bias and dark counts. The background is measured in the beginning and than from time to time on a low frequency. 7.4.6.1 Measure T3WFS background The T3WFS detector has to be switched on. The other sensor components are not needed but could be switched on. It has to be dark or the shutter, if existend, must be closed. Several exposures are taken and an average background for each pixel is then calculated. 7.4.6.2 Measure LGSW background The LGSW detector has to be switched on. The other sensor components are not needed but could be switched on. It has to be dark or the shutter, if existend, must be closed. Several exposures are taken and an average background for each pixel is then calculated for each pixel. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 32 of 65 8 Operating Environment The software has to work within the LBT software and computer environment. Further the First Light AO system (FLAO) is used as TT WFS and Truth sensor (T3WFS). Already existing software and computer environment should be re-used as much as possible and all existing operation modes should not be impacted by the ARGOS implementation. 8.1 Current Hardware layout of FLAO The FLAO system hardware consists of the WFS unit and the DM electronics. The DM electronics is a self-contained extendable system based on BCU boards. The BCU boards are doing all the calculations necessary to control the actuators and are able to run in parallel the reconstruction of the AO system. A specialized BCU board is used to acquire the sensor images and calculate the slopes for the effective data. This all happens on the ASM network (blue line in Figure 13). Figure 13 shows the FLAO WFS unit. All the hardware devices are commanded through RS232 serial lines on the usual telescope network (red). There are filters, position stages, pupil re-rotation and CCD controller. All this, including the data of the acquisition camera might be used as it is for the TT-star. Figure 13: Current hardware layout of the FLAO WFS unit. There are several controller for motors, CCD, etc., which are commanded through RS232 (green) on the usual telescope network (red). But there is in addition a dedicated communication line to the ASM (blue) for real-time reconstruction. 8.2 Current SW layout of FLAO The AO supervisor software consists of two main parts: the WFS software and the DM diagnostic software. All the reconstruction is done within the DM electronics and excluded from this software. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 33 of 65 The WFS software takes care of all the hardware devices of the WFS (motors, CCD controllers, etc.), monitors temperature in the WFS unit and provides data to the acquisition camera. The WFS arbitrator receives commands from outside through the AO arbitrator and dispatches them within the WFS software. The DM diagnostics software does housekeeping, fast diagnostics and sets mirror parameters through an IDL controller. The housekeeping includes monitoring the status of the DM electronic on-board of each card. It has access to data like voltages and currents of the power supplies, temperatures, air pressure and humidity. The fast diagnostic software monitors the status of the shell, provides warnings/alarms and react in case of necessity automatically. It has access to data like actuator position or forces and provides them to GUI and high level applications. The IDL controller can calculate the value of parameters, i.e. reconstruction matrix, of the ASM and load it then to the DSP in the DM electronic. IDL scripts sequence the setup of the DM. The WFS software and DM diagnostics software is coordinated on the AO supervisor side by the AO arbitrator. The AO arbitrator receives requests from the TCS through the AOS subsystem of the TCS. The AOS subsystem acts as a bridge between TCS and the AO supervisor. It listens to the commands from other TCS subsystems and sends the appropriate request to the AOA. More detailed information can be found in [AD 16], [AD 17], [AD 18], [AD 19] and [AD 20]. Figure 14: Current FLAO software overview. The AOSupervisor consist of two main packages: WFS software and ASM software. Both are coordinated by the AOArbitrator, which is talking to the AOS a TCS subsystem listening to the other TCS modules for requests to the AO system. 8.3 Current interface to TCS LBT TCS software and AO supervisor software are using different middleware to communicate between their processes. Both software have built their own IPC libraries. LBT TCS software is using a XML RPC version [AD 30] and the AO supervisor is using a message system directly based on sockets. The © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 34 of 65 interaction between the AO supervisor software and the TCS is by means of communication protocol, which is implemented in the AOS subsystem of the TCS following [AD 31]. As defined in [AD 18] the AOS provides following states: Standalone, when the AO system is operational but will neither request nor accept interaction with the TCS. Engineering, when the system is performing calibration or maintencance function,and requires services from the TCS (to operate telescope devices or to point asuitable reference star). Ready, when the system has successfullly completed the automatic bootstrap preocedure waitin for TCS requests or direct interaction. Observation, when the AO system is supporting an observation The AOS functional description [AD 18] defines a set of commands, which the AO system accepts from the TCS for further action. The list of commands is shown in Table 2. Command StartObs PresetFlat Preset AO AcquireRefAO GetSnap RefineAO StartAO OffsetXY OffsetZ CorrectModes Stop Pause Resume Terminate User Panic State Ready Observation Observation Observation Observation Observation Observation Observation Observation Observation Observation Observation Observation Observation Observation Engineering Ready Description Start an observation Preset AO System for seeing limited operation. Preset AO System for adaptive operation. Acquire the reference star and become ready for closing the AO loop. Get a snapthot image of the AO field of view. Modify some AO loop parameter. Start the AO mode (i.e. close the AI loop. Offset AO pointing. Offset AO focus. Apply mirror shape correction. Stop current operation. Temporarily suspend current operation. Resume suspended operation. Terminate an observation. Emergency shutdown request. Table 2: List of commands AOS accepts from the TCS. But the AO system must also be able to send commands to the TCS. Such commands are mainly necessary for engineering and notification. Three subsets of commands are defined, which can be send from the AO supervisor to the TCS through the AOS. The first subset includes housekeeping commands as listed in Table 3. Command RequestService EndOfService LogItem Stop State Description Engineering Request exclusive service from TCS, Engineering Notifies to the TCS that the AO ystem has finished with AO engineering operations, and releases the telescope. Engineering Requests to log some information into the TCS Logging system. Observation Engineering Terminate current operation. © ARGOS Consortium Software Preliminary Design Warning Error Panic Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 35 of 65 Engineering Notify warning condition. Observation Engineering Notify erro condition. Observation Engineering Notify some AO System panic condition. Observation Table 3: List of commands issued from the AO supervisor to the TCS. Subset I – Housekeeping commands. The second set of commands, listed in Table 4, are used when the AO System is performing engineering operations which do not require pointing and tracking in the sky. In this mode of operation the AO System may need to directly control devices susch as the hexapod or the rotartor Command SetAltAz SetHexapod SetRotator SetTertiary State Engineering Engineering Engineering Engineering Description Set telecope postion (alt-azimuth, not tarcking). Set hexapod position. Set rotator angle. Set tertiary position. Table 4: List of commands issued from the AO supervisor to the TCS. Subset II – Low level commands. The third subset of commands, listed in Table 5, are used when the AO System is performing engineering operations, which require pointing on sky and tracking. In this case the AO supervisor must be able to control devices such as the hexapod or the primary because they are under the control of PCS. Command ActivatePreset PointTelescope OffsetPointing OffloadModes State Engineering Engineering Engineering Engineering Description Activate telescope preset.GUI. Point telescope and start tracking. Request a pointing offset to the telescope. Offload accumulated aberrations. Table 5: List of commands issued from the AO supervisor to the TCS. Subset III – Pointing commands. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 36 of 65 9 Software Structure and Functional Specifications We now define the software structure concluding on the investigation of the use cases in chapter 7 and taking the current implementation of the First Light AO (FLAO) into account, as described in chapter 8. After presenting the software structure we describe the functional specification of each software package. The software for the right and left arm are identical, just different instances of the same software, as it must be necessary to run both arms independently. A synchronization of the right and left arm is not planned on software level. The only synchronization needed is for gating the lasers, which is done electronically through a master clock. Further software dependencies would create more failure cases and wait situations and therefore make the system less efficient. Any co-ordination needed, between right and left, can be handled on the highest level by GUI or scripts and should involve also the science instruments. Following the general requirements of chapter 5, especially the requirement stand alone, a natural choice of software packages should follow the optomechanical systems of ARGOS. The optomechanics can be divided into three major components, which are taken over as component into the software structure: LLS: The laser launch system, which consist of the laser system and the launch optics. LGSW: The LGS wavefront sensor, which includes the dichroic. T3S: The tip tilt and truth sensor, which is based on the existing FLAO system. The deformable mirror diagnostics and the real-time reconstruction built an additional software component, as the first is already one separate part in the existing FLAO and the latter is based in dedicated electronics. Further we define a wavefront data handling system, which takes care of automatic optimization and offloading between different optical elements. Therefore, we have three further components: DMD: Deformable mirror diagnostics, which monitors the DM data and does the houskeeping of the DM unit in the FLAO system. RTR: The real-time reconstructer software, placed on the slope BCU of the LGSW. WDHS: The wavefront data handling system, which optimizes the AO loop and handles all the off-loading and slow steering control loops of the system. All these components have to interface with each other and the Telescope Control Software (TCS) provided by an communication interface. The communication to the DM is defined by the ASM interfaces from Microgate. For the other communication we have to define the interfaces depending on how close such system have to work together. Following considerations are taken into account: The Launch system has to interact closely via SW with the LGS sensor for the launch stabilization. The WDHS requires close interaction with all diagnostic systems of each component. After intermediate steps, the Offset requires several times synchronization between the LGS and the TT sensor. A close entanglement of both systems is required. The AOS interface of the FLAO provides all required functionality, which is needed also in case of the LGS operation. Due to the close interaction between LLS and LGSW and WDHS it makes sense to implement them embedded into a common software layer, which is able to handle asynchronious command exchange and has a scalable distributed data base system. Minimizing the number of interfaces we propose to use only one interface to the AO arbitrator to handle the communication with the TCS and sequence the T3S and LGSW. The AOS provides all functionallity needed for the LGSW as well as the T3S and the AO © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 37 of 65 arbitrator already now sequences the FLAO system during operation. The proposed structure is shown in Figure 15 including all communication paths envisioned. Two additional packages are defined, which are supporting the astronomer in the preparation of the observation and later in the reduction of the data. PSFR: The Point Spread Function Reconstruction software, which should provide the PSF at any position of the field. OPS: The Observation Preparation Software, which shold support the astronomer to prepare his observation. Figure 15: Package diagram of ARGOS. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 38 of 65 9.1 Common Software As a common middle ware for the ARGOS software packages we propose to use the MPIA inhouse development for LINC-NIRVANA, which consist of two parts: TwiceAsNice, a communication layer and distributed database [Reference] BASDA, a generic device driver library for hardware [Reference] This software is based on ICE an object oriented communication software. The advantage of this choice is that this software provides asynchronous communication, database and easy to implement server and client architecture in a completely distributed system. 9.1.1 TwiceAsNice TwiceAsNice provides the communication layer and a database. The database is distributed and has a tree hierarchy, which can dynamically attach new structures. Tree branches are accessable over network to other clients and parameteres get automatically updated based on an event system. Figure 16: Client server architecure of TwiceAsNice. The principe of the TwiceAsNice server client architecture is illustrated in Figure 16. There are four major components within this scheme: Properties are container objects, which are able to keep data of complex data types like vectors, matrices. Tree Joints represent nodes of the data tree structure, which defines the hierarchical path to a data object (Property). Bridges do connect two or more Properties of the same data type. They manage the data synchronization between connected Properties. Actors are objects, which can be attached to a Property. The processing function of the Actor is called before actually setting the data. Within the processing function user defined actions can take place. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 39 of 65 Any application, which will be built based on this software will have four major states, which it inherits from the base classes. Automatically also a property interface is provided, which can be loaded from ASCII configuration files. The schematic of Figure 17 shows the basic interfaces and state machine any service based on TwiceAsNice will have. Figure 17: Schematic of the basic state machine and interfaces of an application based on TwiceAsNice. An additional feature of this software package is a generic GUI application, which displays any parameter of the distributed database. Simple engineering interfaces to monitor data or interface with any hardware can be built by configuring the database. An example screenshot is shown in Figure 18. 9.1.2 Basic Devise Driver Application (BASDA) BASDA provides an generic library to built hardware services based on TwiceAsNice. It has four layers: Assemblies: This is the real hardware and its delivered driver libraries. Devices: The device layer interfaces the hardware to the generic BASDA Service layer. Services: This layer makes the hardware distributor independend. Four type of Services are identified. Any software above the Service layer has not to be changed, when i.e. a different motor controller is used. Applications: This layer contains the instrument specific software. An application programmer has no more to think about how to communicate with a certain hardware from a certain vendor. I.e. for a motor the interface is always the same doesn’t matter what kind of controller is used. Altogether four device types have been identified and implemented so far. This might extend with time. Vino, contains all types of cameras and readout electronics. Mocca, supports all kind of motor controller and devices. I/O, collects I/O devices like D/A boards etc. Tempo, implements monitoring devices like temperature sensor controller, etc. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 40 of 65 Figure 18: Example screenshot of the generic database interface of TwiceAsNice, Dr. Greenthumb. Figure 19: Structure of the BASDA software layer. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 41 of 65 9.1.3 Status and GUI Each module should include an engineering GUI to control the modules functionality. Each package should have a GUI to operate the important subsystem tasks. Details on status and GUI will be described deeper in the next phase of the project. At the current stage it is too early to show prototypes. However to get an impression of the style and kind of GUI one can expect we refer to [AD 24]. All parameter, which are public or configurable are normally available through the common software to everyone. The update on the parameters should be asynchronous to avoid heavy network load through polling. Status displays should provide the essential information. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 42 of 65 9.2 Laser and Launch System Software (LLS) The LLS software will have two sub-packages: the laser system and the launch system; each of them consisting of several modules. 9.2.1 Laser system modules (LAS) The LAS controls the components of the laser system. The class diagram in Figure 20 shows the outline of the structure. The functionalities of the modules are described in the following paragraphs Figure 20: Class diagram of the Laser System. Laser ctrl (LASCTRL): The laser control module takes care of switching the laser on and off, adjusts the power remotely and moves the shutter in and out. There will be one instance of this module for each eye. Master clock (LASCLK): The master clock synchronizes the laser gating. This is done electronically. The delay time and frequency of the pulse signal can be defined. The master clock can be switched off but in this case it still must be possible to take images with the WFS CCD for engineering purposes. Therefore the Pockels cells must be set in a way that the light can pass and is not blocked. There will be only one instance of this module for both eyes. 9.2.2 Launch system modules (LAN) The LAM controls the components of the launch telescope. The class diagram in Figure 21 shows the outline of the structure. The functionalities of the modules are described in the following paragraphs Launch ctrl (LANCTRL): The launch control will coordinate the hardware of the launch system on a higher level. It will receive the commands and dispatch them to the corresponding modules. Polarization (LANPOL): Each laser has one L/2 plate and one L/4 plate in front. After commissioning the polarizer should only be moved rarely for re-adjustment. It might be necessary to use them to compensate flexure introduced polarization changes. The stages have to be moved relatively to previous positions. Direction and amount of movement is related to the return flux measured on WFS detector. There is no © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 43 of 65 automation planned. The stages are moved via GUI, while measuring the return flux with the WFS. Therefore the WFS display should show the average flux of an image. There will be one instance for each polarizer rotation stage, altogether 6 per eye. Periscope (LANPTT): The separation of the lasers and their individual position to each other can be steered via two tip tilt mirrors. Input from the field and pupil imager is used to tilt the mirrors correctly. The stages have to be moved relatively to their current position. The adjustment should be automatic and in closed loop but with low frequency to compensate flexure or initial setup. LANPTT does only receive move commands and will have no calculation algorithms included. The measurement and calculation for this closed loop will be handled in the field diagnostic module (LANFLD). The separation of the lasers is set with the preset command or defined interactively by the TO, if it differs from some default value. There are 6 instances of the module per eye. Launch pupil mirror (LANPUM): The launch pupil mirror can change the position on sky of all lasers of one side together. It will get the information off-loaded from the WFS. The stage will only move relative to the current position. There is one instance of the module per eye. Focus (LANFOC): The focus unit adjusts the altitude on sky. The laser focus has to be conjugated to the image plane of the WFS. Therefore input from the WFS is needed. The same focus distance has a different altitude when changing elevation. The altitude should be adjusted for each new pointing and during very long observations on the same target. Input on the elevation is needed as well as coordination with the WFS. All this should not happen during an exposure but in-between. This thus requires knowing if the instrument is currently taking an exposure. All this coordination and intelligence could be in the LANCTRL module. The focus module would just receive relative movement commands. There is one instance of the module per eye. Figure 21: Class diagram of the launch system. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 44 of 65 Pupil diagnostic (LANPUP): The pupil diagnostics consist of a CCD on which the pupils of the laser guide stars are re-imaged. The pupil diagnostic is needed during assembly and just for monitoring during operations. There is no feedback and interaction with other modules or packages needed. A display to look at the images with some buttons to change exposure time and start/stop exposure should be enough. There is one instance per telescope eye. Field diagnostic (LANFLD): The field diagnostic consists of a CCD where all the laser guide stars of one eye are re-imaged. It will be used to adjust the individual separation of the laser guide stars as already described with the periscope module. The LANFLD will just take the images and send them to the LANCTRL, which then evaluates them and defines the new actions. Simple interfaces to browse images and set camera parameters are needed. There will be one instance of the module per eye. Alignment source (LANCAL): The alignment source is used during assembly of the launch system and later to check the alignment. It consists of one stage which might later also be used to feed the system with an on-axis sodium laser. The stage has to move to a named position and the source has to be switched on and off. There will be one instance of this module per eye. 9.3 LGS Wavefront Sensor System Software (LGSW) The LGSW runs the components of the LGS wavefront sensor. The class diagram in Figure 22 shows the outline of the structure. The functionalities of the modules are described in the following paragraphs. Figure 22: Class diagram of the LGSW. Wavefront sensor ctrl (LGSWCTRL): The WFS control will coordinate all modules and hardware devices of the LGS WFS sensor. It will receive commands from a higher level and dispatch them to the corresponding modules of the WFS. There is one instance of this module per eye. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 45 of 65 Detector ctrl (LGSWDET): The detector control module controls the WFS detector. Images can be displayed; binning and exposure time can be defined. In closed loop the readout is externally triggered by the master clock. There is one instance of this module per eye. Pockels cell (LGSWPOC): The Pockels cells are driven by the master clock, which defines when light might pass or is blocked. Within the module the voltage range can be set and the cells can be switched on and off. In engineering mode it must be possible to overwrite the master clock and create a non-blocking condition in which the detector gets light independent of the master clock. There are three instances of this module per eye. Field lens (LGSWFLE): The field lens adjusts the pupil position of each laser return on the lenslet array. The lens has to be moved within the focal plane - XY movement. The movement is relative to the current position, but it must also be possible to set the lens to an absolute position. The LGSWFLE does only receive move commands and will have no calculation algorithms included. A closed loop is established with the LANCTRL, which calculates the relative offset from monitoring the intensity of the outer subapertures of the LGSWDET image. There will be three instances of the module per eye Focus (LGSWFOC): The focus stage adjusts the image on the WFS detector. It is necessary to be able to move relative to the current position, but also to move to an absolute position. The module gets commanded either by a higher-level module or through a GUI by the operator. There is one instance of this module per eye. Periscope (LGSWTT): A periscope system of two folding mirrors is used for field selection. The tilt measured on the LGS-WFS detector is feed back through a serial line into this module and then applied to the folding mirrors to compensate for fast image motion. The slow image motion due to flexure is feed back from the patraol camera. There is one instance of the module per laser, altogether three per eye. Patrol Camera (LGSWPCAM): The patrol camera consists of a CCD where the laser guide star return of is re-imaged. There will be for each LGS one patrol camera. The cameras will be used to adjust the postiton of the laser guide stars as already described with the periscope module. The LGSWPCAM will just take the images and send them to the LGSWCTRL, which then evaluates them and defines the new actions. Simple interfaces to browse images and set camera parameters are needed. There will be three instances of the module per eye. BCU ctrl (LGSWBCU): The BCU computes the slopes and sends them to the ASM. This local control unit has an electrical interface to the LGSW detector from where it gets the images to extract the slopes. The LGSWBCU is a module to control the configuration of the BCU. It loads the configuration, which consists of the control matrix, the slope offsets, gain parameters, subaperture mapping and detector parameters like size, pixel mapping, etc. There will be one instance of the module per eye. Dichroic (LGSWDIC): The dichroic feeds the LGSW with light when inserted. It must be possible to move the dichroic to an absolute position, in and out. The module gets commanded either by a higher-level module or through a GUI by the operator. The dichroic is in the common path with the science instrument. This requires, that it must be possible to command this component even all other software is not running and the sensor is off. Internal WFS calibration unit There will be a calibration unit providing a DM and a calibration source to test the LGSW standalone. This unit will not be permanently mounted, but used in the laboratory for testing or at the telescope for © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 46 of 65 maintenance and troubleshooting. Therefore, the software is not integrated closely into the LGSW package and does not appear in the class diagram in Figure 22. DM ctrl (LGSWCDM): This deformable mirror is a MEMS based one.It will need an electronical interface to the BCU for running in closed loop. Additional software in this case will contain some diagnostics and power switch functionalities. Calibration source (LGSWCSRC): The calibration source will simply be a laser fiber fed to the focal plane. The software for this device will only need power switch functionality. It might have some remote dimming capability. 9.4 Wavefront Data Handling System Software (WDHS) The Wavefront Data Handling System software takes care of the automatic system optimization and wavefront data handling. The class diagram in Figure 23 shows the outline of the structure. The functionalities of the modules are described in the following paragraphs. The major tasks are: Data dump to disk for post evaluation Display of residual errors Display of corrected modes Display of slope vectors PSF evaluation Gain optimization Control Matrix calculation Offloading The task list shows how versatile this software has to be. In the final operation scheme most of the functions have to be automated but it must also be possible to overwrite or execute tasks manually. Data dump (WDHSDATA): The WDHSDATA gathers the wavefront data for post processing and non real-time but online reduction. The frames of the wavefront detector, the slopes and the applied voltages of each measurement are stored. In addition the current slope offset, control matrix, gains, background and flatfield is added. Time stamps built the relation between the data types and avoid duplication. With this the loop behaviour and calculations can be reproduced at any time and post-evaluated. The transfer of diagnostic data from the ASM can happen in lager packages as no hard real-time is needed. However, the transfer has to be secured and no package should be lost or block the other tasks. The diagnostic datarates are calculated in chapter 11 and the storage space needed is calculated in chapter 10. Display (WDHSDISP): The WDHS display should display all the information needed to evaluate the behaviour of the reconstruction process. Arrows with according length and direction for each sub-aperture visualize the measured slopes. A histogram shows the measured and corrected modes. A switch between Zonal, Zernike, KL or other modes should be possible independent of the mode set used in the reconstruction. A plot with the remaining residual as difference between measured slopes and corrected slopes over time gives an impression of the performance. The display of the average residual over the science exposure time or the average performance since start of the science exposure, respectively, could be shown in addition as number. This would require a feedback from the instrument with time synchronization. Alternatively one could show the average performance since start of the loop or over a fixed time period. Remaining average tip and tilt for a fixed period of time (~60s) should be displayed in an RA and DEC plot. Such plot is very useful to evaluate flexure effects. The sensor images with the SH plots © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 47 of 65 should be displayed to have an online feedback on the sensor behaviour. Displaying the data does not require the full datarate. The upper limit is defined by the typical TV update rate of 25Hz but might be much less. Experience from other systems show that 5-10Hz might be sufficient. However, the display rate should be easily adjustable by the user to adapt to his purpose. Figure 23: Class diagram of the WDHS system. Offload (WDHSOFF): The WDHSOFF evaluates data collected from the individual systems and decides to offload to other components. Up summing large strokes of atmospheric tilt applied to the ASM should be offloaded to the hexapod. Such tip tilt is only seen by the natural TT wavefront sensor and saturates the ASM. Tracking tip tilt should be offloaded to the mount. The tip tilt is seen in the launch as well as in the LGS and the TT path. Flexure of the incoming path should be compensated by the hexapod. Such effect produces a tilt signal in the LGSW and TTW but not in the launch path. Flexure in the launch path should be offloaded to the exit pupil mirror of the launch system. The TT is measured by the LGSW as common tilt. Differential tip tilt between the incoming laser beams leading to saturation of the TT steering mirrors in front of the LGSW should be offloaded to the field steering mirrors in the launch path. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 48 of 65 Gain optimization (WDHSOPT): The robustness and performance of the loop is strongly depending on the actual atmospheric condition, guide star magnitude and the noise behaviour of the system. The gain of the control loop is the parameter to adjust the system to these conditions. The gain should be selected in a way to keep the loop stable but to give an optimum performance. It should be possible to set the gain interactively, from a lookup table or to calculate it from WFS data as e.g. described in [RD 4]. The WDHSGAIN module provides automatic gain control. Therefore it needs the WFS data and command access to the control loop. The gain has to be adjusted in a time base of minutes. PSF evaluation (WDHSPSF): The PSF online evaluation from WFS data is still a subject of research but was identified as very valuable. Several publications, [RD 6], [RD 7], [RD 5] and [RD 2], discuss recent development in this field and possible schemes to implement. In chapter 9.8 we present a study of on the available methods and developed scheme how to extract the PSF from wavefront sensor data with support of additional information from other facilities like the DIMM. While that software will be provided for post processing at home a similer approach can be implemented for quick look This way, the astronomer has an immediate feedback of what can be expect from the data just taken. Control Matrix calculation (WDHSCM): The control matrix is the essential part of the control loop in an AO system. The control matrix reflexes how the DM has to respond to the measurement in the sensor. The possibility how to create an influence matrix, which is the base for a control matrix, is discussed in document [AD 13 Calibration Unit Design”. For some of the schemes the WFS data during closed loop is used, for others not. However, the sequence is the same: a. b. c. d. Peak and poke the deformable mirror actuators in a modal or zonal way Measure sensor response and save the measurement Create Interaction matrix Invert the matrix -> create control matrix In the case a calibration unit is used and the measurement is not done on sky some coordination with the calibration unit has to be implemented on a higher level. The matrix inversion could be done, e.g. offline with the script language IDL, which already has a SVD algorithm implemented. An interface to the DM to apply the peak and pokes is needed. 9.5 Tip Tilt and Truth (T3) Sensor Software The current AO system consists of two packages as described in section 8.2. The TTW corresponds to the package Wavefront Sensor of the FLAO software and will be used as it is. All functionalities provided and described in [AD 19] and [AD 25] are sufficient. Coordination with the LGSW will be handles through the AO Arbitrator. An interface to the AO arbitrator has to be built and the AO Arbitrator has to be extended in such way that the LGSW is included for LGS operation. A detailed design of the implementation will be provided with FDR. As for ARGOS FDR the FLAO system should be under commissioning, we also hope, that at that time the AO arbitrator is more stable and documented as now. 9.6 DM Diagnostic Software (DMD) The current AO system consists of two packages as described in section 8.2. The DMD corresponds to the package Adaptive Secondary Mirror of the FLAO software and will be left untouched. As described in document [AD 16] the software has three modules: housekeeping, IDLController and FastDiagnostic. In the case of the LGS operations functionality of the IDLController and FastDiagnostics might be dublicated in the WDHS system. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 49 of 65 9.7 Real-time reconstructor software (RTR) The real-time reconstruction software is located in the Basic Computational Units (BCU) of the ASM [AD 26]. The BCU use Digital Signal Processors (DSP) as processor unit. Dedicated firmware is installed on the BCU, which can be re-configured by uploading configuration parameters. The firmware has already control algorithms implemented which support modal control and filtering for different type of sensors. The implementation for a pyramid sesnor is described in [AD 26] and [AD 27] depicts the control algorithm for a SH sensor with LGS, tested at the LBT. For the initial implementation we target on a modal integrator reconstructing the modes of each sensor separately and averaging the signals in modal space. Such approach has less cross error propagation within the reconstruction process as averaging the signals already in the slope space. It also allows for spatial filtering, individal modal gains and mode projection calculated into the command matrix in advance and updated time by time to optimize the loop performance. The individual tasks of the closed loop are performed in a pipline. The computational needs and datarates between the tasks will be calculated and shown in a table at the end of the chapter. The pipline constists of following tasks: Readout Background Flatfield Slope calculation Reconstruction Set DM Readout: After readout the raw frame is provided. With Frametransfere CCDs the readout is done parallel during the exposure of the next frame and is therefore limited in length by the exposure time, or framerate repectively, but can be often much short. The readout has no calculations but starts the pipline process. The timing of the readout is the clock of the laser. Latencies between laser and CCD clocks have to be synchronized by the delay cards. Background: For each pixel a background is subtracted. The background is either defined by a fixed background matrix created with dark images in advance or dynamically defined through an average of the overscan region. Summarized in an equation with I the intensity and B the background of the pixel: pixel i: I i ,bacl I i ,raw Bi The algorithm has one operation for all pixels in a subapertur leading to 43.2KFLOP for three sensors with 15x15 subapetures and 8x8 pixel per subaperture. Flatfield: Each pixel gets divide by proportional factor equal to its linearity to normalize the pixel to pixel variations. The flatfield is defined in advance from images with different illumination of the CCD. This is done once in the laboratory and can only be repeted by dismounting the CCD from the sensor. The sensor has no flatfield calibratoin capabilities implemented. Summarized in an equation with I the instensity and F te background of the pixel: pixel i: I i , flat I i ,back / Fi The algorithm has one operation for all pixels in a subapertur leading to 43.2KFLOP for three sensors with 15x15 subapetures and 8x8 pixel per subaperture. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 50 of 65 Centroid: For each sub-aperture the individual slope in x and y direction has to be calculated. The slopes will be the input to the reconstruction of the deformable mirror shape to be applied. Each sub-aperture will have an 8x8 pixel. As initial implementation we will use a Threshold Weighted Pixel Average (TWPA) algorithm, which was shown to be stable and sufficient [Error! Reference source not found.]. An alternative could be the weighted weighted pixel average (WWPA) algorithm, which weights the each pixel with ist poisson noise. The TWPA algorithm neglects all pixels at position r with intensity I lower than a threshold for the calculation, as summariezed in following equation: sub-apertures a: I I thres I 0 rI I N than ra i N n n Correction TBD: For all pixel Ii and ri,Ii n i The thresholding is approximated with one Operation for a pixel of a subaperture leading to 43.2.KFLOP. With three sensors, each 15x15 subapertures and 8x8 pixel per subapterture, the centroiding will need about 86.4.8KFLOP. Slope calculation: The slopes of each sub-aperture has to be calculated for each LGS separately in the following way, with s the slope, r the position and x the zero position: sub-apertures a: sx ,a rx ,a x0,a , s y ,a ry ,a y0,a The slope calculation will need two operation per subapertur leading to 1.35kFLOP for three sensors with 15x15 subapertures. Reconstruction: The controller is a simple Modal Integrator reconstructing each sensor seperately and then summing the modes. Time filters and space filters can be added and are already implemented in the firmware. The reconstruction can be done with one matrix multiplication, where R is the reconstruction matrix and s is the slope vector containing the x and y slopes of all three sensors in a row. The slope offset F is removed in modal space as seen in the following equations, where the calculation from modes m to the final correction Δp to be applied is separated: mt RM st FM ,time mt 1 FM , space pt Rz mt TBD: remove temporal filter! The implementation is one matrix multiplication with a slope vector of three sensors, each two times 225 slopes resulting into the command vector of 672 actuators. This leads to 1.81MFLOP. Set DM: After applying the new DM commands it will still take some time until the actuators are settled at the requested position. This has to be taken into account into the control approach. The real-time reconstruction constraints can be summarized as shown in . The loop frequency is 1kHz. The allocated time allows for a one cycle calculation time lag and an additional for the actuator settling. Task Input Data FLOP Output © ARGOS Consortium Datarate Time Software Preliminary Design Readout 264x264/16bit Background Flatfield Centroid Slope calculation Reconstruction Datatransfere 3x15x15x8x8pix /16bit 3x15x15x8x8pix/16bit 3x15x15x8x8/16bit 3x15x15/16bit 1350B/16bit 672 actuator Doc: Issue Date Page data 1.12Mbits 140kB 43.2k/1OP 43.2kB 43.2k/1OP 43.2kB 129.6k/3OP 1350B 1.35k 1350B 1.81M 1344B - - ARGOS PDR 012 1.0 2009/02/01 51 of 65 1.12Gbit/s 140MB/s 380MFLOP/s with one BCU (217.35kFLOP) With 12 BCU 1Gbit/s 1000μs 572μs ~400μs 11μs Table 6: Summary of the RTR requirements. 9.8 PSF reconstruction software The reconstruction of the PSF at any location of the field was considered as very important for the ARGOS science cases. As such task is still a research field in progress we can not provide a detailed design at this stage but present a study we made evaluating available literature to this top. The result and a first layout what we envision is presented now. Author: D. Peter 9.8.1 Introduction Post processing of astronomical data is an important task to optimize the image quality. In this context PSF-reconstruction is the tool to improve the resolution of the image produced by an AO-system. This means the knowledge of the spatial variation of the PSF over the entire field of view is desired. With this knowledge one can then deconvolve the image with the spatially variable PSF and remove, at least partially, the speckles which are present in any image produced with an AO system. Thus the structure of the targets on the image is revealed more clearly. One classical example where this method is used are double stars or multiple systems where the companion(s) sit on the PSF of the primary maybe even closer than the diffraction limit of the telescope. So they cannot be seen directly on the image but after a PSF deconvolution the multiple nature of the target is revealed. Two basic ingredients are needed for the reconstruction: A reference PSF at one position of the image. This reference can be e.g. a bright star close to the target A method to transfere the PSF from the reference to the posistions of the other targets on the image. Classically this is done by the so called isoplanatic transfere function (see e.g. Britton 2006). There are three basic approaches to find the reference PSF for the reconstruction. One, as mentioned above, uses a reference star close to the target (see e.g RD 2). The second one uses a speckle holography method. For this approach one needs the short exposure images which add up to the final image. Due to the usual faintness of the targets and the fact that IR-detectors have a large read noise this method is much less performand. The third and last approach uses wavefront sensor data to reconstruct the reference PSF ([RD 9], [RD 5]). Due to the fact that we have three wavefront sensors and potentially not three bright reference stars in the field the second method will probably turn out to be the default process. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 52 of 65 We also cannot just copy the approaches cited above as our system has several features which are not covered within the studies found in the literature. These are: We use three guide stars. The position of the TT-star and the laser guide stars for the high order correction differ. We use lasers, which show cone effect. We only correct the lower layers of the atmosphere. These points need some additional measurement and calculation. In the following we will first shortly sketch the classical methods of PSF-reconstruction and then adress each of the additional points just mentioned. The final goal is to provide the observer with three files per image: The original image, a PSF map and a deconvolved image. Thus the observer can start with the reconstructed image provided by the observatory or do his own deconvolution. In addition it would be desireable to provide a data basis with the sets of wave front sensor data of each night. The data should be marked such that one can easily assign WFS data and image. these WFS data should also be available on request. So the observer can construct his own PSF map if wanted. 9.8.2 Classical PSF Reconstruction In this chapter the two parts of the classical approaches of PSF-reconstruction will be explained. These are: the reconstruction of the on-axis PSF from WFS data and the reconstruction of the off-axis PSF from the on-axis PSF 9.8.2.1 On-axis PSF-reconstruction from WFS data The reconstruction of the on-axis PSF has been described by [RD 9] and the algorithm has been improved later by [RD 5]. This improvement has, however, not changed the basic principle. So in the following we will just sketch the Veran paper. The basic approach is to write the OTF of the system as a product of the measured OTF, B║, the OTF of the wave front orthogonal to the measured one, B┴, and the OTF of the static non-common-path aberrations, Bs. Bs can be measured with a calibration source so in the following we will only adress the measurement of B║ and B┴. In a first step one derives the noise transfer function Hn(g,f) from the modal gains g [RD 4]. Together with the noise on the gradients one can deduce the noise on the wave front. Then, one uses the measurements of the atmospheric turbulence (Cn2) to model the atmosphere either analytically or numerically. This model then provides the statistics of the high order modes not measured by the WFS. Together with the reconstruction matrix this yields the aliasing measured on the WFS. The only missing parameter is the scale factor (D/r0)5/3. This factor can be derived iteratively using the noise on the wave front, the aliasing and the mirror shape. Thee algorithm is as follows: Start with D/r0=0. Compute σ2rr from Crr=Crr(D/r0=1),with σ2rr the mean square due to aliasing, Crr(D/r0=1) the covariance matrix of the aliasing at the position of D/r0 =1. Compute σ2a=σ2m-σ2r-σ2n∫df |Hn(g,f)|2, with σ2a the mean square of the true wave front ,σ2m the mean square of the mirror shape, σ2n the mean square of the wave front noise. Compute D/r0 by (D/r0)5/3 = σ2a/Kii for every mode i, with Kii the contribution of the mode to the wave front from Kolmogorov statistics (or statistics derived on the site). © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 53 of 65 Take the value of D/r0 and start again until convergency. Now we have the contribution of noise, the contribution of aliasing and the high order contribution not mesured by the WFS i.e. B┴. The last contribution comes fom the measured wave front error σ2w. Then using the covariances Cww, Cnn and Crr, one can compute the estimate of the true wave front covariance Ctt as Ctt=Cww-Cnn+Crr. From this one can compute B║. Putting B║, B┴, and Bs together one gets the science OTF and via FFT the PSF. The algorithm is illustrated schmatically in Figure 24. Figure 24: Classical scheme of PSF reconstruction from WFS data. 9.8.2.2 Off-axis PSF from on-axis PSF - the isoplanatic transfer function This chapter follows the paper by Britton 2006 paragraph 2. A classical AO-system measures (and corrects) a major part of the (off-axis) guide star wavefront which will be denoted by φ(r)=φa(r) +δφ(r) . Here φa(r) denotes the corrected wave front and δφ(r) denotes the residual error, r is the coordinate in the pupil plane. Thus the wave front φb of the target star is changed to the residual Δφ(r)=φb(r)-φa(r)+δφ(r). Now we calculate the structure function of the residual phase: Dδφ(r1,r2)=Dapl(r1,r2)+Dδφ(r1,r2)+2<[φ(r1)δφ(r1)+φ(r2)δφ(r2)-φ(r2)δφ(r1)-φ(r1)δφ(r2)]> The cross terms at the end are negligible. From the above expression we can calculate the OTF: OTF(r)=exp[-½Dapl(r)] x ∫ds exp(-½Dδφ(s,r+s))W(s)W(r+s) with W(r) the pupil function i.e. a step function with value 1 inside and 0 outside the pupil. The integral term is the OTF of the guide star. So any OTF can be calculated by multiplying the guide star OTF with the isoplanatic transfer function. This transfer function can be calculated using: © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 54 of 65 Dapl(r1,r2)=2 Ξk2D5/3 x ∫ 0∞dz Cn2(z){|Ωab|5/3+2 x |2/D(r1-r2)|5/3-|2/D(r1-r2)+Ωab|5/3-|2/D(r1-r2)+Ωab|5/3} with Cn2(z) the turbulence profile of the atmosphere, Ωab = (2z/D)θab the angle between the guide star and the target scaled by (2z/D), Ξ=0.458986, D the telescope diameter and k the wave number. Thus it is possible to calculate the OTF and thus the PSF of the off axis target by knowing the on-axis OTF, the turbulence profile and the angle between the target and the guide star. 9.8.3 PSF reconstruction for ARGOS As already mentioned in the introduction, in our case there are some additional challenges to solve. In the following we will do this one by one and in the end show the resulting scheme of the PSF reconstruction. As reminder we list again the four issues, which differ to the classical schemes: Finite height of laser: The system measures only the abberation in the lower atmosphere. Different angle of view for TT and HO: LGS and TTS are not measured in the same direction. Number of guide stars: Three guide stars are used for the reconstruction instead of one. Cone effect: The LGS suffer cone effects, which must be taken into account for the reconstruction. 9.8.3.1 Finite height of Laser The problem to solve is to get information on the unmeasured higher layer of the atmoshpere. If one wants to evaluate the wavefront from WFS data as stated in section 9.8.2.1 one has to split the wavefront in the part which is measured by the WFS, i.e. the modes which have been calibrated, and the part orthogonal to it. However, in the case of the laser we do not fully measure the disturbance of the atmosphere for any mode. The way to account for the turbulence not measured in the WFS is similar as in the case of a natural guide star. The only difference is how to get the missing information on the Cn2 profile. The question which must be placed at this point is: Up to which height and with how many layers do we measure the atmosphere. The answer strongly depends on the controller we use. If the approach is to use a mere averaging of the three wavefront measurements, then we can only estimate the mean height of the ground layer we correct. The part of the atmosphere, which is not corrected, starts at about the height where the laser footprints do no longer cover the entire target beam. The volume of the corrected atmosphere can be extended in height with a controller using pupil extension [RD 3]. The remaining missing contribution of the higher atmospheric layers, which are not measured, must be extracted somewhere else. DIMM data or the FLAO as truth sensor can give the information over the full atmoshpere. The lower atmosphere is extracted from the three LGS measurements using the SLODAR [RD 10] technique. A comparison between the two measurements then yields the r0 of the higher layers and that of the lower ones. With an atmospheric model we then can derive the contribution of the high atmosphere in the same way as it is done for the high order modes in the classical approach. 9.8.3.2 Different angle of view for TT and HO The problem here is that the TT mode and the high order modes are not measured in the same direction. The different angle of view makes the scheme more complex than the standard one. However, due to a correlation between Zernike modes for different directions on sky, one can project the wavefront from any direction into the science direction [see e.g. [RD 13]. There are several schemes for such calculation. The approach yielding the least error seems to be the on which projects first all three laser measurements and the TT measurements into the science direction. Then we combine the TT measurement and high order measurement following the similiar approach as above in section 9.8.3.1. Thus we have knowledge of the full atmosphere above the target. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 55 of 65 9.8.3.3 Three wave front references In the case of ARGOS we have three LGS not only one. This increases the number of calculations. The projection of all three lasers can be done simultaneously. Suppose we correct in the single guide star case N Zernike modes, then the measured wavefront x is a vector with length N, as is the applied wavefront y. So the projector is a N x N matrix with y=Px. In the case of three guide stars the measured wavefront is a vector of length 3N and thus the projector is a N x 3N matrix. Still the equation to derive the best estimate of the wavefront reads y=Px. 9.8.3.4 Cone effect Finally, in the case of LGS one has to include the cone effect, which does not appear in the NGS case of the standard scheme. The cone effect is accounted for in the calculation of the layer height from the C n2 profile. This is done in two steps: During the calculation of the correlations using the SLODAR technique, the (measured) wavefront is stretched with height, in order to account for the projection by a spherical wave and also for the change in footprint. Then, the wavefront derived will be weighted to account for the corrected height of the atmospheric layer. The weighting is strongly related to the correction hight, which depends on design of the system and the controller chosen. Figure 25 shows the PSF-reconstruction scheme as planned for ARGOS. Figure 25: PSF-reconstruction scheme as proposed for ARGOS. 9.9 Observation Preparation Software For the observation preparation software following tasks have been identified: © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 56 of 65 TT star selection Performance estimation The TT star selection will need some interaction to guide star cataloges. Such capabilities are provided in available tools like skycat [AD 29]. For the performance estimator we goal on an analytical approch similar to the one proposed for LINCNIRVANA [AD 24]. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 57 of 65 10 Computer Architecture The software is built in such way, that it runs on one machine or distributed on many. The computer architecture follows the requirement of independent and standalone systems. Therefore each of the systems, Laser Launch System and LGS Wavefront Sensor, has its own workstation to host the related software. This is duplicated, one set for each side of the LBT. With such layout each individual system can be assembled or taken to or from the telescope without interfering with the others. The T3 Sensor will use the existing AO supervising computer of the FLAO. All the workstations are located in the computer room. The real-time reconstruction runs on the dedicated Basic Computational Units (BCU) of the ASM located at the DM. The slope calculation is done in a a special LGS BCU close to the WFS. Figure 26: Layout of the computer deployment for the LBT LGS GLAO system of one eye. All workstations run a standard LINUX distibution as Operating system. The middleware and the dedicated software packages do not imply special requirements. In case of workstations LBTO suggests to use Altus server from Penguin Computing. An outline of the workstation deployment and a summary of the requirements can be found in Figure 26 and in Table 7, respectively. Table 7: Summary of computers and their minmal needs. Workstation CPU Clock LLS-WS ≥1 ≥1GHz LGSW-WS 2 RAM Cache Storage ≥16GB ≥4MB ≥200GB ≥1.9GHz ≥32GB ≥8MB ≥4.1TB Datarates <100MB/s <190MB/s © ARGOS Consortium Interfaces 2x PCI (diagnostics) 1x PCI (Master Clock) 1x Ethernet 2x Ethernet 1x PCI (diagnostics) Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 58 of 65 Table 8: Overview of computer equipment, rackspace and power consumptions of the LGS system for one side. Unit LLS-WS LGSW-WS Raid system KVM switch Network switch Sum one side/two sides Type Relion 1650/2650 Relion 1650/2650 Xyratex F5412E Raritan MCIP 8 Cisco 2960/8 Power 600W 600W 300W 20W 20W 1540W/3080W Dimension 2U 2U 2U 1U 1U 8U/16U LLS Workstation: The LLS Software has medium computational demands and no real-time requirements. One PCI slot is needed for the master clock and two PCI slots are needed for the diagnostic cameras in case of a Camera Link interface, which could also be substituted with an Ethernet interface. The datarate is expected to be less than 100MB/s (see chapter 11 Network Architecture). With 10 operations per incoming Byte the CPU clock should be 1GHz or more. The data is expected to sustain up to 10 seconds in the RAM. All this leads to a RAM larger than 10GB, usual next size is 16GB which also suggests a cache of minimal 4MB. Permanent storage of diagnostic data is not required. We assume that command data of one night and maybe diagnostic data of up to one hour full rate might be stored. This would result in about <30GB command data for an 8 hour night using an upper limit of 1MB/s on the command rate. The diagnostic data is less thant 150GB per hour. We therefore specify 200GB harddisk space as lower limit. LGSW Workstation: The LGSW workstation will host the LGSW control software and the WDHS Software. It is better to distribute this to different CPU. One PCI slot is needed for the diagnostic camera in case of the Camera Link interface. An alternative is via Ethernet. An additional dedicated Ethernet interface for the ASM diagnostics is required. The datarate will not exeed 50MB/s for the LGSW software and will be arround 140MB/s for the ASM diagnostics (see chapter 11 Network Architecture for details). This puts some demand on the internal bus system of the workstation but not unusal high for a state of the art server system. With 10 operations per incoming Byte the CPU clock should be 1.9GHz or more. The data is expected to sustain up to 10 seconds in the RAM. All this leads to a RAM larger than 19GB, usual next size is 32GB which also suggests a cach of minimal 8MB. We assume that command data of one night and maybe diagnostic of the WFS field data of up to one hour full rate might be stored. This would result in about <30GB command data for an 8 hour night using an upper limit of 1MB/s on the command rate. The WFS field diagnostic data is less than 75GB per hour. The system should be capable to store the ASM diagnostic data of one night, requiring around 4TB. We therefore specify 4.1TB harddisk space as lower limit. BCU (Real-time computer): The real-time reconstruction is done on the BCU boards of the ASM. As the reconstruction is done in modal space separately for each sensor the demand on computational power is three times larger than for the FLAO. One BCU has the computational performance of 380 Mega FLOPS [AD 26]. The raw data processing and slope calculation needs 217.35kFLOP as shown in chapter 9.7 and will/can be done one BCU. The matrix calculation will be done on the BCU at the adaptive secondary and demands 12 BCU for reconstruction to keep the one cycle time lag requirement. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 59 of 65 11 Network Architecture The network connects the computers in the control room and the devices and local computers at the telescope. Most communication within the ARGOS system has no constrains on latency, in some cases there is a quite high datarate and finally we have the real-time demands of the ASM. Therefore, we define three categories of network connection: Gigabit Ethernet for low to medium throughput with no demands on latency. Gigabit Ethernet with Quality of Service (QoS) for high throughput with no demands on latency. QoS assures the bandwidth of a domain. Dedicated Network or fiber connection for very high throughput or for communication with low latency demands. All the devices on the telescope should be remotely accessible. Most devices provide either an Ethernet connection or a Seriell connection, which gets accessed through a terminal server. A possible solution for the terminal server is the one from MOXA [Error! Reference source not found.]. Table 9, Table 10 and Table 11 show the devices of the LLS, LGSW and Cal Unit, respectively. Table 9 List of devices for the Laser and Launch System. Device Laser Laser focus stage Laser polarizer rotation stages Laser periscope TT Stages Laser diagnostic cameras Laser upgrade stage Laser shutter Launch TT stage Launch focus stage Launch TT fold mirror Launch shutter fold mirror Launch exit shutter Laser master clock Laser delay generator right-left Number 3 3 3 6 2 1 1 1 1 1 1 1 1 for both sides 1 for both sides Connection Ethernet (direct or Terminal Server) Ethernet Ethernet Ethernet Camara Link (dedicated fiber) or Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Local PC or Terminal Server Local PC or Terminal Server Table 10: List of devices for the LGS wavefront sensor. Device LGSW dichroic stage LGSW field diagnostic LGSW TT periscope LGSW focus Stage LGSW pockels cells LGSW Delay generator LGWS WFS detector BCU Number 1 3 3 1 3 1 1 1 Connection Ethernet Camara Link (dedicated fiber) or Ethernet Ethernet Ethernet Terminal Server Local PC or Terminal Server AIA to BCU and Terminal Server or dedicated fiber Ethernet + Dedicates diagnostic Ethernet © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 60 of 65 Table 11: List of devices for the CalUnit. Device White light source on-axis White light source cal unit Laser source off-axis PSD source PSD controller Swing arm motor Number 1 1 for both sides 1 1 1 1 Connection Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet The estimated data rate is collected in Table 12. The most data is produced with ASM diagnostics which results in up to 140.6MB/s, when all requested data is transferred in 1kHz. The diagnostic data does not demand real-time constraints but should be available timely, means seconds, and without data loss. We do not consider, that frames could be skipped. However, the frequency of 1kHz might be reduced in case of bandwidth problems. For the LLS and LGSW the diagnostic images are the largest contributer. The frequency of 10Hz for the launch and WFS diagnostics gives an upper limit and might be slowed down after understanding the flexure of the system better. Altogether we reach a data rate of 130.18MB/s per eye. Therefore we propose to have for each eye or the LBT separate networks and also split the LLS and LGSW in two separate domains. Table 12: Data rate estimation. Data rate of ASM diagnostics network Frame Slopes Applied Modes Actuator Position Accelerometers Number 256x264 2x 672 672 672 6 Data rate in telescope network Launch pupil diagnostic Launch field diagnostic WFS field diagnostic WFS images display Devices Number 2048x2048 2048x2048 2048x2048 256x264 42.5 Sum one side/two sides Sum ~135kB ~3kB 1.3kB 1.3kB 0.001kB 140.6kB x 1kHz = 140.6 MB/s Sum 4.2MB x10Hz = 42MB/s 4.2MB x10Hz = 42MB/s 4.2MB x10Hz = 42MB/s 135kB x25Hz =3375 kB/s 42.5x19kB/s = 807.5kB/s (100 messages of 100 Byte forth and back) 130.18/260.37 MB/s The outline of the ARGOS network architecture is shown in Figure 27. The system will have four class C networks. From the telescope to the computer room this will be virtual networks. The networks are divided as following: Network 1: LGSW network commanding the WFS and taking care of the WFS diagnostics. The network has no real-time requirements and the datarate is midium with less than 50MB/s. A fiber connection from the SCP to the LGSW cabinet is required. Network 2: ASM diagnostic network with high data throughput but no stringened real-time requirements. This network requires QoS. The ASM diagnostic network should be already installed for FLAO. © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 61 of 65 Network 3: The LLS network commanding the lasers and the launch telescope. The network has no real-time requirements but a high datarate with up to 85MB/s. Therefore, we would also require QoS for this network. At the telescope the devices of this network are distributed over the telescope at the C-Ring and the Laser Platform. From both places fiber connections to the SCP are required. Network 4: The existing FLAO network to command the T3 WFS. The bandwidth of running ARGOS on both sides in parallel results in 4.33 Gb/s. Currently the connection between telescope and computer room allows for 6Gb/s. Therefore, we conclude the existing network capabilities are sufficient. The selected switches within the LBT network environment allow for QoS. Figure 27: ARGOS network architecture scheme © ARGOS Consortium Software Preliminary Design Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 62 of 65 The real-time communication from the slope BCU to the ASM will have a dedicated fiber. The sensor will be selected with the switch BCU placed close to the ASM (not shown in Figure 27). A dedicated serial line from the FLAO BCU to the LGS BCU is needed for the asynchronious TT command. Table 13: Summary of the requirements to LBT. Domains Domain-IP LGSW domain SX LGSW domain DX LLS domain SX LLS domain DX T3 domain SX T3 domain DX ASM diagnostic domain SX ASM diagnostic domain DX TBD by LBT TBD by LBT TBD by LBT TBD by LBT TBD by LBT TBD by LBT TBD by LBT TBD by LBT Band width 1GB/s 1GB/s 1GB/s 1GB/s 1GB/s 1GB/s 1GB/s 1GB/s #port Dedicated fibres Comments 1 1 2 2 1 1 1 1 QoS QoS From FLAO From FLAO From FLAO From FLAO Possible up to 2 (=1 pairs) Possible up to 2 (=1 pairs) Possible up to 4 (=1 pairs) Possible up to 4 (=1 pairs) none none none none © ARGOS Consortium Software Preliminary Design APPENDIX (1): List of acronyms AGN AGW AIA AIP AIT AIV ALFA AOA AOS APD ARIES ASM BCU BH BLINC CAAO CAHA CAOS CCD CONICA CSW CUS CW DIMM DIQ DM DMD DSP ECSS E-ELT EMCCD ESO FAA FLAO FOROT FOV FPGA FTE FWHM GLAO GLAS GS GSAOI HLL HST HVR ICD IDL IEC Active Galactic Nuclei Acquisition Guiding and Wavefront sensing Automated Imaging Association Astrophysical Institute Potsdam Assembly, Integration and Testing Assembly, Integration and Verification Adaptive optics with a Laser For Astronomy Adaptive Optics Arbitrator Adaptive Optics System Avalanche Photo Diode Arizona infraRed Imager and Echelle Spectrograph Adaptive Secondary Mirror Basic Computational Unit Black Hole Bracewell Infrared Nulling Cryostat Center for Astronomical Adaptive Optics Centro Astronómico Hispano Alemán Code for Adaptive Optics Systems Charged Coupled Device COudé Near Infrared CAmera Common SoftWare Calibration Unit Software Contiunious Wave Differantial Image Motion Delivered Image Quality Deformable Mirror Deformable Mirror Diagnostics Digital Signal Processor European Coorperation on Space Standardization European - Extremely Large Telescope Electron Multiplied CCD European Southern Observatory Federal Aviation Administration First Light Adaptive Optics Forecast Optical Turbulence Field of View Field Programalbe Gate Array Full Time Equivalent Full Width Half Maximum Ground Layer Adaptive Optics Ground layer Laser Adaptive optics System Guide Star Gemini South Adaptive Optics Imager HalbLeiterLabor, Max-Planck-Institute semiconductor laboratory Hubble Space Telescope High Vertical Resolution Interface Control Document Interactive Data Language International Electrotechnical Commission © ARGOS Consortium Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 63 of 65 Software Preliminary Design IIF ILT IMF INAF ING IPC IR IRCAL ISAAC LBC LBT LBTB LBTC LBTI LBTO LCSW LCU LGS LGSF LGSW LINC LL LLNL LLS LLT LMC LSW LUCIFER MAD MAIT MCAO MIRAC MIT MMT MODS MOU MPE MPG MPI MPIA NACO NAOS NGS NICMOS NIF NIFS NIR NIRI NIRSPEC NIRVANA NOAO OSIRIS PA PAH PCI PHL Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 64 of 65 Instrument InterFace Instrument Level Test Initial Mass Function Istituto Nazionale di Astrofisica Isaac Newton Group Inter Process Communication InfraRed IR Camera for Adaptive optics at Lick Infrared Spectrometer And Array Camera LBT Camera Large Binocular Telescope LBT Beteiligungsgesellschaft Large Binocular Telescope Corporation LBT Interferometer LBT Observatory LGS Common SoftWare+B112 Local Computational Unit Laser Guide Star LGS Facility LGS Wavefront Sensor LBT Interferometric beam Combiner Laser Launch Lawrence Livermore National Laboratory Laser Launch System Laser Launch Telescope Large Magellanic Cloude LandesSternWarte LBT Near Infrared Spectroscopic Utility with Camera and Integral Field Unit for Extragalactic Research Multi conjugated Adaptive optics Demonstrator Manufacturing, Assembly, Integration and Testing Multi Conjugated Adaptive Optics Mid-Infrared Array Camera for Astronomy Massachusetts Institute of Technology Multi Mirror Telescope Multi-Object Double Spectrograph Memorandum of Understanding Max-Planck Institute for Extraterrestric Max-Planck Gesellschaft Max-Planck Institute Max-Planck Intitute for Astronomy NAOS CONICA Nasmyth Adaptive Optics System Natural Guide Star Near Infrared Camera and Multi-Object Spectrometer Near-Infrared Integral-Field Spectrograph Near InfraRed Near InfraRed Imager Near Infrared Spectrograph Near-IR / Visible Adaptive INterferometer for Astronomy. National Optical Astronomy Observatory OH-Suppressing InfraRed Imaging Spectrograph Product Assurance Polycyclic Aromatic Hydrocarbons Peripheral Component Interconnect Preliminary Hazard List © ARGOS Consortium Software Preliminary Design PID pnCCD PO PSF PW PXI QA QSO RCO RLGS RMS RON RPC RTC SAM SCAO SCIDAR SDSS SDT SFR SH SINFONI SMBH SMT SNR SOAR SOR SR STIS STScI SVD TBC TBD TCS TMT TRE TT TTW UA UKIDSS UMAC UNISIS VATT VLT WDHS WFS WHT WIYN Proportional, Integral and Differential the very fast high-resolution radiation detector of the HLL Project Office Point Spread Function Pulsed Wave PCI eXtensions for Instrumentation Quality Assurance Quasi Stellar Object Radiation Control Office Rayleigh Laser Guide Star Root Mean Square Read Out Noise Remote Procedure Call Real Time Control SOAR Adaptive Module Single Conjugated Adaptive Optics SCIntillation Detection And Ranging Sloan Digital Sky Survey Science Demonstration Time Star Formation Rate Shack Hartmann Spectrograph for INtegral Field Observations in the Near Infrared Super Massive Black Hole Sub Millimeter Telescope Signal to Noise Ratio Southern Astrophysical Research Starfire Optical Range Strehl Ratio Space Telescope Imaging Spectrograph Space Telescope Science Institute Single Value Decomposition To Be Confirmed To Be Defined Telescope Control Software Thiry Meter Telescope Test Review Europe Tip Tilt Tip Tilt Wavefront sensor University of Arizona United Kingdom Infrared Deep Sky Survey Universal Motion and Automation Controller University of Illinois Seeing Improvement System. Vatican Advanced Technology Telescope Very Large Telescope Wavefront Data Handling WaveFront Sensor William Herschel Telescope Wisconsin Indiana Yale & NOAO End of document © ARGOS Consortium Doc: Issue Date Page ARGOS PDR 012 1.0 2009/02/01 65 of 65