ps1 pordig meeting, nov 21 2008 ● observatory, telescope, and instrument software (otis) ●...
Post on 14-Dec-2015
212 Views
Preview:
TRANSCRIPT
PS1 PORDIG Meeting, Nov 21 2008
● Observatory, Telescope, and Instrument Software (OTIS)
● Remote Operations
● Survey Efficiency
● Scheduler and Simulated Design Reference Mission
PS1 PORDIG Meeting, Nov 21 2008
Observatory, Telescope, & Instrument Software -
OTIS
Observatory, Telescope, & Instrument Software -
OTIS
The PS1 System
Gigapixel Camera
Gigapixel Camera
PS1 TelescopePS1 Telescope
Image Processing
Pipeline - IPP
Image Processing
Pipeline - IPP
Published Science Producs
System - PSPS
Published Science Producs
System - PSPS
Moving Object Processing System - MOPS
Moving Object Processing System - MOPS
PS1 Science Consortium Members
PS1 Science Consortium Members
Science Analysis Servers
Science Analysis Servers
Solar System Community
Solar System Community
raw images
photonscommands and feedback
metadata
detectionsstatic sky images
detections detections, metadata
orbits identifications
static sky images reduced data products
reduced data products
detections, metadatadetections, metadata
PS1 PORDIG Meeting, Nov 21 2008
Observatory, Telescope, and Instrument Software (OTIS)
● Collection of software tools for – GUI point & click remote control of PS1 observations– Configurable speech synthesis for audible alerts– Maintaining a configurable collimation model– Maintaining a configurable focus model– Fitting a mount model– Monitoring external and internal environment– Logging commands and sensor data in database– Tool for querying and plotting metadata in database– Queue execution of observations– Tools for scheduling the Design Reference Mission– Tools for simulating the Design Reference Mission
● Approximately a quarter of a million lines of Java code, plus ancillary items.
PS1 PORDIG Meeting, Nov 21 2008
OTIS Status
● Extensive use of OTIS at the summit for control of the Observatory, Telescope, GPC Camera, and other instrumentation.
● Regular remote use of OTIS from a variety of remote sites. Only difference between remote and summit operations is network connectivity.
● Modest testing of network connectivity from ATRC to summit.
● Lots of minor issues and irritations to be resolved
● Functionality is currently sufficient for trained Observers to carry out the remote observations necessary for the PS1 Design Reference Mission (as distinguished from remote operations including catastrophic failure modes)
PS1 PORDIG Meeting, Nov 21 2008
Outstanding issues for Remote Operations:
● Remote start-of-night/end-of-night capability– Dome Azimuth drive (warming procedure or mitigated)– Dome leaks sealed, so no water on ring wall– Dome vent 3 fixed
● Faults that require trip to the summit– Camera shutter reset (extremely rare)– Dome Azimuth Master Drive fault (rare)– Dome Azimuth Limit switch (Az drives not warm,
mitigate mechanically or thermally)
● GPC Camera – demonstrated self protection software– Not protected against all possible network failures– Warm up – 24 hours, pump and cool– Helium Compressor – not on UPS, most on MK are
not. Power failure means Camera pump-down, loss of observing time.
PS1 PORDIG Meeting, Nov 21 2008
Outstanding Issues for Remote Operations, Con’t
● Functionality/procedures for “catastrophic” failures
– Summit Power failure:● Have dome shutter and vents on UPS.● Need RPS for TCC Computer (RPS to power down and boot)
– Network failure (link to summit)● Phone line modem to otis computers needs work and procedures
– Major Mechanical Failure (e.g. Main Dome Shutter)● Need tarps to cover telescope/camera and procedure for doing so.
PS1 PORDIG Meeting, Nov 21 2008
Outstanding Issues for Remote Operations, Con’t
● Multiple catastrophic failures:
– Mechanical Failure & Power Failure● Need altitude break switch on UPS so telescope can be
moved by hand for Mechanical Failure Procedure
– Power Failure and Network Failure● Same as Power and Network Failure independently
– Communication and Mechanical Failure● Same as Mechanical Failure alone
PS1 PORDIG Meeting, Nov 21 2008
Outstanding Issues for Remote Operations, Con’t
● Spares for single point failure
– Air Compressor– Spare Telescope Computer and cards– Spare Dome Computer and cards
PS1 PORDIG Meeting, Nov 21 2008
Surveying Efficiency Sept 14 to Nov 19, 2008
● Science Time (science time)/(clear time) 22.6%● Engineering Time (engineering time)/(clear time) 45.3 %● Downtime (downtime)/(clear time)
– Telescope 0.6 %– OTIS 2.6 %– Camera 1.2 %– Unaccounted (Idle or head scratching) 27.7 %
---------
100.0 %
● System Reliability 95.6%
● Weather (percent closed due to bad weather) 17.7 %● Note: during fall used a lot of time with cirrus ● 3 yr average bad weather time ~25%
● Observing Efficiency (Science Observations)– (exposure time)/(science clear time)
59.7%
PS1 PORDIG Meeting, Nov 21 2008
Current and future observing overheads● Time spent focusing in Nov ~ 5%. Hope to reduce this to near zero using science image psf ellipticity ● Camera overhead as per Sidik and Erik: Now Soon
0.3 0.0 OTIS-cam network comm? Guide star lists? ??? 0.3 0.1 Camserv processes guide list 5.3 0.0 Clean 5.2 0.1 Setting up video threads (ssh, launching commands) --- --- integration time 1.0 1.0 shutter blade moving. (now at t=42.1) 1.8 0.0 video overrun and shutter comms. delay (*) 0.4 0.1 video script overhead (waiting to collect thread status) 7.1 0.0 expose script or shutter driver overhead before readsave starts ... 0.4 0.1 readsave startup script overhead 6.4 6.4 detector limited 2.0 usec/pix readout with overscan 0.2 0.2 additional overscan for row-by-row bias correction 0.3 0.0 controller memory clearing, etc. 4.5 0.9 network transfer and some readsave script overhead -- 4.3 clean moved to end (and started during 0.9 sec of network overhead) 0.9 0.0 additional readsave script overhead==== ====34.1 13.2 total overhead (any length exposure time.)
(*) Assuming we change the way we talk to the shutter.
34.1 overhead on a 30s exposure = 47% camera efficiency13.2 overhead on a 30s exposure = 69% camera efficiency
Note: We are currently slewing as soon as shutter closes (during read) so these gains would only be realized for slews less than 13.2 sec.
PS1 PORDIG Meeting, Nov 21 2008
Scheduler
● A simulation of 3.5 year PS1 Mission was done for the Design Reference Mission with the “python” scheduler, a modified version of the LSST cadence simulator.
● The Otis Scheduler is based on a direct implementation of the PS1 Survey Strategy, together with a high fidelity predictive model of the PS1 telescope and camera, and relies on the Survey Strategy plus visibility constraints to present choices interactively to the Observer.
● When run non-interactively it serves as a simulator of the PS1 Mission. It can access either the real Otis database or a simulated database.
● The Otis scheduler is much better at achieving survey completeness, the TTI cadence, and reducing idle time than the “python” scheduler. However at present when run robotically the pairwise and triplet cadencing is unsatisfactory.
● Outstanding robotic scheduler issues include moon avoidance at opposition near full moon in the 3pi i-band survey, completeness in g-band, and achieving TTI pairs and triplets with high completeness.
PS1 PORDIG Meeting, Nov 21 2008
OTIS Scheduler – Robotic Simulation of 1yr of DRM
PS1 Surveys Percent Percent of survey of survey
completed completed
(otis, sim7) (DRM_v3)
– 3pi Steradian 96% 89% – Medium Deep Fields 89% * 32%– Solar System “Sweet Spot” 92% 110% – Deep Survey of M31 49% 32% – Stellar Transit Survey 97% 32%
– Total Completeness 94.3% 74.9%– Percent of clear time idle 5.7% 25.1%
PS1 PORDIG Meeting, Nov 21 2008
OTIS Scheduler – Simulation of 1yr of DRM
otis python PS1 Surveys Percent sim7 DRM_v3
allocated distribution distribution
– 3pi Steradian 58% 60.4% 62.3%– Medium Deep Fields 25% 29.1% 12.5%– Solar System “Sweet Spot” 5% 5.4% 9.6%– Deep Survey of M31 2% 1.0% 0.6%– Stellar Transit Survey 4% 3.9% 2.0%– Discretionary 6% 0.2% 0.0%
top related