Large Synoptic Survey Telescope (LSST) Observatory System ... 1.pdfThe contents of this document are subject to configuration control and may not be changed, altered, or their provisions

LSST Observatory System Specifications LSE-30 Latest Revision 02/12/2014

The contents of this document are subject to configuration control and may not be changed, altered, or their provisions waived without prior approval of the LSST Change Control Board.

1

Large Synoptic Survey Telescope (LSST)

Observatory System Specifications

Chuck F. Claver and the LSST Systems Engineering Integrated Project Team

LSE-30

Latest Revision Date: February 12, 2014

Latest Version: 4.1

This LSST document has been approved as a Content-Controlled Document. Its contents are subject to

configuration control and may not be changed, altered, or their provisions waived without prior

approval. If this document is changed or superseded, the new document will retain the Handle

designation shown above. The control is on the most recent digital document with this Handle in the

LSST digital archive and not printed versions.


The contents of this document are subject to configuration control and may not be changed, altered, or their provisions waived without prior approval.

i

Change Record

Version Date Description Owner name

1 5/23/2011 Initial draft for configuration control. Review comments and actions taken in this draft are found in Document-11071.

Chuck Claver

2 5/26/2011

Updated type and clarifications per May 25, 2011 CCB meeting. Affected requirements: OSS-REQ-0010, 0014, 0051, 0064, 0314, 0083, 0084, 0092, 0108, 0239, 0253, and 0259.

C. Claver

10/15/2012 LCR-88; changes OSS-REQ-0267 (page 95), the system pixel noise from 10e- to 1.7e- per pixel visit.

C. Claver

10/15/2012 LCR-103; Establishes new requirements for crosstalk amplitudes and correction OSS-REQ-0327-0330, 0346-0349 (pg 91-94)

C. Claver

10/15/2012 LCR-86; Complete refactoring of photometric requirements (pg 97-102, 104)

C. Claver

10/15/2012 LCR-84; Updates filling in TBDs in level 1 (pg 46-48) and level 2 (pg50-54) data quality metrics

C. Claver

10/15/2012 LCR-113; Updates to EMI/Rfi requirements (pg 32) C. Claver

3 2/14/2013 LCR-85; Redefinition of the seismic design criteria (pg 3, 9-10, 33)

George Angeli

4 10/8/2013

Incorporates all changes approved via LCRs 133, 145, 146, 148, and 153 and all amendments made to those LCRs by the CCB during the meetings held 10/2/2013 and 10/8/2013

B. Selvy

4.1 2/12/2014

Incorporates changes approved in LCR-166 regarding changing the reference to Document-8123 to LSE-180 in the Discussion of OSS-REQ-0194. Incorporates all changes approved in LCR-168 regarding barometric pressues in OSS-REQ-0010.

B. Selvy



ii

Table of Contents

Change Record ............................................................................................................................................... i

Introduction and Scope ................................................................................................................................ iii

Supporting Documents ................................................................................................................................ iii

1 System Composition and Constraints .................................................................................. 1

1.1 Facilities .................................................................................................................................. 1

1.2 Sites ......................................................................................................................................... 2

2 Common System Functions & Performance ..................................................................... 10

2.1 Survey Scheduling and Management ........................................................................... 11

2.2 System Control ................................................................................................................... 13

2.3 System Monitoring & Diagnostics ................................................................................. 19

2.4 System Maintenance ......................................................................................................... 25

2.5 System Availability............................................................................................................. 27

2.6 System Time Reference .................................................................................................... 28

2.7 System Standards .............................................................................................................. 28

3 Detailed Specifications ............................................................................................................ 33

3.1 Science and Bulk Data ...................................................................................................... 33

3.2 Optical System .................................................................................................................... 55

3.3 System Throughput ........................................................................................................... 67

3.4 Camera System ................................................................................................................... 80

3.5 Photometric Calibration .................................................................................................... 85

3.6 System Timing and Dynamics ........................................................................................ 93

3.7 Education and Public Outreach ...................................................................................... 98



iii

The LSST Observatory System Specifications

Introduction and Scope

This Observatory System Specifications document describes the functional and performance requirements and allocations needed to fulfill the system functionality and survey performance described by the LSST System Requirements Document (LSE-29). These specifications include those derived from the following activities and/or modeling tools:

the reference system architecture consisting of 4 principle sites - summit, base, archive and headquarters

the selection of the summit site on Cerro Pachón;

the modeling the dynamic survey performance with the LSST Operations Simulator;

the optical design optimization;

the point source SNR analysis of the system throughput

In addition to the system specifications this document also includes required codes and regulations covering safety, construction, and other engineering standards.

Supporting Documents

LSST Science Requirements Document (LPM-17)

LSST System Requirements (LSE-29)

LSST Systems Engineering Management Plan (LSE-17)

LSST Change Control and Configuration Management Plan (LPM-19)

LSST Risk Management Plan (LPM-20)



1

The LSST Observatory System Specifications

1 System Composition and Constraints The LSST system will consist of facilities constructed at several sites in Chile and the United States. In this section we enumerate the planned facilities and their functions. The data processing functions at these facilities are further divided into "Centers" -- collections of closely related activities. We specify the choice of the physical sites used for the system design. These choices imply specific constraints that impact the system requirements and design. The specific sites drive system architecture and connectivity specifications. The choice of the summit site, and the subsequent agreement with Chile, also determines particular requirements on the system components that are provided. The LSST summit site selection process resulted in the choice of Cerro Pachón in Chile for the location of the observatory itself. The weather and astro-climate (seeing and cloud cover) of Cerro Pachón provide system constraints under which the survey design requirements must be met which in turns drives certain system specifications.

1.1 Facilities ID: OSS-REQ-0001

Last Modified: 4/21/2011

Specification: The LSST Observatory shall be designed using the following four facilities; Summit Facility. Base Facility, Archive Facility, and Headquarters Facility. These are described below.

1.1.1 The Summit Facility ID: OSS-REQ-0002


Specification: The LSST shall provide a "Summit Facility" to host the following functions and their associated maintenance activities: 1. Collection of the science data for the survey; 2. Collection of additional data required for photometric calibration; and 3. Control of the Observatory. Discussion: The Summit Facility includes the main telescope and its enclosure, camera service areas, mirror coating systems, the auxiliary telescope and its enclosure, utility equipment, and all other infrastructure necessary to safely execute all the functions above and secure all LSST assets located on the summit. Summit Facility also must provide the space and functional equipment to safely maintain all the system assets operating on the site.

1.1.2 The Base Facility ID: OSS-REQ-0003


Specification: The LSST shall provide a "Base Facility" to host the following functions and their associated maintenance activities: 1. The Primary Remote Observing facility to assist in the control of the Observatory; 2. Survey planning and performance monitoring; 3. Collection of newly acquired data for transfer to the LSST data archive;



2

4. Backup of all data - raw, engineering, and derived products; 5. Host Country Data Access Center, as defined below; and 6. Control of Data Management operations (secondary location). Discussion: The Base Facility may be a single structure or a series of co-located buildings that provides the personnel offices, computer equipment, and other specialized infrastructure necessary to safely execute all the functions above and to secure all LSST assets located at the Base.

1.1.3 The Archive Facility ID: OSS-REQ-0004


Specification: The LSST shall provide an "Archive Facility" to host the following functions: 1. Ingest and daily reprocessing of all raw science data; 2. Archiving of all data - raw, engineering, and derived products; 3. Data Release Production; 4. Calibration Product Production; 5. Moving Object Production; 6. United States Data Access Center; and 7. Data Management Operations (secondary location). Discussion: The Archive Facility includes the personnel offices, computer equipment, and other specialized infrastructure necessary to safely execute all the functions of the listed Centers and to secure all LSST assets located at the Archive.

1.1.4 The Headquarters Facility ID: OSS-REQ-0005


Specification: The LSST shall provide a "Headquarters Facility" to host the following functions: 1. Survey planning and performance monitoring; 2. Management of community science input; 3. Overall Observatory and project administration; 4. Education and Public Outreach; and 5. Data Management Operations Center Discussion: The function of Observatory and project administration includes the activities of a director, technical manager, business manager, and human resources, and covers all matters of compliance and reporting, interface to funding agencies, and management of the overall LSST Observatory and its operations world-wide. The functions of Education and public outreach include the development of K-12 curricula, citizen science programs, and the necessary serving of LSST data to educators and the general public through a dedicated Data Access Center within, or in close proximity to, the Headquarters facility. The Headquarters Facility includes the personnel offices, business equipment, and other specialized infrastructure necessary to safely execute all the functions above and to secure all LSST assets located at the Headquarters.

1.2 Sites ID: OSS-REQ-0006 Last Modified: 9/15/2010



3

Specification: The LSST Observatory system shall be designed to safely meet its technical requirements and operational specifications with the above-defined Facilities constructed at the following physical locations ("Sites"): 1. Cerro Pachón in Chile for the Summit Facility; 2. The AURA Recinto in La Serena, Chile for the Base Facility; 3. The National Center for Supercomputing Applications (NCSA) in Urbana-Champaign, IL for the Archive Facility; and 4. A continental U.S. site for the Headquarters Facility.

1.2.1 Chilean Summit and Base Sites ID: OSS-REQ-0350


1.2.1.1 Summit Site

ID: OSS-REQ-0007


Specification: The LSST observatory Summit Facility shall be located within the AURA property on Cerro Pachón (El Peñón), Chile, and shall meet all requirements for survey performance and operations at that site. All other functions of the Summit Facility shall be compatible with the defined weather, access, seismic and other site conditions provided below.

Summit Geographic Definitions

ID: OSS-REQ-0008


Specifications: When design considerations require the specification of the summit site location, the following definitions for elevation, latitude, and longitude shall be used: Description Value Unit Name

The operational summit elevation to be used for design purposes is summitElevation.

2650 Meters summitElevation

The operational site latitude to be used for design purposes is summit Latitude.

-30.2444 Degrees summitLatitude

The operational summit longitude to be used for design purposes is summitLongitude.

-70.7494 Degrees summitLongitude

Summit Environment

ID: OSS-REQ-0009


Specification: All systems operating at the Summit Facility exposed to the external environment (includes the dome interior) shall meet all their functional and performance specifications for the Normal site conditions, shall operate in defined degraded modes under the Marginal conditions, and withstand without damage the non-operational Survival conditions provided below.

Normal Operating Conditions

ID: OSS-REQ-0010 Last Modified: 12/1/2010



4

Specification: The equipment and systems exposed to the external environment at the Summit Facilities shall meet all of their functional, performance, and operational specifications for the normal environmental conditions specified in the table below. Discussion: These conditions correspond to the ~90% to 95% values of the weather distribution. Description Value Unit Name

The mean temperature for normal operations at the summit shall be normTempMean.

11.5 Celsius normTempMean

The minimum temperature for normal operations at the summit shall be normTempMin.

-3.0 Celsius normTempMin

The maximum temperature for normal operations at the summit shall be normTempMax.

19.0 Celsius normTempMax

The rate of change for design purposes shall be normTempGrad.

0.7 C/Hour normTempGrad

When design considerations require operational wind specifications all summit based systems shall use the extreme operational wind speed, normWindMax.

12 m/sec normWindMax

When design considerations require humidity specifications all summit based systems shall use the normal maximal operational relative humidity (non-condensing) normHumidityMax

90 Percent normHumidityMax

When design considerations require humidity specifications all summit based systems shall use the normal mean operational relative humidity (non-condensing) normHumidityMean.

40 Percent normHumidityMean

When design considerations require barometric pressure specifications all summit based systems shall use the mean pressure normBaroMean.

750 milibar normBaroMean

The maximum barometric pressure for normal operations at the summit shall be normBaroMax (TBR).

775 milibar normBaroMax

The maximum barometric pressure for normal operations at the summit shall be normBaroMin (TBR).

725 milibar normBaroMin

Marginal Operating Conditions

ID: OSS-REQ-0011


Specification: The equipment and systems exposed to the external environment at the Summit Facility shall be operable (not necessarily meeting all performance and functional requirements) over the range of marginal environmental conditions specified in the table below. Discussion: These conditions correspond to the ~99% values of the weather distribution. Description Value Unit Name

The temperature rate of change for degraded operations is marginalTempGradient

2.0 C/Hour marginaltempGradient

The maximum temperature for degraded operations at the summit shall be marginalTempMax.

30 Celsius marginalTempMax



5

Description Value Unit Name

The minimum temperature for degraded operations at the summit shall be marginalTempMin.

-5 Celsius marginalTempMin

The maximum free air windspeed for degraded operations at the summit shall be marginalWind.

20 m/sec marginalWind

Survival Conditions

ID: OSS-REQ-0012


Specification: The exterior of the Summit Facility and all hardware permanently located on the exterior shall be capable of surviving a constant wind speed of survivalWindExterior. All equipment and systems at the Summit Facility, when exposed to the external environment (e.g. when the dome is open) shall survive the other environmental conditions specified in the table below. Description Value Unit Name

All hardware permanently located on the exterior of the Summit Facility shall be capable of surviving a constant wind speed of survivalWindExterior.

54 m/sec survivalWindExterior

The equipment in the interior of the Summit Facility must be capable of surviving an exterior 10-second wind gust speed of survivalWindGust.

25 m/sec survivalWindGust

The equipment in the interior of the Summit Facility must be capable of surviving a constant wind speed of survivalWind.

20 m/sec survivalWind

All equipment at the Summit Facility must be capable of surviving a maximum non-condensing humidity of survivalHumidity without damage.

100 Percent survivalHumidity

All equipment located at the Summit Facility must be capable of surviving an ambient air temperature of survivalTemperature.

-10 Celsius survivalTemperature

The survival load on the Summit Facility due to snow shall be snowLoading (ref. Norma Chilena NCH 431).

200 kg/m^2 snowLoading

The survival load on the Summit Facility for ice on vertical surfaces shall be iceLoading (ref. Norma Chilena NCH 431)

22 kg/m^2 iceLoading

Transportation/Shipping Environment

ID: OSS-REQ-0013


Specification: Components of the LSST Observatory that are transported to Chile shall survive the shipping conditions described below. Discussion: The shipping environment includes the general conditions when equipment is shipped to the summit. The equipment must remain undamaged after repeated shipments. Delivery is expected to be by plane or boat to Chile and then by road to the summit. There is a tunnel on the road between the town of La Serena and the summit site on Cerro Pachon called the Puclaro Tunnel. Any equipment will have to pass through that tunnel. Its overall dimensions are given below.



6


During transportation, the effective altitude can change between sea level and 3000m.

Sea level to 2700m

Meters Altitude

The ambient temperature range or transportation to the summit is

-15C to +40C

Celsius Temperature Range

The relative humidity range is from 10% to 100% with condensation for transportation to the summit

10% to 100%

Percent Relative Humidity Range

Wind speed may reach up to 45m/s during transportation to the summit

45 m/sec Wind Speed

Pressure will change during transportation to the summit from 1000mbar at sea level down to 750mbar at the summit

1000 to 750

milibar Pressure

Containers have to be designed to limit water, dust, sand and insect access during transportation

Contamination

Dirt roads will be used during transportation to the summit with grades up to 16%

16 Percent Roads

During transportation to the summit, some roads have vehicle weight restrictions. Gross Vehicle Weight GVW = TBD Weight/axle = TBD

TBD kg GVW

The container dimensions are limited by the Puclaro Dam tunnel (see figure 7) located on the road between La Serena and the summit.

9 Meters Tunnel

Astro-Climate

ID: OSS-REQ-0015


Discussion: The selection of the summit site on Cerro Pachon implies a set of constraints relating to the astro-climate under which the survey performance requirements from the LSR must be met. These include atmospheric seeing, usable fraction of nights and cloud cover fraction, standard dark sky brightness, and standard atmospheric transparency.

Atmospheric Seeing

ID: OSS-REQ-0016


Specification: The LSST shall meet the survey performance requirements under the constraint of the atmospheric seeing on Cerro Pachon (El Penon) as specified in the table below. Discussion: The values included here are direct DIMM measurements referenced to a wavelength of 500 nm. They do not represent the integrated delivered seeing over an 8.4m aperture or include affects from the outer scale. Description Value Unit Name

The first quartile of the seeing distribution shall be taken as seeing1stQuartile

0.58 ArcsecFWHM

seeing1stQuartile

The median of the seeing distribution shall be taken as seeingMedian

0.69 ArcsecFWHM

seeingMedian

The third quartile of the seeing distribution shall be taken as seeing3rdQuartile

0.84 ArcsecFWHM

seeing3rdQuartile



7

Cloud Coverage

ID: OSS-REQ-0017


Specification: The LSST Observatory shall meet the survey specifications under the assumed weather conditions recorded at Cerro Tololo Observatory from 1975 to 2005 for cloud cover and fraction of photometric and usable nights as defined in the table below. Description Value Unit Name

The historically monthly mean available time fraction that is considered "photometric" (i.e. cloudless) shall be taken as photTimeFrac

53 Percent photTimeFrac

The historically monthly mean available time fraction that is considered usable (i.e. with clouds but observable, also called "spectroscopic") shall be taken as usableTimeFrac

85 Percent usableTimeFrac

Standard Atmospheric Transmission

ID: OSS-REQ-0018


Specification: For the purpose of evaluating the system performance and the flow down of subsystem requirements the standard atmospheric transmission shall be calculated from the USAF MODTRAN model using the reference atmospheric parameters given in the table below. Discussion: While the reference airmass is X=1, Collection-973 contains data files for other airmass values up to x=2.5. Document-3902 contains details on using MODTRAN to calculate the atmospheric transmission functions. https://www.lsstcorp.org/docushare/dsweb/Get/Document-3902 https://www.lsstcorp.org/docushare/dsweb/View/Collection-973 Description Value Unit Name

1976 US standard STP sea level pressure is seaLevelPressure.

1013 milibar seaLevelPressure

The standard relative humidity percentage is stpRelHumidity.

15 Percent stpRelHumidity

The standard typical Ozone level over northern Chile is ozoneLevel.

338 Dobson ozoneLevel

Reference airmass for calculating the standard transmission function is stdAirmass.

1.0 Airmass stdAirmass

Standard Dark Sky Emission

ID: OSS-REQ-0019


Specification: For the purpose of evaluating the system performance and the flow down of subsystem requirements the assumed sky brightness in each filter shall be as defined in the darkSkyBrightness table below. Discussion: The details of the sky brightness model and assumptions used are given in Document-8857. The data file containing the assumed sky spectrum is found in Document-8817. The value for the y-band is for the adopted baseline y4 filter.

https://www.lsstcorp.org/docushare/dsweb/Get/Document-3902

https://www.lsstcorp.org/docushare/dsweb/View/Collection-973



8

The intense sky emission at the extreme red end of the LSST system response means this value could change significantly should a different y-band definition be adopted later. https://www.lsstcorp.org/docushare/dsweb/Get/Document-8817 https://www.lsstcorp.org/docushare/dsweb/Get/Document-8857 Description Value Unit Name

Integrated reference sky brightness in the u-band. 22.92 mag/SqArcsec

u_SkyBrightness

Integrated reference sky brightness in the g-band. 22.27 mag/SqArcsec

g_SkyBrightness

Integrated reference sky brightness in the r-band. 21.20 mag/SqArcsec

r_SkyBrightness

Integrated reference sky brightness in the i-band. 20.47 mag/SqArcsec

i_SkyBrightness

Integrated reference sky brightness in the z-band. 19.59 mag/SqArcsec

z_SkyBrightness

Integrated reference sky brightness in the y-band. 18.42 mag/SqArcsec

y_SkyBrightness

Usable Observing Time

ID: OSS-REQ-0020


Specification: The LSST system shall be designed for the expected average number of usable observing hours at the site, nightDurationAvg, the winter maximum, nightDurationMax, and the summer minimum, nightDurationMin. Discussion: These values have been defined with reference to Nautical (12-degree) twilight and do not include the effects of weather. These specifications are required for the design of the peak and average capacities of the Data Management system. They also provide constraints for the definition of the non-observing-time budget for observing preparation, calibration, and maintenance activities together. During the period around winter solstice the scheduled maintenance and calibration activities will be defined such that they can be accommodated in short non-observing hours. Description Value Unit Name

The mean useable length of a night shall be taken as nightDurationAvg.

10 Hour nightDurationAvg

The maximum useable length of a winter night shall be taken as nightDurationMax.

12 Hour nightDurationMax

The minimum useable length of a summer night shall be taken as nightDurationMin.

8 Hour nightDurationMin

1.2.1.2 Base Site

ID: OSS-REQ-0021






9

Specification: The LSST Base Facility shall be located at the AURA Recinto compound in La Serena, Chile. The facilities at the Base Site shall be designed to be consistent with existing conditions; where local standard construction codes are not sufficient, all equipment shall be designed to project-defined Seismic Specifications. Discussion: The facilities at this site will be developed through new construction or through agreements that meet operational and functional requirements but take advantage of existing NSF and AURA infrastructure.

1.2.1.3 Seismic Design Parameters

ID: OSS-REQ-0344


[These requirements are under review and have not been formally adopted.] Discussion: The LSST Summit and Base Facilities are located in Region-3, Chile; a known seismically active area. The requirements for seismic accelerations established here determine the probability for survival, recoverable and operable events as defined below. As a result of the interactions of the dynamic characteristics (natural frequencies and damping) of the telescope mount and its components with the vibration frequencies of the seismic accelerations, the maximum accelerations of the telescope systems vary significantly according to their location on the telescope mount. Consequently, for all systems mounted to the telescope for all event levels, the design accelerations will be determined by the application of the appropriate seismic vibration spectrum to a finite element analysis (FEA) model of the telescope and its pier. These accelerations will be specified at the appropriate interfaces between subsystems and/or components. Verification of these requirement will be by analysis or prototype. The implied accelerations are normalized to ductile materials and should be scaled to ASME standard safety factors for other material types (e.g. glass, carbon fiber etc..). Where a range of material strengths is possible verification analysis will use the minimum strength to determine compliance.

Survival Seismic Design Parameters

ID: OSS-REQ-0014


Specification: All systems and/or components permanently located at the Summit or Base Facilities shall be designed to withstand the loads resulting from an earthquake up to the levels a 300-year return period seismic event and stay intact such that catastrophic failure is prevented and the hazards to personnel safety are either eliminated or reduced. The levels of a 300-year return period earthquake have a 9.5% probability of being exceeded in 30 years. The ground acceleration values corresponding to a 300-year return period earthquake are defined in the standards established in OSS-REQ-0095. "Catastrophic failure” shall be defined as fracture or rupture that allows a significant element to separate and fall, or produces the possibility of personnel injury. Discussion: See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344). The return of the Summit or Base Facilities and their contents to "normal"operations following a "Survival" event will be assessed based on actual damage incurred.



10

Recoverable Seismic Design Parameters

ID: OSS-REQ-0342


Specification: All systems and/or components permanently located at the Summit Facility shall be designed to operate without any permanent damage following a seismic event equivalent to a 20% probability of return over the specified design lifetime of the system and/or component. "Permanent damage” shall be defined as any damage to optical elements, any yielding of primary structural components, damage where capital repair costs are in excess of $10M (TBR) or repair times longer than 6 months after access and damage assessment. Discussion: See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344).

Operable Seismic Design Parameters

ID: OSS-REQ-0345


Specification: All systems and/or components permanently located at the Summit Facility shall be designed to operate without any significant damage following a seismic event with a return period equivalent to specified design lifetime of the system and/or component. "Significant damage" shall be defined as any damage that cannot be repaired within the statistical allocation of the unscheduled down time defined in OSS-REQ-0082. Discussion: See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344).

1.2.2 Archive Site ID: OSS-REQ-0022


Specification: The LSST Archive Facility shall be located at the National Center for Supercomputing Applications (NCSA) in Champaign-Urbana Illinois. Discussion: The facilities at this site will be developed through new construction or through agreements that meet operational and functional requirements but take advantage of existing NSF and NCSA infrastructure.

1.2.3 Headquarters Site ID: OSS-REQ-0023


Specification: The LSST Headquarters Facility shall be located in the continental United States of America. When design considerations require the specification of the site location, Tucson Arizona shall be used. Discussion: The facilities at the selected site shall be developed through new construction or through agreements that meet operational and functional requirements.

2 Common System Functions & Performance



11

The requirements and specification called out in this section are common and apply across the LSST System. These requirements address the following topics: 1. Survey Scheduling and Management; 2. System Control; 3. System Monitoring and Diagnostics, 4. System Maintenance; 5. System Availability; 6. System Time References; 7. System Standards (including environmental and safety).

2.1 Survey Scheduling and Management ID: OSS-REQ-0024


Specification:The LSST shall be capable of scheduling the survey observations in an automated maner based on several optimization parameters established to produce the Survey specifications defined in the LSST System Requirements (LSE-29) and maximize the operational efficiency. Through the parameters defined below, the LSST shall be capable of adjusting its observations and its scientific priorities if they should change before or during the survey. The System shall monitor survey progress and provide the necessary tools described below to evaluate performance.

2.1.1 Survey Scheduling ID: OSS-REQ-0025


Specification: The Observatory Control System shall schedule the survey with the functionality detailed below.

2.1.1.1 Environmental Optimization

ID: OSS-REQ-0026


Specification: The survey scheduling shall be optimized against local environmental conditions to maximize the survey's scientific return. This optimization shall include the ability to adjust filters based on seeing conditions, the ability to avoid clouds with predefined opacity, and adjust to constraints derived from wind direction.

2.1.1.2 Multiple Science Programs

ID: OSS-REQ-0027


Specification: The survey scheduling shall be capable of optimizing scientific returns from multiple science priorities, numbering at least nSciProp. Discussion: A science proposal will be defined by that include but are not limited to

number of visits and distribution by filter;

temporal of visit distribution and/or sequence definition;

limits on astro-climate quality for observation;

constraints on the location of visit fields;

priority relative to other science proposals



12


The minimum science proposal that the scheduling algorithm must be capable of optimizing over.

6 int nSciProp

2.1.1.3 Parallax Factor Sampling

ID: OSS-REQ-0028


Specification: The scheduler shall enforce an even distribution of parallax factor over the sum of all visits in the 10-year survey.

2.1.1.4 Scheduling Assessment

ID: OSS-REQ-0029


Specification: The survey scheduling shall be adjustable based on periodic assessment of performance. This shall be done down to periods of 1 hour throughout the night and shall be based on actual accomplishments compared to objectives and current system technical performance.

2.1.1.5 Survey History Record

ID: OSS-REQ-0030


Specification: The LSST Scheduler shall maintain an independent record of all past observations and shall include Data Quality Assessment parameters determined by evaluation of the imaging data.

2.1.1.6 Temporal Visit Distribution

ID: OSS-REQ-0031


Specification: The scheduler shall be capable of enforcing 5 (TBR) defined temporal distributions of visits covering the fast sample area (defined in the SRD).

2.1.1.7 Visit Optimization

ID: OSS-REQ-0032


Specification: The survey schedule shall be optimized to maximize the number of scientifically useful visits per night.

2.1.2 Survey Planning and Performance Monitoring ID: OSS-REQ-0033


Specification: The LSST shall provide the tools and administrative processes necessary to monitor the progress of the ongoing survey,provide reports on the progress of the survey, respond to feedback from the science community, and evaluate the impact of changing science priorities over the 10 year survey lifetime. Discussion: It is expected that the performance of this task will require the use of detailed survey simulations in order to evaluate scheduling alternatives and optimize the future performance of the survey.



13

2.2 System Control ID: OSS-REQ-0034


Specification: The LSST Observatory shall be implemented with a coordinated set of control software that will achieve the specified survey, as well as the necessary command, control and monitoring of all observatory functions and states across the Facilities. Discussion: This control software includes both the Observatory Control System, which is responsible for sequencing activities associated with data collection and initial processing, and the control software for the Data Management system, which will be responsible for alert, data release, and calibration products productions, and archiving and serving data to users.

2.2.1 Control Capabilities ID: OSS-REQ-0035


Specification: The LSST control capabilities throughout the system shall be designed to achieve the specified survey with an operating team consistent with the LSST Operations Plan. [document-7838] To control the system efficiently, safely and reliably, the control system shall include both local and remote control modes as specified in this section. https://www.lsstcorp.org/docushare/dsweb/Get/Document-7838

2.2.1.1 Local Autonomous Administration of System Sites

ID: OSS-REQ-0036


Specification: Each site in the LSST Observatory shall be capable of local autonomous control and operation. The LSST System shall include the necessary provisions to function effectively when data connections to other sites of the Observatory are interrupted. Discussion: By "Function effectively" it is understood that when data connections are lost that not system functions will be preserved. For example, the Base Facility cannot generate alerts within 60 seconds without the data coming from the Summit Facility and the Archive Facility cannot serve data it doesn't yet have. Further, regarding data management "effectively" means that the equipment operates normally, processes, and serves whatever data is available.

2.2.1.2 Remote Operation Capabilities

ID: OSS-REQ-0043


Specification: All LSST major subsystems and OCS shall be remotely operable from any of the LSST Facilities or other Project designated site (e.g. SLAC for camera troubleshooting). Discussion: This provides the opportunity to establish a single operations center for the various system functions. Remote operation of the telescope requires granting of permission by an operator who is present at the site, and must remain present during remote operation It is expected that routine observing oversight of the observatory will be done from the Base Facility, with the exception of actions for which safety and/or equipment protection considerations require operator




14

presence on the summit. These restrictions will be documented in the LSST Safety Plan.

Summit Facility Operator

ID: OSS-REQ-0308


Requirement: A local operator shall be always available at the Summit Facility to regain local control when conditions or safety considerations merit.

Netwrok Security

ID: OSS-REQ-0309


Requirement: Remote operations shall comply with all LSST Corporation cyber security policies in effect at the time.

2.2.1.3 Observatory Safety System

ID: OSS-REQ-0321


Specification: Each Facility in the LSST Observatory shall implement a non-software based safety system(s) in areas where injury or harm to personnel and or equipment can occur.

2.2.1.4 Observatory Control System Definition

ID: OSS-REQ-0037


Specification: The Observatory Control System (OCS) is the primary high level supervisor and monitor for conducting the survey that shall consist of software subsystems that interact through a connectivity backbone layered on top of the observatory communications network. Discussion: The OCS commands, monitors and controls all observatory activities, to achieve a safe and efficient observation environment.

Scope of Control

ID: OSS-REQ-0038


Specification: The OCS shall control and monitor all activities necessary for the acquisition of the survey and ancillary data. Additionally, the OCS shall provide high level control of the Data Management system's processing of new data from the observatory, including the selection of its operational mode consistent with each type of operational and maintenance data acquisition. Discussion: The operational mode selection above is intended to encompass the choice of normal nightly science data acquisition, calibration data acquisition of various types, and diagnostic processes. The OCS will control the nightly start and stop of DM processing and overall system state changes, but it is not envisioned that it will exert fine-grained (e.g. per-exposure or per-visit) control of DM's activity.

Visit Sequencing

ID: OSS-REQ-0039


Specification: : The OCS shall include the ability to orchestrate a complete sequence of visits over any 24 hour time period. This master sequencer shall be capable of system action flow control as well as



15

system process synchronization and parallelization. Discussion: OCS can be viewed as a sequencing engine for the execution of science, calibration, and engineering observations. The sequence of science observations are generated by the observatory scheduler based on observatory performance and project defined priorities. The master sequencer will include observatory configuration and target acquisition sequences, from an OCS master process sequencer.

Manual Visit Specification

ID: OSS-REQ-0040


Specification: The OCS shall be capable of accepting a full set of visit specifications from an external source. This shall include individual operator defined targets and a target list that is followed in order.

2.2.1.5 Subsystem Activation

ID: OSS-REQ-0041


Specification: Upon activation, each subsystem connected to the OCS architecture shall be able to initialize itself and be ready for communication with the OCS without further human intervention. This activation process shall take less subSysStart to complete.. Discussion: In the context of this requirement a subsystem refers to the three major subsystem of the LSST Observatory, Telescope, Camera, and Data Management. It can also include other subsystems of each of the three that are directly connected to the OCS architecture. This does not place any requirements on the subsystem in terms of being ready to take data. For example, the Camera cool down (which requires activation) will take considerable longer than 1 minute. This requirement assumes a "warm restart" or activation with the appropriate computer(s) up and running. Description Value Unit Name

The maximum time for a subsystem to execute a warm restart and regain connectivity with the OCS.

60 Seconds subSysStart

2.2.1.6 Subsystem Initialization

ID: OSS-REQ-0307


Specification: Each subsystem when powered up shall be initialized into a known safe state without human intervention.

2.2.1.7 Subsystem Health and Welfare

ID: OSS-REQ-0042


Specification: Each LSST subsystem shall be responsible for maintaining its own technical heath, safety, and status without any other subsystem operational. Discussion: The Observatory shall have independent safety systems but each subsystem shall include an initial level of autonomous safety for independent operation.



16

2.2.2 Standard Operating States ID: OSS-REQ-0044


Specification: The LSST observatory system shall be designed and constructed to support the following operational states:

Fully automated observing - used for most of the survey observing;

Calibrate - used for special observing modes needed to calibration either the science data or other technical aspects of the observatory;

Manual observing - used for specific non-scheduler driven observing to support system verification and testing or specialized science programs;

Engineering and Maintenance Note: The states need further definition in terms of access and safety requirements for each.

2.2.2.1 Automated Survey Observing

ID: OSS-REQ-0045


Specification: The LSST system shall be capable of operating in an automated operation state to perform the survey execution. Discussion: The survey operation shall proceed under the conduct of the OCS utilizing the automated scheduler and its coordination capabilities with an operator available at the Summit Facility.

2.2.2.2 Calibration

ID: OSS-REQ-0046


Specification: In calibration state the LSST system shall be capable of performing a science calibration plan. Discussion: The science calibration plan can include both the acquisition of specialized sky observations or instrumental characterization data (e.g. dome flats, dark and bias images).

2.2.2.3 Engineering and Maintenance

ID: OSS-REQ-0047


Specification: While in the engineering and maintenance state the LSST system shall provide the capabilities to support the activities comprising of access to maintenance plans, capturing relevant telemetry, executing sequences of tests, recording of associated activities, among others.

2.2.2.4 Manual Observing

ID: OSS-REQ-0048


Specification: The LSST Observatory shall be capable of executing manual or simple script driven observations.

2.2.3 Degraded Operational States ID: OSS-REQ-0049 Last Modified: 4/21/2011



17

Specification: The LSST system shall support the modes of degraded operation enumerated below. Discussion: For each type of degradation we specify the time for which we can tolerate an outage of that particular type. Longer outages are then assumed to cause unacceptable losses, and are then charged against the unscheduled downtime budget. The system should therefore be engineered to minimize the occurrences of outages longer than the specified durations. This can lead to concrete requirements at lower levels. For instance, the fact that we are designing for two-day outages in Summit-Base and Base-Archive connectivity now requires us to minimize the number of outages longer than two days. This can be done, for instance, by requiring - at the subsystem level - the acquisition of redundant network links.

2.2.3.1 Summit Power Grid Loss

ID: OSS-REQ-0050


Specification: The summit Facility shall be capable of normal survey operations in the event of power loss from the grid for a minimum duration of gridLossTime. Description Value Unit Name

The minimum time between resupply of the Summit Facility backup power under continuous operation.

2 Days gridLossTime

2.2.3.2 Summit-Base Connectivity Loss

ID: OSS-REQ-0051


Specification: The LSST shall be able to continue with automated survey observing in the event that the data communications between the Summit and Base sites are severed, for outages of less than summitConnectivityLossTime. Discussion: The level of data quality monitoring provided during such degraded operation may be lower than normal, due to the lack of availability of Base resources for computing. However, at a minimum, data quality monitoring related to the health and welfare of the subsystems (see OSS-REQ-0065) and simple analytic functions of the "quick look" display (see OSS-REQ-0057) must be maintained. Upon resumption of normal operations all normal science data processing, including full data quality assessment, must be completed on acquired during the outage. The emphasis on automated survey observing here is meant to convey that other capabilities might be lost during such an outage, for instance the ability to reassess the progress of the survey, adjust scientific priorities, etc. Description Value Unit Name

Minimum duration of summit-base connectivity outage for which normal survey operation can be maintained

48 Hour summitConnectivityLossTime

Summit Data Buffer

ID: OSS-REQ-0052




18

Specification: The LSST system shall provide a limited buffer of both raw image (science and wave front sensing images) and telemetry data to allow survey observations to proceed in the event of communications loss between the summit and base. The buffer(s) shall have sufficient capacity to store the raw pixel and telemetry data for at least the design outage time, summitConnectivityLossTime. Upon recovery from a communications interruption, it shall be possible to drain the buffer, in parallel with continuing normal operations, in no more than summitBufferTransferTime. Discussion: Once the connectivity is restored it is expected that any data obtained during the outage will be transferred to the Base Facility and then forwarded to the Archive Facility where it will be processed for alerts (late) and the data base updated. Discussion: This requirement does not imply completing the nightly reprocessing of 3 days worth of data at the Archive Facility within 24 hours. Description Value Unit Name

The maximumallowedtime to transmit entire pixel buffer in parallel with normal operations is summitBufferTransferTime.

24 Hour summitBufferTransferTime

2.2.3.3 Base-Archive Connectivity Loss

ID: OSS-REQ-0053


Specification: The LSST system shall be able to conduct normal science operations in the event that data communication between the base and archive sites is lost, for outages of less than baseConnectivityLossTime. Description Value Unit Name

Minimum duration of base-archive connectivity outage for which normal survey operation can be maintained

48 Hour baseConnectivityLossTime

Maximum time for recovery from a Base-Archive communications outage of length baseConnectivityLossTime.

24 Hour baseConnectivityRecoveryTime

Base Data Buffer

ID: OSS-REQ-0054


Specification: The LSST system shall provide a limited buffer for data (raw, processed, and engineering) en route from the Base to the Archive Center, to allow science operations to proceed in the event of communications loss between the Base and Archive. The system shall have sufficient capacity to store all en route data for at least the design outage time, baseConnectivityLossTime. Discussion: This requirement does not imply completing the nightly reprocessing of the buffered data at the Archive Facility within 24 hours once it is transferred.

Base Updating from Archive

ID: OSS-REQ-0055


Specification: Following an outage in Base-Archive connectivity not longer than baseConnectivityLossTime, all data transfer from Archive to Base shall be brought current within



19

baseConnectivityRecoveryTime, in parallel with the continuation of normal operations.

2.3 System Monitoring & Diagnostics ID: OSS-REQ-0056


Specification: LSST Observatory shall monitor system and instrument performance on a regular (daily where appropriate) basis with the goal of detecting sudden as well as gradual performance changes. Discussion: Data volume and rate drive the need for very summary or statistical representation of the information, thresholds and alarms, and the ability to drill down. During routine observing hours the system will provide real time display(s) summarizing system performance. This includes real time display of the FPA image and basic image analysis including, but not limited to PSF measurements, background levels, amplifier noise and other image statistics. . During non-observing hours the primary activity shall be to review the quality control and performance parameters specified by the established baseline performance report against the current performance summarized in automated reports. Sudden changes should be obvious from the near real time displays and image analysis – detecting long-term changes will require monitoring performance as a function of time.

2.3.1 Image Visualization ID: OSS-REQ-0057


Specification: The LSST Observatory shall provide the means to display images from the FPA (including both science and wavefront sensors) in real time commensurate with the FPA readout, as well as from archived images. This "quick look" display shall support the following global functions:

Pan/zoom quickly and easily to arbitrary resolution

View from laptop/workstation or multi-monitor wall (albeit with performance trade-offs)

Ability to view warning/quality flags via color coding, overlays or some other mechanism

blink / compare images from at least two different exposures

2.3.1.1 Analytic Functions

ID: OSS-REQ-0058


Specification: The "quick look" display tool shall support as a minimum the following analytic functions:

computation of basic statistics (mean, mode, SDEV, etc...) over an arbitrary region of pixel space

line/column plot on any scale

histogram of pixel values in an arbitrary region of pixel space

basic PSF measurements (FWHM, second moments, radial plots profile fitting, etc...)

simple arithmetic between arbitrary regions of two images

overlaying the results of queries to the Engineering & Facility Database



20

2.3.1.2 Display Timing Performance

ID: OSS-REQ-0059


Specification: The "quick look" image display at the Summit and Base Facilities shall respond with the latency performance indicated below. Discussion: these requirements only apply to "quick look" display located at the Summit and BAse Facilities when accessing data from either the base archive or the summit data buffer. Description Value Unit Name

Users at the Summit or Base facility shall be able to view the image data from the most recent exposure within displayLatency after the shutter has closed.

10 Seconds displayLatency

Users shall be able to cycle through predefined views of the full image (e.g. bright or faint star optimized binned, bias map, noise map, etc.) within viewCycleTime between each.

2 Seconds viewCycleTime

2.3.1.3 Image Data Sources

ID: OSS-REQ-0060


Specification: The "quick look" image display shall have access to image data from the following sources:

the real-time pixel streams (raw or cross-talk corrected)

the 2-day on Summit image buffer (from Summit and Base only)

the image archive at the Base Facility

the image archive at Archive Facility

2.3.1.4 Image Display Locations

ID: OSS-REQ-0310


Specification: "Quick look" image displays shall be locatde at a minimum at the following locations:

Summit Facility Control Room

Base Facility Control Room

Archive Facility

Headquarters

Data Access Centers

2.3.2 Data Visualization ID: OSS-REQ-0061


Specification: The LSST Observatory shall provide facilities (physical and software) for the visualization of a variety of types of data produced by the Observatory at the locations specified in OSS-REQ-0006, including:



21

Catalog data derived from image analysis

Calibration data and data products, including images and spectra from the ancillary telescopes and cameras in the Observatory

Data quality metrics derived from the analysis of the Observatory's raw data

Engineering and facilities data, including monitoring and diagnostic data from the Observatory and data processing systems

Data processing metadata

Selected reference datasets from external sources (e.g., astrometric catalogs) These facilities shall provide for at least the following types of displays:

Statistical, including histograms, correlation plots, and basic statistical data reductions on selected data

Temporal, showing time histories of selected parameters and of statistical properties of acquired data

Spatial, displaying data overlaid on associated images

2.3.3 Subsystem Telemetry ID: OSS-REQ-0062


Specification: All LSST subsystems shall publish telemetry using the Observatory specified protocol (LSST Document-2233) containing time stamped structures of all command-response pairs and all technical data streams including hardware health, and status information. Discussion: In the context of this requirement a subsystem refers to the three major subsystem of the LSST Observatory, Telescope, Camera, and Data Management. It can also include other subsystems of each of the three that are directly connected to the OCS architecture. Hardware health and status information includes data regarding the correct functionality of all major internal components and sub-subsystems. The data for the science, wavefront sensing, and raw guider images are not included in this requirement. https://www.lsstcorp.org/docushare/dsweb/Get/Document-2233

2.3.3.1 Subsystem Metadata for Science Analysis

ID: OSS-REQ-0063


Specification: The subsystem telemetry shall include all required information (metadata) needed for the scientific analysis of the survey data. Discussion: The specific metadata that each subsystem is required to produced will be detailed as part of the DM interface control definitions between the Camera, Telescope & Site, and OCS. Collection-1539 contains the lists of metadata for the EFD as it is developed. https://www.lsstcorp.org/docushare/dsweb/View/Collection-1539

2.3.3.2 Subsystem State Notification






22

Specification: Each subsystem shall report changes in its internal state consistent with the significant state changes contained in the Observatory State Model in SysML. Discussion: The state change notification include at least those states defined in OSS-REQ-0047, as well as the following additional states:

System Reset

Emergency Shutdown

Standby / Idle

Reconfiguring

2.3.3.3 Subsystem Status

ID: OSS-REQ-0065


Specification: Each LSST subsystem (or a small number of major subsystem components) shall assess and report an overall hardware health status. Discussion: The primary purpose of these status indicators is for the OCS to be able to orchestrate normal operations and handle out of normal conditions.

2.3.3.4 Telemetry Database

ID: OSS-REQ-0195


Specification: The LSST System shall capture the telemetry data produced by every subsystem, organize it and make it available through an Engineering Facility Data Base (EFD). Discussion: There will be two kinds of interfaces for querying the EFD. One is to obtain the current value of the telemetry, a real-time status of the system. The other one is for accessing the history of the telemetry. The access of large amount of history data may span through more than one distributed instance of the EFD, and such fact must be transparent to the user performing the query, as well as not having an impact on real-time operations. https://www.lsstcorp.org/docushare/dsweb/View/Collection-677

Control Data

ID: OSS-REQ-0196


Specification: The telemetry data shall include reported values needed for the purpose of the real-time control of the observatory.

Engineering Data

ID: OSS-REQ-0197


Specification: The telemetry data shall include reported values needed for the purpose of the engineering activities.

Meta Data




23

ID: OSS-REQ-0198


Specification: The telemetry data shall include reported values needed for the purpose of the insertion of meta data alongside the science data.

Monitoring Data

ID: OSS-REQ-0199


Specification: The telemetry data shall include reported values needed for the purpose of the monitoring activities.

Telemetry Database Sizing

ID: OSS-REQ-0311


Specifications: The telemetry database shall be sized and support the bandwidths defined in the table (EFD_OSSparameters) below. Discussion: The average rate EFD_AvgRate and the estimated data storage requirement i EFD_DayStore are supported in document 7722. There is another set of data (see document 7721) consisting of non-science images that are not permanently stored in the EFD that pushes the data rate transfer to Blob_AvgRate, for a combined rate of NonScience_MaxRate. https://www.lsstcorp.org/docushare/dsweb/Get/Document-7721 https://www.lsstcorp.org/docushare/dsweb/Get/Document-7722 Description Value Unit Name

Long-term mean ingest rate to the Engineering and Facilities Database required to be supported.

6.5 Mbit/sec EFD_AvgRate

The minimum supported daily data volume of the engineering facility data base.

30 GBytes EFD_DayStore

Long-term mean ingest rate to the Engineering and Facilities Database of non-science images required to be supported.

15.4 Mbit/sec Blob_AvgRate

Maximum ingest rate to the Engineering and Facilities Database of non-science images required to be supported.

21.9 Mbit/sec NonScience_MaxRate

Initiation of Telemetry Database

ID: OSS-REQ-0312


Specification: Collection and retention of telemetry data shall begin no later than the start of system integration in the Summit Facility.

Telemetry Database Retention

ID: OSS-REQ-0313


Specification: The data in the EFD shall be retained at least for the lifetime of the survey.

2.3.4 Subsystem Baseline Performance ID: OSS-REQ-0066






24

Specification: Each subsystem shall provided a baseline of the as built performance as determined during acceptance testing and system integration & test. Discussion: The baseline analysis is a deliverable of the subsystem and will be part of the acceptance process. It is expected that over time the observatory operations staff will modify and add to the analysis as knowledge of the subsystems improves.

2.3.5 Subsystem Performance Reporting ID: OSS-REQ-0314


Specification: The LSST Observatory over the course of the 10-year survey shall monitor its performance with respect to its established baseline and report variances exceeding established thresholds.

2.3.6 Performance & Trend Analysis Toolkit ID: OSS-REQ-0067


Specification: The LSST system shall provide a common tool kit for conducting performance analysis, including trending, on the telemetry captured in the Engineering & Facility Database. Discussion: This tool kit will be part of the OCS.

2.3.7 Summit Environment Monitoring ID: OSS-REQ-0068


Specification: The LSST Observatory shall monitor the local observing environment so that delivered data performances can be assessed against the state of the environment at the time the data were obtained. The monitoring shall include all natural elements that impact the image data quality and at a minimum shall include the following as detailed below:

Cloud Coverage

Meteorological Parameters

Atmospheric Turbulence Structure

Integrated atmospheric seeing

Seismic activity Discussion: The data generated from the Summit Environmental Monitoring is part of the recorded observatory telemetry streams (see OSS-REQ-0062).

2.3.7.1 Atmospheric Seeing

ID: OSS-REQ-0069


Specification: For the purpose of monitoring the system performance and optimizing its operation the LSST Observatory shall provide the necessary instruments to measure the atmospheric seeing independently from the main observing system.

2.3.7.2 Atmospheric Turbulence Structure

ID: OSS-REQ-0070




25

Specification: For the purpose of monitoring the system performance and optimizing its operation the LSST Observatory shall provide the necessary instruments to measure the structure of the atmospheric turbulence in at least minTurbLayers to an altitude of minTurbHighAltitude. Description Value Unit Name

The high altitude limit to which the atmospheric turbulent profile shall be measured shall be no less than minTurbHighAltitude.

20000 Meters minTurbHighAltitude

The number of layers for which the atmospheric turbulence structure will be measured shall be at least minTurbLayers.

6 int minTurbLayers

2.3.7.3 Cloud Mapping and Monitoring

ID: OSS-REQ-0071


Specification: For the purpose of monitoring the system performance and optimizing its operation the LSST Observatory shall provide the necessary instruments to provide a 2-D map of the cloud cover covering the visible sky centered on the Summit Site with a cadence equal to or faster than a standard visit. The could map shall as minimum the properties listed in the table below. Description Value Unit Name

The angular resolution of the all sky cloud map shall be at least cloudMapResolution.

1.0 Degrees cloudMapResolution

The angular extent of the all sky cloud map centered on the zenith point shall be at least cloudmapCoverage.

150 Degrees cloudMapCoverage

2.3.7.4 Weather and Meteorological Monitoring

ID: OSS-REQ-0072


Specification: The LSST Observatory on the summit shall provide local weather conditions that impact, and at a resolution consistent with, technical and scientific performance. This shall include, at a minimum, Temperature Humidity Wind Speed Wind Direction

2.3.7.5 Seismic Monitoring

ID: OSS-REQ-0073


Specification: The LSST Observatory shall provide and report real time monitoring of local summit seismic activity and a near real-time feed back on nearby seismic events to the local operators at the summit and base facilities.

2.4 System Maintenance ID: OSS-REQ-0074


Specification: The LSST system shall be designed for maintainability of components, and a maintenance plan shall be implemented to achieve the required survey performance during the life span.



26

Discussion: The concept of the maintenance comprises both the idea to facilitate the monitor/inspection/repair activities and the plan to perform the activities. The maintenance activities and the plan to perform them, shall be derived from documentation delivered as part of each subsystem. Maintainability features in the designs shall include: the adoption of standard components where possible; use of software and utility systems to track and minimize the spare parts inventories; and technical training and tool sets for maintenance activities. Specific standards and codes are detailed below in System Standards.

2.4.1 Predictive Maintenance ID: OSS-REQ-0075


Specification: The LSST Observatory shall implement and maintain a comprehensive system-wide predictive maintenance program based on regular inspection and/or condition monitoring of all major sub-systems including enclosure, telescope, adaptive optics, and instrumentation. Discussion: The goal is to detect and correct performance degradation and/or potential failures before these problems cause lost science time or significantly reduce system efficiency.

2.4.2 Preventive Maintenance ID: OSS-REQ-0076


Specification: The LSST Observatory shall implement and maintain a comprehensive system-wide preventive maintenance program based on vendor recommendation. Discussion: This program shall cover all major technical sub-systems including enclosure, telescope, active optics, instrumentation, and data processing hardware and software. The goal is to maintain system efficiency within specified ranges and maximize the time between failures.

2.4.3 Maintenance Activity Support ID: OSS-REQ-0077


Specification: In support of all maintenance activity, both predictive and preventive, the LSST Observatory shall implement the following systems:

Comprehensive problem reporting, tracking, and management system

Work order driven preventive maintenance support system (usually known as CMMS for Computerized Maintenance Management System).

Warehouse inventory and property control

Document control center

Analysis tools for supporting predictive maintenance.

2.4.4 Maintenance Reporting ID: OSS-REQ-0078




27

Specification: For the purposes of monitoring technical performance, a set of automatic reports based on engineering telemetry shall be generated on a daily basis. Discussion: The reports are based on device/mechanism usage, behavior of their parameters within specified limits, and correlation with common environmental conditions. More detailed and specific reports can be generated using the tools specified in Maintenance Activity Support.

2.4.5 Maintenance Tracking and Analysis ID: OSS-REQ-0079


Specification: The LSST Observatory shall maintain a permanent record of the description and time required to recover from all maintenance events.

2.5 System Availability ID: OSS-REQ-0080


Specification: The LSST system shall have an availability for science and calibration observations, of at least plannedAvailability of observing nights of operation, within the specified performance limits defined under "Normal Operating Conditions" (see OSS-REQ-0010 above) and the allowed fractional cloud cover cloudCoverFrac, in order to achieve the goals given by the survey. Discussion: An observing night is considered when weather conditions are within observable limits. Of those observing nights a percentage is allocated for scheduled downtime and another for unscheduled downtime. Description Value Unit Name

The minimum allowed fraction of available nights that can be used when all sources of down time are summed is plannedAvailability.

90 Percent plannedAvailability

An night is considered "observable" when the fractional cloud cover is less than cloudCoverFrac.

62.5 Percent cloudCoverFrac

2.5.1 Scheduled Down Time ID: OSS-REQ-0081


Specification: The LSST shall meet the survey specifications allowing for plannedDownTime days of scheduled down time annually for maintenance and repair. Description Value Unit Name

Allowed down time for scheduled non-observing activities is scheduledDownTime.

14 Days scheduledDownTime

2.5.2 Unscheduled Down Time ID: OSS-REQ-0082


Specification: The LSST shall meet the survey specifications allowing for the equivalent of unplannedDownTime days for un-scheduled down time annually for maintenance and/or repair.



28

Discussion: The basis for allocating the unscheduled downtime uses "typical" observatory down time of 4% with 2% added to account for the single instrument of the LSST. This down time covers only the ability to collect survey data. Description Value Unit Name

The allowed time the system can be down for unplanned events is unplannedDownTime.

21 Days unplannedDownTime

2.6 System Time Reference ID: OSS-REQ-0086


Specification: The LSST system shall provide an observatory wide standard time reference that shall be used by all subsystems where absolute and external time reference is required

2.6.1 Time Acuracy and Precision ID: OSS-REQ-0087


Specification: All time tagged events reported both internally and externally by the LSST system shall be done with the timing accuracy and precision given in the table below. Discussion: This implies that the observatory master clock is significantly better than the specifications for absolute accuracy (e.g. absolute accuracy of few mili-seconds) to allow latency in the various subsystems to meet this requirement. Description Value Unit Name

All time tagged events reported both internally and externally by the LSST system shall be done with an accuracy of absTime.

0.010 Seconds absTime

All internal events within the LSST system shall be recorded with a precision relative to the master clock of relTime.

0.001 Seconds relTime

2.6.2 Time Reporting Standard ID: OSS-REQ-0089


Specification: The time reporting standard shall be International Atomic Time (TAI). Discussion: TAI is a purely sequential time standard without leap seconds. It forms the basis of the Terrestrial Dynamic Time standard from which most other time references can be derived.

2.7 System Standards ID: OSS-REQ-0090


Specification: The LSST shall be designed to meet the site based component and procedure standardization captured in the LSST System Standards document, LSE-XX. This document defines the component standards to be followed to ensure a minimum dispersion of final design elements across the LSST system, in particular at a single facility/site.



29

Discussion: The objective is to minimize the support equipment and specialized training necessary to maintain and operate different types of electronics, to minimize the types of tooling to service otherwise similar hardware, etc...

2.7.1 Environment ID: OSS-REQ-0091


Specification: The LSST shall be developed and operated in compliance with all applicable local environmental, cultural, and permitting regulations for each relevant LSST site and location of work. All LSST development and operation shall comply with the LSST Environmental and Cultural Sensitivity Plan (Document-TBD) that describes in detail the LSST Policy and Procedure for adhering to local permitting requirements and other US Federal guidelines for extraterritorial projects. In addition to these local and international standards the LSST shall also comply with the following environmental parameters.

2.7.1.1 Electromagnetic Compatibility

ID: OSS-REQ-0343


Discussion: LSST consists of a collection of commercial and custom electronics supporting a single scientific instrument. Some parts of the instrument deal with exceptionally small electrical signals and are, thereby, susceptible to interference from neighboring equipment. Some parts of the instrument deal with large voltage and current changes and are, thereby, potential sources of interference. It is essential for robust operation of the Observatory that all electrical and electronic equipment be purchased, designed, fabricated and installed with this in mind.

Electromagnetic (RF) Emissions

ID: OSS-REQ-0092


Specification: The LSST Observatory shall not emit electromagnetic radiation on any frequency in accordance to FCC part 15 Class B standards that significantly interferes with itself (as defined by meeting its performance specifications) or the operation of any neighboring facility, not including the formal certification defined in those standards. All off-the-shelf electronic devices that are not compliant require suitable shielding or other mitigation. Custom designed LSST electronics shall take advantage of all reasonable good practices in design and fabrication to minimize interference.

Electromagnetic (RF) Suceptibility

ID: OSS-REQ-0326


Specification:The LSST Observatory shall not be susceptible to electromagnetic emissions consistent with FCC Part 15 Class A standards and commercial sources within and external to the Summit Facility, not including the formal certification defined in those standards. All off the shelf electronic components that are not compliant require suitable shielding or other mitigation. Custom designed LSST electronics will include all reasonable good practices in design and fabrication that minimize susceptibility. Discussion: This requirement is meant to ensure the LSST design is robust against typical radio emissions in and around the Summit Facility (e.g. walkie talkie and cell phone transmissions).

2.7.1.2 Night Light Emission




30

Specification: During normal night time operation the LSST Summit Facility shall not generate detectable light pollution. Discussion: The requirement is meant to both protect the scientific integrity of the LSST survey and also minimize the LSST's impact on neighboring observatories.

2.7.1.3 Radio Active Background

ID: OSS-REQ-0094


Specification: Charged particle events from radioactive material in the summit facility shall cause a background of no more than 0.01 (TBR) events/cm^2-sec on the detector plane. Discussion: Additional work is necessary to derive the allocation from the telescope and camera.

2.7.2 Building Codes ID: OSS-REQ-0095


Specification: All LSST facilities shall comply with the 2006 International Building Code and the accompanying 2006 International Mechanical/Plumbing Codes for the deisgn of the Summit Support Facility. These codes shall also apply to the LSST Base facility in Chile and the design of all U.S.-based facilities. In addition, all LSST Facilities in Chile shall comply with the applicable Norma Chilena:

NCH-431: "Earthquake resistant design of buildings";

NCH-433: "Earthquake resistant design of buildings";

NCH-2369: "Seismic design of industrial structures and installations"; and with other related regulations regarding seismic design. In cases of conflicting requirements, the most stringent code shall govern.

2.7.3 Electrical and Controls Standards ID: OSS-REQ-0096


Specification: For each system Facility the LSST shall develop and document standards for the following:

Control Panels

Electrical and Electromagnetic Compatibility

Controllers and associated software

Utility Connection

Grounding Summit Facility - Document-TBD Base Facility - Document-TBD Archive Facility - Document-TBD Headquarters - Document-TBD



31

Discussion: The objective of these standards is to support efficient operations and minimize the dispersion of final design elements across the LSST system. This requirement will be applied at the facility/site level to account for differences in facility/site specific needs.

2.7.4 Minimum Design Lifetime ID: OSS-REQ-0097


Specification: The LSST Observatory shall be designed for a minimum lifetime of minDesignLife. Discussion: The minimum design lifetime includes the time from initial assembly during construction, 2 years of commissioning, and 10 years of survey operations. Description Value Unit Name

The minimum expected lifetime covering mid-construction through to the end of 10 years of survey operation is minDesignLife.

15 Years minDesignLife

2.7.5 Safety ID: OSS-REQ-0098


Specification: The LSST shall be designed to achieve the highest level of personnel health and safety performance in all phases of the project lifecycle. All aspects of the design and construction shall comply with the LSST Safety Policy, LPM-18. This policy defines the procedures for personnel and equipment safety throughout the design, construction, and operation phases of the project addressing working conditions and procedures, as well as the management structure and design features that impact safety throughout the LSST Project.

2.7.5.1 Safety Priorities

ID: OSS-REQ-0099


Specification: The safety priority within the entire LSST shall be (in priority order): 1. The protection of personnel; 2. The protection of the technical integrity of the LSST system and other equipment associated with its operation; and 3. The protection of scientific data.

2.7.5.2 Hazard Analysis and Safety Practices

ID: OSS-REQ-0100


Specification: The LSST system shall govern its hazard analysis and safety practices (see LPM-49) in an order of precedence as follows: 1. Design for Minimum Risk: The primary means for mitigating risk shall be to eliminate the hazard through design. 2. Incorporate Safety Devices: Protective devices shall be used as part of system design to reduce hazard risks to an acceptable level where possible. These devices shall be subjected to periodic functional tests and checks. 3. Provide warning Devices: when neither design or safety devices can effectively minimize a



32

hazard risk, devices shall be used to detect the hazard condition and alert personnel of its presence. These devices may include visual or audible alarms and/or movable or permanent signs. 4. Procedures and Training: Only when it is impractical to substantially eliminate or reduce the hazard, or where the condition of the hazard indicates additional emphasis, special operating procedures and training shall be used. All such procedures shall be fully documented. https://www.lsstcorp.org/docushare/dsweb/Get/LPM-49

2.7.5.3 Safety Plan

ID: OSS-REQ-0101


Specification: Comprehensive safety plans shall be developed and implemented before construction starts at each of the 4 LSST system sites.

2.7.5.4 Operational Safety Plan

ID: OSS-REQ-0102


Specification: An operational safety plan shall be developed and implemented before the Commissioning phase starts.

2.7.5.5 Emergency Communications

ID: OSS-REQ-0103


Specification: The LSST shall be designed, and shall include, the necessary communication equipment to support the necessary machine and personnel communication in both normal and emergency operating conditions at the summit. Other LSST sites are not specifically addressed due to their proximity to normal municipality infrastructure and emergency response services.

Earthquake Display

ID: OSS-REQ-0104


Specification: The summit facility shall include a comfort display to present summit personnel with information on seismic activity monitored per OSS-REQ-0073 down to a level of 3 on the Richter scale.

Summit Radio Equipment

ID: OSS-REQ-0105


Specification: LSST shall include radio communication devices to support the personnel necessary to be on the remote summit site. This equipment shall be consistent with Summit radio infrastructure already in place.

2.7.6 Health ID: OSS-REQ-0106


Specification: The LSST shall comply with all applicable local and national environmental and occupational health codes, regulations, and standards.

2.7.7 Security

https://www.lsstcorp.org/docushare/dsweb/Get/LPM-49



33

ID: OSS-REQ-0107


Specification: The LSST shall provide a secure and safe environment for personnel, equipment, and data at each of its 4 operational sites throughout the full life cycle of the project.

2.7.7.1 Cyber Security Agency Requirements

ID: OSS-REQ-0108


Specification: The LSST shall comply with funding agency requirements for cyber security appropriate to the sensitivity of the project and the data it maintains and produces. Discussion: This process requires an evaluation of the threat level and of the consequences of a compromise of security. The bulk of the project will generally be subject to security requirements for what is often called an "open/public/unrestricted" environment. In such an environment, the cyber security architecture focuses on maintenance of the integrity of the data and computing systems, and of system availability. Any sensitive computing systems, such as those used to manage personnel and business data or other Personally Identifiable Information, will be subject to more stringent requirements. The control systems for the LSST Observatory will also require additional levels of security appropriate to SCADA (Supervisory Control and Data Acquisition) for physical systems.

2.7.7.2 Cyber Security Planning

ID: OSS-REQ-0109


Specification: The LSST project shall produce and maintain a cyber security plan and corresponding system architecture. Discussion: The plan must comply with agency requirements (see OSS-REQ-0108). It should be based on established best practices appropriate to the sensitivity of the project and the data it maintains and produces. Within that context, it will reflect engineering tradeoffs based on an evaluation of the anticipated threats, capabilities of security systems, the role of personnel in maintaining a secure environment, and the cost of proposed mitigations.

3 Detailed Specifications

3.1 Science and Bulk Data

The composite requirements below concern the acquisition, processing, and management of science data, as well as certain other bulk data such as wavefront sensor images.

3.1.1 Scoping ID: OSS-REQ-0188


Discussion: The scoping requirements control the amount of input data and catalog entries the Data Management system is expected to process, archive, distribute, and store, and the query and processing load design point for user support.



34

The processing load and resources associated with the derived data products are constrained by these requirements, and may be calculated from them, but do not appear here in the OSS. Many data products are best defined with respect to content, quantity, or quality given certain reference conditions. These conditions are also grouped under this requirement.

3.1.1.1 Raw Exposures Per Night, Maximum

ID: OSS-REQ-0189


Specification: The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least nRawExpNightMax new science exposures per night, in isolated peaks, and an average rate of nRawExpNightWinterAvg for extended periods. Discussion: These rates are derived from the estimate of nightDurationMax hours of science observing on the longest nights of the year, and from the visitDuration and aveVisitInterval parameters of the standard cadence. The peak requirement is derived by adding two hours of twilight observing and taking a worst-case scenario of short slews: it does not account for any time spent moving to a new field beyond the two-second readout period for the second exposure in a visit. This requirement does not include calibration exposures, which are considered separately. Description Value Unit Name

Minimum number of raw science exposures required to be supported by the LSST Observatory in a single-night burst

2800 int nRawExpNightMax

Minimum number of raw science exposures required to be supported by the LSST Observatory over a sustained period (as during the weeks around the winter solstice)

1960 int nRawExpNightWinterAvg

3.1.1.2 Raw Exposures Per Year

ID: OSS-REQ-0190


Specification: The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least nRawExpYear new science exposures per year. Discussion: This rate is derived from an estimate of an average of 10 hours of science observing per night, 300 nights per year that are available for observing (rounded up after taking scheduledDownTime and cloudCoverFrac into account), assuming visitDuration and aveVisitInterval parameters of the standard cadence, and adding a 10% margin. Description Value Unit Name

Minimum number of raw science exposures required to be supported by the LSST Observatory over the course of a single year

5.5E5 int nRawExpYear

3.1.1.3 Galaxy Counts

ID: OSS-REQ-0191


Specification: The LSST Data Management system shall be sized to handle approximately nGalaxyYr1



35

identified galaxies by the end of the processing of the first year's data. It shall be designed to scale to nGalaxySurvey galaxies by the end of the planned survey. Discussion: These numbers are based on peer reviewed estimates collected in the LSST Science Book, Section 3.7.2, and captured in the DM Sizing Model (LSE-81). They assume survey-depth coverage of 25,000 deg

2. Their values depend on the expected depth of single images and the survey. The scaling

with time further depends on an assumed luminosity function. Description Value Unit Name

Minimum number of identified galaxies required to be supported by the end of the processing of the first year's data

8.0E9 int nGalaxyYr1

Minimum number of identified galaxies required to be supported by the end of the processing of the data from the ten-year survey.

2.0E10 int nGalaxySurvey

3.1.1.4 Star Counts

ID: OSS-REQ-0192


Specification: The LSST Data Management system shall be sized to handle approximately nStarYr1 identified stars by the end of the processing of the first year's data. It shall be designed to scale to nStarSurvey stars by the end of the planned survey. Discussion: These numbers are based on peer reviewed estimates collected in the LSST Science Book, Section 3.7, and captured in the DM Sizing Model (LSE-81). They assume survey-depth coverage of 25,000 deg

2. Their values depend on the expected depth of single images and the survey. The scaling

with time further depends on an assumed luminosity function. Description Value Unit Name

Minimum number of identified stars required to be supported by the end of the processing of the first year's data

1.3E10 int nStarYr1

Minimum number of identified stars required to be supported by the end of the processing of the data from the ten-year survey.

1.7E10 int nStarSurvey

3.1.1.5 Alerts per Visit

ID: OSS-REQ-0193


Specification: The LSST Data Management system shall be sized to accommodate an average value of at least nAlertVisitAvg alerts generated per standard visit while meeting all its other requirements. Performance shall degrade gracefully beyond that limit. Discussion: This is derived directly from the SRD specification for transN. Description Value Unit Name

Minimum number of alerts required to be accommodated from a single standard visit

10000 int nAlertVisitAvg

3.1.1.6 Calibration Exposures Per Day




36

Specification: The LSST Observatory shall be capable of collecting at least nCalibExpDay calibration exposures per day, while meeting all other requirements for the use of day time for maintenance and other activities and at least nCalExpMax over a 24 hour period. Discussion: These include bias frames, monochromatic flats, broadband flats, and twilight calibration exposures, as described in the Level 2 Photometric Calibration for the LSST Survey (LSE-180). It is understood that calibration data for guider sensors is a part of this data set. The specification for nCalExpMax is meant to accommodate a cloudy night that is dedicated to calibration. Description Value Unit Name

Minimum number of calibration exposures able to be acquired per day under normal operation shall be at least nCalibExpDay.

450 int nCalibExpDay

The number of calibration exposures that can be acquired over a single 24 hour period (e.g. on a cloudy night) shall be at least nCalibExpMax.

750 int nCalibExpMax

3.1.1.7 Calibration Exposures Per Year

ID: OSS-REQ-0323


Specification: The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least nRawCalYear new Calibration exposures per year. Description Value Unit Name

The total number of calibration exposures that the observatory must be capable of support over a 1 year period shall be at least nCalExpYear.

1.5E5 int nCalExpYear

3.1.1.8 Bright, Isolated Point Source

ID: OSS-REQ-0337


Specification: The terms "bright, isolated point source" and "isolated point source" are used repeatedly in the data quality requirements. This is because many of the requirements are specified as an asymptotic value in the absence of contributions from photon statistics or overlapping objects/confusion. For the purposes of defining test cases for these requirements, "bright" shall be understood to mean having a magnitude in the "bright end" range as defined in sec. 3.3 of the SRD. "Isolated point source" shall be understood to mean a point source (typically a star) having no other detected source within a radius of isolatedRadius PSF FWHM. Description Value Unit Name

Radius containing no other detected sources 10 PSF FWHM

isolatedRadius

3.1.2 Science Image Handling Reliability ID: OSS-REQ-0110


Discussion: The following requirements place constraints on the losses of and damage to science data



37

that has been archived and that are processed during each visit.

3.1.2.1 Science Image Archiving Reliability

ID: OSS-REQ-0111


Specification: No more than sciImageLoss % of science, wavefront, and guider images read out in the camera and specified to be acquired by Data Management shall be permanently lost or corrupted, integrated over all stages of data handling through archiving and availability of the image for access in the archive, or have its essential image acquisition metadata permanently lost or disassociated with the image. Corruption of images shall mean changes of any image pixel values, with the exception of application of a compression algorithm. Any such compression algorithm must be shown to have no effect on any SRD requirement. Discussion: The "specified to be acquired" language allows for the possibility that under some operating modes, such as diagnostics, images might be acquired by the camera and deliberately not archived. Description Value Unit Name

Maximum fraction of read-out raw images permitted to be permanently lost or corrupted downstream, including loss due to the loss or corruption of essential associated metadata.

1% Percent sciImageLoss

3.1.2.2 Science Visit Alert Generation Reliability

ID: OSS-REQ-0112


Specification: No more than sciVisitAlertFailure % of science visits read out in the camera [and specified to be analyzed by Data Management] shall fail to be subjected to alert generation and distribution, integrated over all stages of data handling from data acquisition through transmission of the alerts across the project boundary. Specification: No more than sciVisitAlertDelay % of science visits read out in the camera [and specified to be analyzed by Data Management] shall have their alert generation and distribution completed later than the SRD specification for alert latency (OTT1). Discussion: The "specified to be analyzed" language allows for the possibility that under some operating modes, such as diagnostics, images deliberately not be analyzed for alerts. This requirement applies to visits, and not to individual alerts, because a specification that, e.g., "no more than 1% of alerts shall fail to be generated" gets tangled with questions of the scientific performance of the actual alert detection. This requirement is a performance specification on the DM system, taking the alert-detection algorithm as a given. Note: Visits with alerts delayed beyond the latency specification will not have all of their alerts generated late. A substantial proportion of the alerts for those visits will still be delivered on time. Description Value Unit Name

Maximum fraction of science visits for which alerts are generated, but delivered later than the OTT1 latency

1% Percent sciVisitAlertDelay



38


specification

Maximum fraction of visits for which alerts are not generated or distributed

0.1% Percent sciVisitAlertFailure

3.1.3 Data Acquisition ID: OSS-REQ-0113


[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the hierarchy.] Discussion: These requirements deal primarily with the bulk science data.

3.1.3.1 Acquisition of Science Sensor data

ID: OSS-REQ-0114


Specification: The LSST data management system shall acquire science images from the camera, for archiving and for further processing.

3.1.3.2 Ancillary Image Data

ID: OSS-REQ-0315


Specification: The LSST shall provide for the acquisition of other ancillary image data (e.g. data from the auxiliary telescope) needed for the analysis of the science data.

3.1.3.3 Wavefront Sensor Data

ID: OSS-REQ-0316


Specification: The LSST shall provide for the acquisition of wavefront images used determine the alignment, surface control, and knowledge of the instrumental PSF over the FOV.

3.1.4 Data Processing ID: OSS-REQ-0116


[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the hierarchy.] Discussion: These requirements enumerate the general principles that govern the processing of science data.

3.1.4.1 Automated Production

ID: OSS-REQ-0117


Specification: Level 1 Data Product production shall proceed without the need for routine human intervention in the course of a night's observing.

3.1.4.2 Consistency and Completeness



39

ID: OSS-REQ-0118


Specification: The LSST data management system shall ensure that internal processing tasks are carried out on self-consistent and complete inputs, and that means are provided for users to achieve this in their own processing tasks. Discussion: it should not be possible to inadvertently mix data, calibrations, and code from different data releases. All available data shall be used, and no piece of input data shall be inadvertently double-counted.

Completeness

ID: OSS-REQ-0119


Specification: Completeness means that every appropriate piece of input data from the data sets intended to be processed, such as images or catalog entries, shall be included exactly once in the processing; i.e., that no data will be inadvertently skipped and that no single piece of data will be used, counted, etc. more than once. Discussion:

Consistency

ID: OSS-REQ-0120


Specification: Consistency shall mean that all input data, such as raw images, facility data, catalogs, processed images, metadata, calibrations, camera configuration data, etc., match each other and arise from consistent previous stages of processing, and that all processing is carried out within a single major code release.

3.1.4.3 Open Source, Open Configuration

ID: OSS-REQ-0121


Specification: All LSST-written data processing software shall be released under an open-source license. All configuration information necessary for users to be able to apply the software to reproduce LSST's processing shall also be made publicly available. Discussion: The LSST software is permitted to depend on other open-source software packages, and will establish a configuration control mechanism for determining which are acceptable for use in the project. Discussion: This specification does not prohibit the LSST production system from using infrastructure with a proprietary component, if that is justified by a cost-benefit analysis. The software itself must be open-source, and must be able to be run in at least small-scale production on open platforms.

3.1.4.4 Provenance

ID: OSS-REQ-0122


Specification: The LSST Data Management system shall record provenance data on all its processing activities: all information necessary to reproduce computed data products from the associated raw data, and to understand the processing history of any data product.



40

This shall include at least: software version and build information, settings of all configurable parameters, history of processing steps, identification of all calibration constants used in processing, and hardware and operating system configurations used. Discussion: The intent is for provenance information to be sufficient to support the Reproducibility requirement.

3.1.4.5 Reproducibility

ID: OSS-REQ-0123


Specification: The LSST data management system shall ensure that the results of processing of data are reproducible. Any data processing task, when re-run based on the provenance data from the previous run, on the same system, shall produce the same results (with the exception of provenance data or other execution records that depend on the wall-clock time or on variable system loads). Tasks re-run on different systems shall produce the same results to the extent computationally feasible. Discussion: "Computationally feasible" refers to the fact that floating-point operations typically can return slightly different results on different hardware platforms. LSST code is required to use reasonable care in the implementation of floating-point computations to avoid the unnecessary accumulation of error, but is not required to adopt computationally costly defensive techniques to avoid differences altogether.

3.1.4.6 Software Development Standards

ID: OSS-REQ-0124


Specification: The LSST project shall define a set of software development standards that shall govern all code developed under project auspices, as well as open-source code contributed to and accepted by the project from outside. These standards shall take account of best practices in scientific software development and shall incorporate specifications of external programming language and operating system API standards where appropriate. The software development standards shall be devised to meet applicable project requirements, and shall be under project configuration control. Discussion: It is intended that these standards will include, for example, statements of which specific version of the C++ and POSIX standards the project will follow.

3.1.5 Data Products ID: OSS-REQ-0125


Discussion: This composite requirement contains only the definitions for what data products are required to exist. It does not cover how they are produced nor where or how they are archived nor what means and level of access are to be provided.

3.1.5.1 Level 1 Data Products

ID: OSS-REQ-0126


Specification: Level 1 data products are intended to enable time-domain science use cases requiring timely alerting and follow-up. They are the result of processing of the stream of image data from the



41

Camera during normal observing. Discussion: The baseline list of Level 1 data products is provided as the composite contents of this requirement.

Level 1 Data Product Availability

ID: OSS-REQ-0127


Specification: With the exception of alerts and Solar System Orbits, all Level 1 Data Products shall be made public within time L1PublicT of the acquisition of the data. Solar System Orbits shall be made available within L1PublicT of successful moving source linkage and orbit computation. Alerts shall be made available within time OTT1, from the conclusion of readout of the raw exposures used to generate each alert to the distribution of the alert to community distribution mechanisms. Discussion: Level 1 Data Products will in general arise from either the nightly Alert Production or from the daily processing of each night's data, and will be released to the public promptly following the completion of processing. There is no high-level requirement in the SRD on the latency of delivery to external users of Level 1 data products other than transient alerts, but they should be distributed in a timely way.

Alerts

ID: OSS-REQ-0128


Specification: The Level 1 Data Products shall include the Alerts produced as part of the nightly Alert Production.

Exposures (Level 1)

ID: OSS-REQ-0129


Specification: The Level 1 Data Products shall include the following types of Exposures:

Raw Exposures as obtained from the Camera and assembled/re-formatted for processing

Processed Exposures (trimmed, de-biased, flattened, etc. - i.e., provisionally calibrated)

Difference Exposures. Discussion: All exposures, other than raw exposures, may be regenerated on demand from raw data, rather than be physically stored.

Catalogs (Level 1)

ID: OSS-REQ-0130


Specification: The Level 1 Data Products shall include the following catalogs:

Exposure meta-data

Difference Sources (DIASources, detected by comparing visits with reference images for the same field)

Difference Objects (DIAObjects, inferred from positionally coincident DIASources)

Difference Forced Sources (DIAForcedSources, obtained by performing photometry at the predicted location of previously detected DIAObjects)



42

Solar System Objects (SSObjects, detected by associating sets of DIASources consistent with motion on Keplerian orbits around the Sun) Discussion: These catalogs are all also recreated from scratch during the production of each Data Release. New Solar System Objects will be identified in daily post-processing.

Nightly Summary Products

ID: OSS-REQ-0131


Specification: The Level 1 Data Products shall include a variety of reports, generated every night, that summarize the scientific quality of the Level 1 data (SDQA metrics), and the associated Observatory performance and performance of the Data Management subsystem.

Engineering and Facility Database Archive

ID: OSS-REQ-0132


Specification: The Level 1 Data Products shall include a daily update of the Archive Center copy of the Engineering and Facilities Database (EFD), including all data from the Summit/Base copy of the EFD associated with other released Level 1 Data Products.

Level 1 Data Product Quality

ID: OSS-REQ-0147


Discussion: The requirements in this area specify the scientific performance required of the LSST Level 1 data products. These are driven by the needs of the science missions in the LSST SRD.

Level 1 Catalog Precision

ID: OSS-REQ-0149


Specification: Data processing shall contribute no more than a fraction dmL1PhotoErr to point source photometric errors in Level 1 data products. Data processing shall contribute no more than an RMS error of dmL1AstroErr to point source astrometric errors in Level 1 data products. Discussion: This requirement will be tested with simulation, and in commissioning using repeated observations of one or more fields. Description Value Unit Name

Maximum contribution from DM to Level 1 point source astrometric errors

0.1 arcsec dmL1AstroErr

Maximum contribution from DM to Level 1 point source photometric errors

6 mmag dmL1PhotoErr

Level 1 Photometric Zero Point Error

ID: OSS-REQ-0152


Specification: The photometric zero point determined for each CCD in the Level 1 data products shall agree with the final zero point result from photometric calibration within photoZeroPointOffset.



43

Discussion: This is meant to be interpreted as a requirement on the accuracy of the Level 1 photometric zero-point determination algorithm compared to its Level 2 counterpart, and not a requirement on the weather (e.g., the presence or structure of clouds). Description Value Unit Name

Maximum photometric zero point offset between CCDs and final photometriccalibration

50 mili-Mag photoZeroPointOffset

Alert Completeness and Purity

ID: OSS-REQ-0166


[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the hierarchy.]

Difference Source Spurious Probability Metric

ID: OSS-REQ-0351


Specification: The Observatory shall develop a metric to characterize the probability of each reported difference source being spurious. Discussion: This spuriousness metric will be “prior free” to the extent possible. For example, while it may make use of information from the source and image characterization (e.g., comparison of source to PSF morphology), as well as the information on the Telescope and Camera system (e.g., ghost maps, defect maps, etc.), it will not use any information about the astrophysical neighborhood of the source, whether it has been previously observed or not, etc. The intent is to avoid introducing a bias against unusual sources or sources discovered in unusual environments. The performance of this metric will be assessed by simulations, by insertion and recovery of artificial sources, and comparisons to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc).

Difference Source Sample Completeness

ID: OSS-REQ-0352


Specification: For each visit, the Observatory shall estimate the detected difference source sample completeness and purity as a function of spuriousness metric threshold cut. Discussion: Assuming some spuriousness threshold T, a sample of sources with spuriousness s > T will have some purity (defined as the ratio of the number real sources with s > T and the number of all sources with s > T), and completeness (defined as the ratio of the number of real sources with s > T, and the total number of real sources). This information will aid the end users in selecting the spuriousness threshold appropriate for their particular science case.

Difference Source Spuriousness Threshold - Transients

ID: OSS-REQ-0353


Specification: There shall exist a spuriousness threshold T for which the completeness and purity of selected difference sources are higher than transCompletenessMin and transPurityMin, respectively, at the SNR detection threshold transSampleSNR. This requirement is to be interpreted as an average



44

over the entire survey. Discussion: This specification captures representative completeness and purity rates supportive of time-domain science cases. Note that these are rates determined only using the spuriousness metric cut; it is likely the end-users will perform further classification steps to increase the purity of their samples, depending on their particular science case. This specification will be tested using simulations, by insertion and recovery of artificial sources, and comparisons to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc). Description Value Unit Name

Minimum average completeness for transient science 90 Percent transCompletenessMin

Minimum average purity for transient science 95 Percent transPurityMin

SNR threshold at which the above are evaluated 6 int transSampleSNR

Difference Source Spuriousness Threshold - MOPS

ID: OSS-REQ-0354


Specification: There shall exist a spuriousness threshold T for which the completeness and purity of difference sources are higher than mopsCompletenessMin and mopsPurityMin, respectively, at the SNR detection threshold orbitObservationThreshold. This requirement is intended to be interpreted as an average for any one month of observing. Discussion: This specification captures representative completeness and purity rates needed to enable successful identification and linking of observed Solar System objects. In particular, the need to have a Solar System object repeatedly detected orbitObservation times in orbitObservationInterval days strongly prefers high completeness, even at the expense of purity. This specification will be tested using simulations, by insertion and recovery of artificial sources, and comparisons to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc). Description Value Unit Name

Minimum average completeness for Solar System object discovery

99 Percent mopsCompletenessMin

Minimum average purity for Solar System object discovery 50 Percent mopsPurityMin

Level 1 Difference Source - Difference Object Association Quality

ID: OSS-REQ-0160


Specification: The fraction of isolated Difference Sources not flagged as likely artifacts that are associated with an incorrect Difference Object shall be less than sourceMisassociation for Difference Sources brighter than sourceAssocThreshold sigma in a single visit. Discussion: Source association algorithms that take Difference Object characteristics, such as proper motions, positional error estimates, or shapes, may be needed to satisfy this requirement. The verification method will be by comparison with simulated inputs.



45


Significance threshold for testing of Source-Object associations

5 Sigma sourceAssocThreshold

Maximum fraction of significant Source detections that may be associated with the wrong Object

0.1 Percent sourceMisassociation

Level 1 Moving Object Quality

ID: OSS-REQ-0159


Specification: Valid identification and orbits shall be determined for at least a fraction orbitCompleteness of Solar System objects which are detected orbitObservations times in orbitObservationInterval days at a level orbitObservationThreshold sigma or more above the single frame background. Discussion: Valid identification means that detections of the same Solar System objects have been correctly associated as such. The verification method for this requirement will be comparison with simulated inputs. Description Value Unit Name

Minimum fraction of Solar System objects meeting reference criteria for which valid orbits shall be determined

95% Percent orbitCompleteness

Interval over which a reference test case Solar System object must be observed within a night

90 minutes orbitNightlyObservationInterval

Interval over which a reference test case Solar System object must be observed

3 days orbitObservationInterval

Number of detections within a single night required to define the reference test case for Solar System objects

2 int orbitObservations

Significance threshold required for moving object detections to be included in the reference test case definition

5 Sigma orbitObservationThreshold


ID: OSS-REQ-0133


Specification: Level 2 Data Products shall periodically be derived from a processing pass over the complete data set. Discussion: The baseline list of Level 2 data products is provided as the composite contents of this requirement.

Level 2 Data Product Availability

ID: OSS-REQ-0134


Specification: All Level 2 Data Products shall be made public as part of a Data Release, with releases coming at least once every time DRT1, and as soon as possible following the completion of data release processing as is consistent with verifying the applicable data quality requirements. Discussion: Data Release processing will be initiaed more frequently during the first year of the survey.



46

Uniformly calibrated and processed versions of Level 1 Data Products

ID: OSS-REQ-0135


Specification: In association with the production of the Level 2 Data Products, a data release shall also include uniformly processed and calibrated versions of all the Level 1 Data Products.

Co-added Exposures

ID: OSS-REQ-0136


Specification: The Level 2 Data Products shall include the following types of co-added Exposures, covering the full exposed area of the survey:

Template co-adds for creating Difference Exposures, per filter band

Detection co-adds for object detection, optimized for the faintest limiting magnitude; may be both multi-band and single-band

Multi-band (RGB) co-adds for visualization and EPO

Catalogs (Level 2)

ID: OSS-REQ-0137


Specification: The Level 2 Data Products shall include the following catalogs, created anew, uniformly, during the production of each Data Release:

Object

Solar System Object

Source

Forced Source In addition, the Exposure catalog shall be updated with the latest derived metadata, such as WCS and PSF.

Release Independence

ID: OSS-REQ-0138


Specification: Each Data Release shall consist of a complete reprocessing of the entire LSST data set on a uniform footing, and shall not require access to the data products of any previous Data Release to interpret. Discussion: This does not prevent some results of one Data Release from being used as a seed for an iterative refinement of some calibration or reference catalog. It does require that any data so used, e.g., from Data Release N-1, be incorporated by value as part of the contents of Data Release N.

Level 2 Data Product Quality

ID: OSS-REQ-0338


Discussion: The requirements in this area specify the scientific performance required of the LSST Level 2 data products. These are driven by the needs of the science missions in the LSST SRD.

Level 2 Catalog Accuracy



47

ID: OSS-REQ-0162


Specification: DM processing shall result in products with photometric accuracy and precision consistent with OSS-REQ-0275. DM processing shall contribute no more than an RMS error of dmL2AstroErr to point source astrometric errors in Level 2 data products. Discussion: The verification method for this requirement will be comparison with simulated inputs. Description Value Unit Name

Maximum contribution from DM to Level 2 point source astrometric errors

0.05 arcsec dmL2AstroErr

World Coordinate System Accuracy

ID: OSS-REQ-0153


Specification: WCS inaccuracies, including any refinements due to astrometric calibration, in processed images shall contribute no more than wcsAbsoluteError to the PSF FWHM of template and deep detection coadds. Description Value Unit Name

Maximum contribution from WCS inaccuracy to the PSF FWHM in template and deep detection coadds

0.1 Pixels wcsAbsoluteError

Level 2 Source-Object Association Quality

ID: OSS-REQ-0339


Specification: The Level 2 source-object association quality requirements are the same as at Level 1; see OSS-REQ-0160.

Coaddition for Deep Detection

ID: OSS-REQ-0157


Specification: False detections on the deep detection coadds caused by unremoved artifacts from moving objects, transient objects, and other instrumental artifacts (e.g. glints) shall be no more than falseDeepDetect fraction of all detections on those coadds. This specification will be tested using simulations under realistic survey conditions encountered in Commissioning. Discussion: The scientific rationale for this requirement is that statistical studies of real objects (galaxies, stars) are not overwhelmed by false detections. 0.1% is a reasonable number that achieves this. This is also a reasonable upper limit based on experience with existing surveys. Description Value Unit Name

Fraction of all detections on deep detection coadds caused by unremoved artifacts

0.1% percent falseDeepDetect

Coaddition for Templates for Subtraction

ID: OSS-REQ-0158




48

Specification: Subtraction templates shall contribute no more than a fraction templateNoiseLevelY1 to the noise of the difference images in year 1 of the survey and templateNoiseLevelY2 to the noise in subsequent years of the survey. (The variance of the difference image shall be no more than 1 + templateNoiseLevelY1 times the variance of the single visit image.) Discussion: Note that this requirement imposes a constraint on the scheduler to obtain some minumum number of exposures of each part of the sky in order for it to be met. The time variation in this requirement reflects the fact that the first-year templates may not have as many epochs available as subsequent years. Description Value Unit Name

Maximum permissible fraction of the noise level in difference images contributed by the subtraction template in Year 1

40 Percent templateNoiseLevelY1

Maximum permissible fraction of the noise level in difference images contributed by the subtraction template in Year 2 and following

20 Percent templateNoiseLevelY2

Deep Detection and Measurement Quality

ID: OSS-REQ-0161


Specification: The deep detection and measurement shall meet the implied requirements from the SRD on coadded depth, assuming the nominal survey conditions. For a galaxy with elliptical isophots and Sersic radial profile with radius ellipTestRadius and Sersic index ellipTestSersicIndex, the ellipse parameters shall be measured to an accuracy ellipAccuracy1 for galaxies detected on the coadd at a signal-to-noise ellipTestSNR1, and ellipAccuracy2 for galaxies detected on the coadd at a signal-to-noise ellipTestSNR2. Discussion: While the detection will be performed on full-depth coadds, the measurement may use techniques such as multifit, that perform measurements using individual epoch data. The verification method for this requirement will be comparison with simulated inputs. Description Value Unit Name

Galaxy radius definition for the ellipse parameter accuracy test

5 Arcsec ellipTestRadius

Galaxy Sersic index definition for the ellipse parameter accuracy test

1 float ellipTestSersicIndex

Reference SNR #1 for ellipse parameter accuracy test 10 int ellipTestSNR1

Reference SNR #2 for ellipse parameter accuracy test 1000 int ellipTestSNR2

Maximum RMS error on ellipse parameters measured for a galaxy of magnitude ellipTestSNR1

1 Percent ellipAccuracy1

Maximum RMS error on ellipse parameters measured for a galaxy of magnitude ellipTestSNR2

.01 Percent ellipAccuracy2

Object Deblending

ID: OSS-REQ-0155


Specification: The Observatory shall be capable of measuring properties of overlapping (blended) objects. Any degradation of accuracy and precision in measurement of blended objects shall be bounded



49

by the need to satisfy LSR-REQ-0043 through LSR-REQ-0046. Discussion: This requirement will give rise to a deblender software component, or an algorithm to perform simultaneous measurements of blended objects. While it is extremely difficult to write quantitative yet all-encompassing and actionable requirements on the deblender, it is understood that it is primarily an enabling component to perform measurements and statistical studies involving those measurements. Therefore, its performance will be evaluated by assessing the efficacy of measurements that employ it, and studies that depend on those measurements (e.g., in the context of weak lensing).

Level 2 Moving Object Quality

ID: OSS-REQ-0340


Specification: The Level 2 moving object quality requirements are the same as at Level 1; see OSS-REQ-0159.

Catalog Completeness and Reliability

ID: OSS-REQ-0164


Specification: The object catalog completeness and reliability shall be determined by the data management system for a variety of astrophysical objects to be specified by the LSST Science Council. Discussion: Objects that will be evaluated for completeness in the catalogs will include at least stars of a range of colors, small galaxies on both the red- and blue-sequence at a range of redshifts, and supernovae at a range of redshifts, and will be reported as a function of magnitude. Further, provisions will be made to determine completeness and reliability of more specialized object types through injection of synthetic objects into the DM pipelines during the Data Release processing (ie. not part of the live data stream).


ID: OSS-REQ-0139


Specification: The LSST Observatory shall support Level 3 Data Products that are the result of processing based on Level 1 and Level 2 Data Products, of a nature specified by users (by the provision of code and/or processing configuration data). Discussion: This is flowed down from LSR-REQ-0041.

Production

ID: OSS-REQ-0140


Specification: It shall be possible to create Level 3 Data Products either using external or internal (Data Access Center) resources, provided they meet certain requirements. LSST shall provide a set of specifications and a software toolkit to facilitate this. Level 3 Data Products may consist of new catalogs, additional data to be federated with existing catalogs, or image data.

Storage



50

ID: OSS-REQ-0141


Specification: The LSST Data Management system shall provide for the archiving of Level 3 Data Products that meet project-specified requirements.

Access

ID: OSS-REQ-0142


Specification: Archived Level 3 Data Products shall be capable of being federated with and analyzed in conjunction with Level 1, Level 2, and other Level 3 Data Products. The LSST project shall support access controls for Level 3 Data Products that allow them to be restricted to specific individuals or groups as well as released for public access.

Resource Allocation

ID: OSS-REQ-0143


Specification: The LSST project shall define a resource allocation policy and mechanism for arbitrating among the calls on Level 3 Data Product production, archiving, and analysis resources.

3.1.5.4 Internal Data Products

ID: OSS-REQ-0144



Science Data Quality Analysis

ID: OSS-REQ-0145


Specification: The facilities and software of LSST Observatory shall be designed and built so that Data Quality Analysis during operations is supported. Discussion: For example, a DQA group should be able to monitor metrics and undertake data explorations of outliers. Automated searches and monitoring of known issues (example: known systematics) during pipeline processing could provide alerts to the operator and DQA group.

WCS Reporting

ID: OSS-REQ-0146


Specification: The LSST data management system shall make available to other Observatory systems a WCS solution for each exposure. The WCS is a computational map from pixel coordinates to sky (ra, dec) coordinates, and will have an RMS error of no more than wcsReportingPrecision within a time wcsReportingLatency of the completion of data readout for a standard visit. Discussion: This is in addition to the archiving of the WCS solution as part of the metadata for each processed exposure. The purpose of this report is for the monitoring and potential recalculation of the accuracy of the mount model. The WCS reporting will be done with using the OCS publish/subscribe mechanism used for other observatory telemetry reporting.



51


Maximum RMS uncertainty on the comparison of observed and reference star positions from the real-time WCS reporting

0.2 ArcsecRMS

wcsReportingPrecision

Maximum time for the reporting of telemetry data containing WCS solutions from the completion of the readout of the data for a standard visit

60 Seconds wcsReportingLatency

3.1.6 Data Archiving ID: OSS-REQ-0167


Specification: The LSST project shall create and manage an archive of all its public data products and the raw data necessary to reproduce them. In addition, the archive shall contain all necessary engineering and calibration data for the full understanding of the performance and operation of the Observatory.

3.1.6.1 Science Sensor Raw Data

ID: OSS-REQ-0168


Specification: The LSST project shall archive all raw data acquired from the science sensor array during operation of the Observatory.

3.1.6.2 Data Products

ID: OSS-REQ-0169


Specification: The LSST project shall archive each of its Level 1 and Level 2 data products, or the complete set of inputs and provenance necessary to reproduce it, for the lifetime of the survey. Discussion: Some data products are archived, while others, such as calibrated exposures, are intended to be recreated on demand.

3.1.6.3 Calibration Data

ID: OSS-REQ-0170


Specification: The LSST project shall archive all raw data acquired from the calibration instrumentation and processes.

3.1.6.4 Engineering and Facilities Data

ID: OSS-REQ-0171


Specification: The LSST project shall archive all engineering and facility data required to (recreate the physical state of the observatory). Discussion: This is not intended to be a live copy of the EFD, but rather a periodic transfer of a copy of the live database operating at the Base Facility.

3.1.6.5 Provenance Archiving




52

Specification: The LSST project shall archive all processing provenance associated with archived data products.

3.1.6.6 Wavefront Sensor Raw Data

ID: OSS-REQ-0173


Specification: The LSST project shall archive all raw data acquired from the wavefront sensing system during operation of the Observatory.

3.1.6.7 Data Archive Lifetime

ID: OSS-REQ-0174


Specification: The LSST data archive design shall facilitate the maintenance of the archive beyond the lifetime of the survey. Discussion: The project recognizes that there will be great long-term interest in the availability of its data set. Planning for long-term data curation should be guided by funding agency policies and requirements. This is an active area of research and policy development at present, which LSST should follow as the design and construction process continues. This requirement does not commit the project to fund the operations costs of the archive beyond the lifetime of the survey. The intent here is to facilitate an orderly transition.

3.1.6.8 Redundant Backup of Archive

ID: OSS-REQ-0175


Specification: The LSST project shall ensure that a redundant and physically separate copy is maintained of the 1. raw science data; 2. raw calibration data; 3. the full engineering and facility data required to make use of the science and calibration raw data above; and 4. all science data products or the data necessary to reproduce them. Discussion: This requirement goes beyond merely using the appropriate engineering required to meet the archive reliability requirements. It requires a backup that can be used for disaster recovery. The intent is that this redundant copy will be maintained at the Base Facility. It does not have to have the access performance required of the "live" copy.

3.1.7 Data Access ID: OSS-REQ-0176


Specification: The LSST Data Management System shall provide open access to all LSST Level 1 and Level 2 Data Products, as defined in the LSST System Requirements and herein, in accordance with LSSTC Board approved policies. The LSST project shall make available open-source software for querying and processing the data products and for generating Level 3 Data Products, and limited



53

computing and storage resources for performing such analyses and productions.

3.1.7.1 Data Access Environment

ID: OSS-REQ-0177


Specification: The LSST shall provide an open-source environment for access to its public data products, including images and catalogs. Discussion: It is expected that this software will be written to be compatible with common varieties of Linux, and perhaps other widely available Unix-like operating systems. See also the "Software Development Standards" requirement elsewhere in this document. It is a design goal of the LSST Data Management software that it be portable within the family of Unix-like operating systems. It is also a goal to separate, as much as possible, the parts of the code that implement substantive image processing and astronomical algorithms from the parts with platform dependencies.

3.1.7.2 Data Distribution

ID: OSS-REQ-0178


Specification: The LSST project shall facilitate the distribution of its data products in bulk to other sites and institutions willing to host it, in accordance with LSSTC Board approved policies for data release. Discussion: This does not require the LSST project to absorb the marginal costs of the actual distribution, e.g., the provision of increased network bandwidth between the Archive Center and the external consumer.

3.1.7.3 Data Products Processing Infrastructure

ID: OSS-REQ-0179


Specification: The Data Management System shall provide at least a fraction userComputingFraction of its total capability for user-dedicated processing and user-dedicated storage, including for the generation of Level 3 data products. Discussion: This allocation does not include the resources needed to support the expected load of queries against the catalog database.

3.1.7.4 Data Products Query and Download Availability

ID: OSS-REQ-0180


Specification: The data product query and download system at each Data Access Center shall be available to end users a fraction dpAvailabilityFraction of the time, averaged over a year. Individual outages shall be no longer than dpAvailabilityOutage working days. These include both scheduled and unscheduled downtime. Description Value Unit Name



54


Minimum fraction of the time that data products are available for query and/or download, including scheduled and unscheduled downtime.

98 Percent dpAvailabilityFraction

Maximum duration of a single outage of data product access, in working days.

3 Days dpAvailabilityOutage

3.1.7.5 Data Products Query and Download Infrastructure

ID: OSS-REQ-0181


Specification: The LSST project shall provide processing, storage, and network resources for general community query and download access to LSST data products. Discussion: The resources to be provided will be based on a sizing model using representative queries derived from the key science goals of LSST.

3.1.7.6 Transient Alerts

ID: OSS-REQ-0183



Transient Alert Publication

ID: OSS-REQ-0184


Specification: Transient alerts shall be published to community alert distribution networks using community-standard protocols, to be determined during the LSST construction phase as community standards evolve. Discussion: The intent is to use a community standard like VOEvent, assuming that the standard as of the time of LSST construction meets the project's requirements.

Transient Alert Query

ID: OSS-REQ-0185


Specification: All published transient alerts, as well as all reprocessed historical alerts generated as part of a Data Release, shall be available for query. Discussion: This allows users to perform statistical analyses on alerts, which are of interest both for actually published, real-time alerts, e.g., for assessment of the quality of the real-time alert analysis, and for uniformly reprocessed alerts in Data Releases, e.g., for optimally calibrated studies of the statistics of actual astrophysical transients.

3.1.7.7 Access to Previous Data Releases

ID: OSS-REQ-0186


Specification: The LSST project shall maintain user access to the contents of Data Releases prior to the current one. However, this facility may be provided with substantially reduced performance and capability



55

compared to the access provided to the most recent Data Release. Discussion: Data Releases other than the two most recent ones are planned to be archived on tape (e.g., as database table dumps) and be accessible as bulk downloads only. End-users interested in these products are expected to use their own hardware and set up any the necessary software infrastructure (e.g., databases).

3.1.7.8 Information Security

ID: OSS-REQ-0187


Specification: The LSST project shall ensure that Personally Identifiable Information (PII) and other sensitive data relating to individuals or business relationships are protected from unauthorized disclosure, as required by law and applicable standards. Discussion: Data of this nature is not expected to be part of the science data set, but could arise in the engineering and facilities data collected as part of Observatory operations (e.g., information associated with the operations personnel). PII may also be associated with the resource management in Data Access Centers (e.g. names, addresses, etc. for researchers producing Level 3 data products).

3.2 Optical System

The LSST shall be design and constructed using the following specifications for: 1. Optical design Prescription 2. Optical Alignment and Compensation 3. Ghost Image Control 4. Stray and Scattered Light Control

3.2.1 Optical Design Specification ID: OSS-REQ-0200


Specification: The LSST optical system shall be a Mersene-Schmidt design consisting of a 3-mirror modified Paul-Baker telescope and a 4-element (3 lenses + filter) refractive corrector. Discussion: The reference optical prescription is given below with details and performance discussed in document LSE-11. The prescription contains parameters to define each surface, their separations, and clear apertures. All parameters follow the sign conventions used by the Zemax raytracing software. https://www.lsstcorp.org/docushare/dsweb/Get/LCR-14 https://www.lsstcorp.org/docushare/dsweb/Get/LSE-11

3.2.1.1 M1 Prescription

ID: OSS-REQ-0201


Specification: The surface prescription of the primary mirror (M1) shall be defined by the table of parameters m1Prescription: Description Value Unit Name

https://www.lsstcorp.org/docushare/dsweb/Get/LCR-14

https://www.lsstcorp.org/docushare/dsweb/Get/LSE-11



56


The primary mirror outer clear aperture radius shall be at least m1OuterCa.

4180.0 mm m1OuterCa

The primary mirror inner clear aperture radius shall be no more than m1InnerCa.

2558.0 mm m1InnerCa

The primary mirror radius of curvature shall be m1Radius -19835.0 mm m1Radius

The primary mirror surface conic constant shall be m1ConicConstant.

-1.2150 m1ConicConstant

The primary mirror surface 6th order aspheric coefficient shall be m1_6thAsphere

1.381e-24

mm^-5 m1_6thAsphere


ID: OSS-REQ-0202


Specification: The surface prescription of the secondary mirror (M2) shall be defined by the table of parameters m2Prescription: Description Value Unit Name

The secondary mirror (m2) outer clear aperture radius shall be m2OuterCa.

1710.0 mm m2OuterCa

The secondary mirror (m2) inner clear aperture radius shall be m2InnerCa

900.0 mm m2InnerCa

The secondary mirror surface radius of curvature shall be m2Radius.

-6788.0 mm m2Radius

The secondary mirror surface conic constant shall be m2Conic.

-0.2220 m2Conic

The secondary mirror surface 6th order aspheric coefficient shall be m2_6thAsphere.

-1.274e-20

mm^-5 m2_6thAsphere

The secondary mirror surface 8th order aspheric coefficient shall be m2_8thAsphere.

-9.680e-28

mm^-7 m2_8thAsphere


ID: OSS-REQ-0203


Specification: The surface prescription of the tertiary mirror (M3) shall be defined by the table of parameters m3Prescription: Description Value Unit Name

The tertiary mirror outer clear aperture radius shall be at least m3OuterCa.

2508.0 mm m3OuterCa

The tertiary mirror inner clear aperture radius shall be at least m3InnerCa.

550.0 mm m3InnerCa

The tertiary mirror surface radius of curvature shall be m3Radius.

-8344.5 mm m3Radius

The tertiary mirror surface conic constant shall be m3Conic. 0.1550 m3Connic

The tertiary mirror surface 6th order aspheric coefficient shall be m3_6thAsphere.

-4.500e-22

mm^-5 m3_6thAsphere

The tertiary mirror surface 8th order aspheric coefficient shall -8.150e- mm^-7 m3_8thAsphere



57


be m3_8thAsphere. 30

3.2.1.4 Mirror Spacings

ID: OSS-REQ-0204


The prescription for the separation of the successive mirror surfaces and the next optical element in the system shall be defined by the parameters in table mirrorSpacings Description Value Unit Name

The distance from the vertex of M1 to the vertex of M2 shall be m1m2Spacing

-6156.2006

mm m1m2Spacing

The distance from the vertex of M2 to the vertex of M3 shall be m2m3Spacing

6390.0006

mm m2m3Spacing

The distance from the vertex of M3 to the vertex of the first surface of L1 in the r-band shall be m2l1Spacing

-3631.273

mm m3l1Spacing

3.2.1.5 L1 Prescription

ID: OSS-REQ-0205


Specification: The prescription of the first lens (L1) shall be defined by the table of parameters l1Prescription: Description Value Unit Name

The first lens (L1) shall be fabricated from l1GlassType Fused Silica

l1GlassType

The clear aperture radius of the first lens (L1) shall be l1OuterCa

775 mm l1OuterCa

The radius of the first surface (s1) of the first lens (l1) shall be l1_s1Radius

-2824.0 mm l1_s1Radius

The center thickness of the first lens (L1) shall be l1CenThic 82.23 mm l1CenThick

The radius of the second surface (s2) of the first lens (l1) shall be l1_s2Radius


3.2.1.6 L2 Presciption

ID: OSS-REQ-0206


Specification: The prisciption of the second lens (L2) shall be defined by the table of parameters l2Prescription: Description Value Unit Name

The second lens (L2) shall be fabricated from l2GlassType Fused Silica

l2GlassType

The clear aperture radius of the second lens (L2) shall be l2OuterCa

551.0 mm l2OuterCa

The radius of the first surface (s1) of the second lens (l2) Infinite l2_s1Radius



58


shall be l2_s1Radius

The center thickness of the second lens (L2) shall be l2CenThic

30.00 mm l2CenThick

The radius of the second surface (s2) of the second lens (l2) shall be l2_s2Radius


The second surface (s2) conic constant on the second lens (L2) shall be l2_s2Conic.

-1.5700 l2_s2Conic

The second surface 6th order aspheric coefficient on the second lens shall be l2_s2_6thAsphere.

1.656e-18

mm^-5 l2_s2_6thAsphere

3.2.1.7 Filter Prescription

ID: OSS-REQ-0207


Specification: The prisciption of the filter substrates shall be defined by the table of parameters filterPrescription: Description Value Unit Name

The third lens (L3) shall be fabricated from l3GlassType Fused Silica

filterGlassType

The clear aperture radius of the filter substrates shall be filterOuterCa

378.0 mm filterOuterCa

The radius of the first surface (s1) of the filter substrates shall be filter_s1Radius

-5632.0 mm filter_s1Radius

The thicknes of the u-band filter substrate shall be filterThick_u

26.60 mm filterThick_u

The thicknes of the g-band filter substrate shall be filterThick_g

21.50 mm filterThick_g

The thicknes of the r-band filter substrate shall be filterThick_r

17.90 mm filterThick_r

The thicknes of the i-band filter substrate shall be filterThick_i

15.70 mm filterThick_i

The thicknes of the z-band filter substrate shall be filterThick_z

14.4 mm filterThick_z

The thicknes of the y-band filter substrate shall be filterThick_y

13.60 mm filterThick_y

The radius of the second surface (s2) of the u-band filter substrate shall be filter_s2Radius_u

-5530.0 mm filter_s2Radius_u

The radius of the second surface (s2) of the g-band filter substrate shall be filter_s2Radius_g

-5576.0 mm filter_s2Radius_g

The radius of the second surface (s2) of the r-band filter substrate shall be filter_s2Radius_r

-5606.0 mm filter_s2Radius_r

The radius of the second surface (s2) of the i-band filter substrate shall be filter_s2Radius_i

-5623.0 mm filter_s2Radius_i

The radius of the second surface (s2) of the z-band filter substrate shall be filter_s2Radius_z

-5632.0 mm filter_s2Radius_z

The radius of the second surface (s2) of the y-band filter substrate shall be filter_s2Radius_y

-5640.0 mm filter_s2Radius_y



59

3.2.1.8 L3 Prescription

ID: OSS-REQ-0208


Specification: The prescription of the third lens (L3) shall be defined by the table of parameters l3Prescription: Description Value Unit Name

The third lens (L3) shall be fabricated from l3GlassType Fused Silica

l3GlassType

The clear aperture radius of the third lens (L3) shall be l3OuterCa

361.0 mm l3OuterCa

The radius of the first surface (s1) of the third lens (L3) shall be l3_s1Radius


The first surface (s1) conic constant on the third lens (L3) shall be l3_s1Conic.

-0.9620 l3_s1Conic

The center thickness of the third lens (L3) shall be l3CenThic 60.00 mm l3CenThick

The radius of the second surface (s2) of the third lens (L3) shall be l3_s2Radius

13360.0 mm l3_s2Radius

3.2.1.9 Lens Spacings

ID: OSS-REQ-0209


The prescription for the separation of the successive lenses in the system shall be defined by the parameters in table lensSpacings Description Value Unit Name

The distance from the vertex of the second surface of L1 to the vertex of the first surface of L2 shall be l1_l2Spacing.

-412.642 mm l1_l2Spacing

The distance from the vertex of the second surface of L2 to the vertex of the first surface of the filter substrate shall be L2_filterSpacing.

-349.58 mm l2_filterSpacing

The distance from the vertex of the second surface of the u-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_u.

-42.40 mm L3_filterSpacing_u

The distance from the vertex of the second surface of the g-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_g.

-47.50 mm L3_filterSpacing_g

The distance from the vertex of the second surface of the r-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_r.

-51.10 mm L3_filterSpacing_r

The distance from the vertex of the second surface of the i-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_i.

-53.30 mm L3_filterSpacing_i

The distance from the vertex of the second surface of the z-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_z.

-54.60 mm L3_filterSpacing_z

The distance from the vertex of the second surface of the y-band filter substrate to the vertex of the first surface of L3 shall be L3_filterSpacing_y.

-55.40 mm L3_filterSpacing_y



60


The distance from the vertex of the second surface of L3 to the focal plane array (FPA) shall be l3_fpaSpacing.

-28.50 mm l3_fpaSpacing

3.2.2 Optical Alignment and Compensation ID: OSS-REQ-0210


Discussion: The LSST optical design has been analyzed for its ability to compensate for errors in alignment and optical fabrication. There are two "one time" compensators in the lens positions that correct for fabrication errors in radii and conic constants of the mirrors. Additionally there are 10 degrees of freedom between the secondary mirror and the camera optics for alignment. The specifications below constrain the minimum range of adjustment for each compensator.

3.2.2.1 Dynamic Alignment and Figure Compensation

ID: OSS-REQ-0211


Specification: The LSST optical shall dynamically compensate for deflections and deformation caused by gravity and thermal gradients.

Secondary (M2) Adjustement

ID: OSS-REQ-0212


Specification: The rigid body position of the secondary mirror shall be adjustable in 5 degrees of freedom (decenter x-y, piston along the optical axis, tilt x-y) over a range specified in the table below. Description Value Unit Name

The range of motion of the secondary on either side of its nominal design position in the x-direction.

10 mm x-decenterRangeM2

The range of motion of the secondary on either side of its nominal design position in the y-direction.

10 mm y-decenterRangeM2

The range of motion of the secondary on either side of its nominal design position in the z-direction.

10 mm z-positionRangeM2

The range of tilt of the secondary on either side of its nominal design position about the x-axis.

0.1 Degrees x-tiltRangeM2

The range of tilt of the secondary on either side of its nominal design position about the y-axis.

0.1 Degrees y-tiltRangeM2

Camera Adjustment

ID: OSS-REQ-0213


Specification: The rigid body position of the camera optical system (3 lenses, filter and focal plane) shall adjustable in 5 degrees of freedom over a range specified in the table below. Description Value Unit Name

The range of motion of the camera on either side of its nominal design position in the x-direction.

10 mm x-decenterRangeCa

m The range of motion of the camera on either side of its 10 mm y-



61


nominal design position in the y-direction. decenterRangeCam

The range of motion of the camera on either side of its nominal design position in the z-direction.

10 mm z-positionRangCcam

The range of tilt of the camera on either side of its nominal design position about the x-axis.

0.1 Degrees x-tiltRangeCam

The range of tilt of the camera on either side of its nominal design position about the y-axis.

0.1 Degrees y-tiltRangeCam

3.2.2.2 One-time Static Compensation

ID: OSS-REQ-0214


Specification: The LSST optical system shall provide for one time compensation for the as-built prescriptions (radii and conic constant) on the three mirror surfaces.

L3+FPA to L2 Spacing

ID: OSS-REQ-0215


Specification: The spacing of the FPA+L3 (+ optionally the filter) to L2 shall be adjustable one time over a range of l3L2Comp about its nominal design spacing. Discussion: Sensitivity analysis show that the filter can be optionally allowed to move with the FPA+L3 group when making this adjustment within system performance. Description Value Unit Name

The minimum adjustment range of the L3-L2 spacing about either side of the nominal design spacing as a one-time compensator.

5 mm l3L2Comp

L3-FPA Spacing

ID: OSS-REQ-0216


Specification: The spacing between L3 and the FPA shall be adjustable one time within the range of fpaL3Comp about the nominal design spacing. Description Value Unit Name

The minimum adjustment range of the FPA+L3 spacing about either side of the nominal design spacing as a one-time compensator.

3.5 mm fpaL3Comp

3.2.2.3 Wavefront Sensing Functions

ID: OSS-REQ-0217


Specification: The LSST optical system shall be able to determine the self induced wavefront aberrations caused by misalignment of the secondary mirror and camera along with figure distortions on the surfaces of the 3 telescope mirrors.



62

Wavefront Estimation Range

ID: OSS-REQ-0218


Specification: Each wavefront sensor shall provide sufficient information to be able to reconstruct the equivalent of up to the first 22 Zernike modes of wavefront error at the telescope pupil.

Wavefront Sensing on Sky Efficiency

ID: OSS-REQ-0219


Specification: The wavefront sensors shall supply data for the estimation of the wavefront over at least wfsSkyEfficiency of all visits regardless of visit filter. Discussion: The fraction of sky coverage is based on the ability to recover the coefficients for Zernikie polynomials (or equivalent) Z4 - Z22 using the standard Noll notation. Description Value Unit Name

The minimum fraction of visits where valid wavefront sensing data can be obtained.

95 Percent wfsSkyEfficiency

Wavefront Sensor FPA Geometry

ID: OSS-REQ-0220


Specification: For the purpose of determining the optical alignment and mirror surface errors the LSST optical system shall use 4 wavefront sensors located near the corners of the inscribed square to the 3.5 degree FOV.

WFS Data Archiving and Buffering

ID: OSS-REQ-0221


Specification: For the purposes of archiving and buffering the wavefront sensor imaging data shall be treated the same as science image data.

3.2.3 Stray and Scattered Light Control ID: OSS-REQ-0224


Specification: All sources of stray and scattered light shall be minimized by design to the extent that it is feasible using standard practices and surface treatments.

3.2.3.1 Ghost Image Control

ID: OSS-REQ-0222


Specification: The effects of image ghosts in single visits shall not increase the errors in photometric repeatability of non-varying sources by more than ghostPhotErr above the limit set by the calculated noise (photon statistics and other measured noise sources). Specification: No more than ghostGradientArea % of image area in a single visit shall be affected by ghosts with surface brightness gradients on 1 arcsec scale exceeding 1/3 of the sky noise.



63

Discussion: These requirements limit the impact of ghosting. The first requirement effectively places an upper limit on the precision of sky brightness determination (~1 % for design specification), which may be affected by ghosts. The second requirement is derived from the effects of ghosting on shape systematics on the scale of faint galaxies. Description Value Unit Name

The increase in photometric error over repeated measurements caused by the effects of image ghosts shall not exceed ghostPhotErr.

10.0 Percent ghostPhotErr

The maximum scientific image area that can be affected by 1 arcsec scale ghost gradients exceeding 1/3 of the sky noise shall be no more than ghostGradientArea.

1.0 Percent ghostGradientArea

Lens Anti-Reflection Coating

ID: OSS-REQ-0223


Specification: The reflection off the any transmissive optical surface shall be less than lensReflection over the entire operating wavelength rage of the LSST system. Discussion: These specifications constrain the intensity of the 2-reflection ghost images. Description Value Unit Name

The maximum allowable reflection fraction from any lens surface after AR coating.

2 Percent lensReflection

3.2.3.2 Lunar Stray Light

ID: OSS-REQ-0225


Specification: All sources of stray light that contribute more than strayThreshold relative to the natural sky background within lunarAngle shall be identified and treated to minimize their impact on diffuse stray light. Description Value Unit Name

The threshold above which surfaces need to be identified and treated for minimization of stray light.

10 Percent strayThreshold

The limiting angle from the moon with respect to the optical axis where surface contributions to stray light need to be identified.

45 Degrees lunarAngle

3.2.3.3 Optical Baffing

ID: OSS-REQ-0226


Specification: The optical system shall be baffled such that there are no direct specular paths to the focal plane outside the nominal field of view from celestial sources.

3.2.4 Image Quality ID: OSS-REQ-0227




64

The delivered PSF image quality specifications flow directly from the SRD/LSR.

3.2.4.1 System Image Quality

ID: OSS-REQ-0228


Specification: The delivered image quality of isolated bright unresolved point sources in images from a single visit shall have the properties specified in the table imageQuality. Discussion: The design point specified here deviates from the SRD design specification due to the conflict between image quality and charge spreading in thick detectors, needed to achieve the desired z-band and y-band sensitivities. The adopted base system image quality of 0.4 arcsec FWHM is within the allowed value set by the SRD minimum specification. Description Value Unit Name

The maximum RSS contribution from the LSST system to the atmospheric seeing referenced at zenith or airmass (sec(zd)) = 1.

0.40 ArcsecFWHM

SysIm_0

The maximum RSS contribution from the LSST system to the atmospheric seeing referenced at zenith distance of 45 degrees or airmass (sec(zd)) = 1.4.

0.49 ArcsecFWHM

SysIm_45

The maximum RSS contribution from the LSST system to the atmospheric seeing referenced at zenith distance of 60 degrees or airmass (sec(zd)) = 2.0.

0.60 ArcsecFWHM

SysIm_60

Delivered image quality increase factor allowed over SF1 fraction of the field of view.

1.1 float SX

The maximum fraction of the field of view that can exceed the delivered image size by a factor of SX.

10 Percent SF1

The minimum number of pixels across the FWHM of the delivered PSF under median atmospheric conditions (0.6 arcsec FWHM) shall be

3 Pixels PSFSample

The system image budget is allowed to degrade through the three reference zenith distances (zd) as sec(zd)^ ImFunc.

0.6 ImFunc

The maximum radius of the PSF spatial profile for a fiducial delivered image quality of 0.69 arcsec FWHM containing 80 percent encircled energy shall be no more than SR1.

0.76 Arcsec SR1


1.17 Arcsec SR2


1.62 Arcsec SR3

3.2.4.2 Image Quality Subsystem Allocations

ID: OSS-REQ-0229


Specification: The telescope and camera subsystems shall use the RSS budget allocations defined by imgBudgetTel and imgBudgetCam in the table below.



65


The portion of the system image budget allocated to the Telescope is imgBudgetTel.

0.25 ArcsecFWHM

imgBugetTel

The portion of the system image budget allocated to the Camera is imgBudgetCam.

0.30 ArcsecFWHM

imgBugetTCam

3.2.4.3 Off Zenith Image Degradation

ID: OSS-REQ-0230


Specification: The system image quality is allowed to degrade as a function of Zenith Distance (angle) at the same rate as the atmospheric turbulent seeing. The canonical dependence on zenith distance is given as sec(ZD)

0.6.

Discussion: The design specification for the image quality requires that, for the median atmospheric seeing, the system contribution to the delivered image quality never exceeds 15%. This requirement should be fulfilled irrespective of the airmass, which limits the seeing degradation due to hardware away from the zenith (e.g. due to gravity load). Assuming that the atmospheric seeing increases with airmass, X, as X^0.6 , the design specification for the allowed error budget due to system is 0.52 arcsec at airmass of 2 and for the median seeing conditions (0.42 arcsec for X=1.4).

3.2.4.4 Image Pixel Sampling

ID: OSS-REQ-0231


Specification: The image sampling shall be pixelSize. Description Value Unit Name

The maximum physical pixel size needed to achieve critical PSF sampling in the reference median seeing conditions.

10.0 Microns pixelSize

3.2.5 Image Ellipticity ID: OSS-REQ-0232


Discussion: The image ellipticity performance parameters specified here flow directly from the SRD/LSR without any further derivation. Monte Carlo analysis of the optical system using the component tolerances derived from the image quality budget shows that these ellipticity specifications are met (see Document-1361). Thus, the ellipticity specifications detailed here are held at the System Level and do not flow down to either the camera or telescope subsystems. https://www.lsstcorp.org/docushare/dsweb/Get/Document-1361

3.2.5.1 Single Image PSF Ellipticity

ID: OSS-REQ-0233


Specification: The Point spread function ellipticity of bright isolated unresolved sources in images from a single r-band or i-band visit shall have the properties specified in the table imageEllipticity below. Discussion: These specifications apply to single isolated unresolved sources as delivered to and




66

recorded by the LSST imaging system. Description Value Unit Name

The maximum median raw PSF ellipticity over the full field of view in a single 15 second exposure for bright isolated non-saturated stars.

0.04 Ellipticity SE1

The maximum PSF raw ellipticity limit.

0.07 Ellipticity SE2

The fraction of PSF ellipticity measurements allowed to exceed the ellipticity outlier limit for bright isolated non-saturated stars.

5 Percent EF1

The maximum residual ellipticity correlation amplitude over 1 arcmin scales.

2.0e-4 SE3

The maximum residual ellipticity correlation amplitude over 5 arcmin scales.

5.0e-7 SE4

The maximum median residual ellipticity amplitude outlier limit on scales less than or equal to 1 arcmin.

4.0e-4 SE5

The maximum median residual ellipticity amplitude outlier limit on scales between 1 and 5 arcmin.

1.0e-6 SE6

Fraction of allowed PSF measurements of isolated bright stars to exceed the ellipticity residual correlation amplitude outlier limit.

10 Percent EF2

3.2.5.2 10-year Ellipticity Residuals

ID: OSS-REQ-0234


Specification: Over the total number of visits in the full set of survey data (or 10 year equivalent stack), the residual ellipticity correlations of bright isolated point sources in the r-band or i-band, after correction, shall have the properties defined in the overallEllipticity table below. Description Value Unit Name

Median residual PSF ellipticity correlations averaged over an arbitrary field of view for separations less than 1 arcmin shall be no greater than TE1.

2.0e-5 TE1

Median residual PSF ellipticity correlations averaged over an arbitrary field of view for separations less than 5 arcmin shall be no greater than TE2.

1.0e-7 TE2

The outlier limit on the PSF ellipticity correlation residuals on 1 arcminute scales shall be no more than TE3.

4.0e-5 TE3

The outlier limit on the PSF ellipticity correlation residuals on 5 arcminute scales shall be no more than TE4.

2.0e-7 TE4

The fraction of PSF ellipticity correlation residuals that can 15 Percent TF1



67


exceed the outlier limits on 1 and 5 arcminutes scales over an arbitrary field of view shall be no more than TF1.

3.3 System Throughput

The LSST system throughput shall allow efficient collection of the science data over a wide range of wavelengths, from near the atmospheric cutoff in the blue to the band gap of silicon in the red.

3.3.1 Filter Response ID: OSS-REQ-0235


Specification: The response function of each filter integrated over the incident beam in the center 100mm circle shall lie within the defined upper and lower response envelope defined below. Discussion: The LSST filter band passes are defined below by three sets of wavelengths specifying the nominal trapezoidal shape for the nominal bandpass, the upper envelope, and lower envelope. Note: The response functions for the baseline ideal filters are contained in Collection-1777 in the LSST document archive (see collection link below) https://www.lsstcorp.org/docushare/dsweb/View/Collection-1777

3.3.1.1 Filter Out of Band Constraints

ID: OSS-REQ-0237


Specification: Each of the 6 defined filters must block its out of band transmission according to the specifications in the table below. Discussion: For leakage that occurs in the wavelength region beyond 1050 the response of 200 micron thick silicon at -100 C can be multiplied against the filter response in the total integrated leak evaluation. Description Value Unit Name

The average leakage in any 10nm segment between 300-1200nm outside the wavelength span one FWHM from the cetral wavelength shall be no more than fLeak_10nm.

0.01 Percent fLeak_10nm

The integrated over all wavelengths between 300-1200nm outside the wavelength span between the first time the filter response goes below 0.1% of the peak the total leakage shall not exceeded fleakTotal.

0.05 Percent fLeakTotal

3.3.1.2 Filter Response Uniformity

ID: OSS-REQ-0238


Specification: The filter response function as measured in any 100mm circle shall vary smoothly as a function of radius by no more than filtUniformity from the measured response in the central 100mm circle. Description Value Unit Name

The maximum filter response uniformity variation. 2.5% Percent filtUniformity




68

3.3.1.3 In-band Ripple

ID: OSS-REQ-0239


Specification: The in-band filter response function shall have a semi-amplitude peak-to-valley ripple of no more than maxFiltRipple about the in-band mean response. Discussion: The in-band region for measuring ripple is defined as the wavelength segment between the red and blue upper envelope at the 100% relative response wavelengths and the red and blue lower envelope at the 100% relative response wavelengths for positive and negative going excursions respectively. Description Value Unit Name

The maximum semi-amplitude peak-to-valley ripple. 3 Percent maxFiltRipple

3.3.1.4 u-band Response

ID: OSS-REQ-0240


Specification: The response relative to the in-band average (as measured between uLowerBlue_100 and uLowerRed_100) of the u-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative u-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal u-band zero relative response wavelength on the blue side.

309 nm uNomBlue_0

The nominal u-band 50% relative response wavelength on the blue side..

321 nm uNomBlue_50

The nominal u-band 100% relative response wavelength on the blue side.

334 nm uNomBlue_100

The nominal u-band 100% relative response wavelength on the red side.

379 nm uNomRed_100

The nominal u-band 50% relative response wavelength on the red side.

391 nm uNomRed_50

The nominal u-band zero relative response wavelength on the red side.

404 nm uNomRed_0


The lower envelope u-band zero relative response wavelength on the blue side.

311 nm uLowerBlue_0

The lower envelope u-band 50% relative response wavelength on the blue side.

323 nm uLowerBlue_50

The lower envelope u-band 100% relative response wavelength on the blue side.

336 nm uLowerBlue_100

The lower envelope u-band 100% relative response wavelength on the red side.

377 nm uLowerRed_100

The lower envelope u-band 50% relative response wavelength on the red side.

389 nm uLowerRed_50



69


The lower envelope u-band zero relative response wavelength on the red side.

402 nm uLowerRed_0

The upper envelope u-band zero relative response wavelength on the blue side.

306 nm uUpperBlue_0

The upper envelope u-band 50%relative response wavelength on the blue side.

318 nm uUpperBlue_50

The upper envelope u-band 100% relative response wavelength on the blue side.

331 nm uUpperBlue_100

The upper envelope u-band 100% relative response wavelength on the red side.

382 nm uUpperRed_100

The upper envelope u-band 50% relative response wavelength on the red side.

394 nm uUpperRed_50

The upper envelope u-band zero relative response wavelength on the red side.

407 nm uUpperRed_0

3.3.1.5 g-band Response

ID: OSS-REQ-0241


Specification: The response relative to the in-band average (as measured between gLowerBlue_100 and gLowerRed_100) of the g-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative g-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal g-band zero relative response wavelength on the blue side.

390 nm gNomBlue_0

The nominal g-band 50% relative response wavelength on the blue side.

402 nm gNomBlue_50

The nominal g-band 100% relative response wavelength on the blue side.

415 nm gNomBlue_100

The nominal g-band 100% relative response wavelength on the red side.

540 nm gNomRed_100

The nominal g-band 50% relative response wavelength on the red side.

552 nm gNomRed_50

The nominal g-band zero relative response wavelength on the red side.

565 nm gNomRed_0


The lower envelope g-band zero relative response wavelength on the blue side.

392 nm gLowerBlue_0

The lower envelope g-band 50% relative response wavelength on the blue side.

404 nm gLowerBlue_50

The lower envelope g-band 100% relative response wavelength on the blue side.

417 nm gLowerBlue_100

The lower envelope g-band 100% relative response wavelength on the red side.

537 nm gLowerRed_100

The lower envelope g-band 50% relative response 550 nm gLowerRed_50



70


wavelength on the red side.

The lower envelope g-band zero relative response wavelength on the red side.

562 nm gLowerRed_0

The upper envelope g-band zero relative response wavelength on the blue side.

387 nm gUpperBlue_0

The upper envelope g-band 50% relative response wavelength on the blue side.

399 nm gUpperBlue_50

The upper envelope g-band 100% relative response wavelength on the blue side.

412 nm gUpperBlue_100

The upper envelope g-band 100% relative response wavelength on the red side.

542 nm gUpperRed_100

The upper envelope g-band 50% relative response wavelength on the red side.

555 nm gUpperRed_50

The upper envelope g-band zero relative response wavelength on the red side.

567 nm gUpperRed_0

3.3.1.6 r-band Response

ID: OSS-REQ-0242


Specification: The response relative to the in-band average (as measured between rLowerBlue_100 and rLowerRed_100) of the r-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative r-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal r-band zero relative response wavelength on the blue side.

540 nm rNomBlue_0

The nominal r-band 50% relative response wavelength on the blue side.

552 nm rNomBlue_50

The nominal r-band 100% relative response wavelength on the blue side.

565 nm rNomBlue_100

The nominal r-band 100% relative response wavelength on the red side.

679 nm rNomRed_100

The nominal r-band 50% relative response wavelength on the red side.

691 nm rNomRed_50

The nominal r-band zero relative response wavelength on the red side.

704 nm rNomRed_0


The lower envelope r-band zero relative response wavelength on the blue side.

542 nm rLowerBlue_0

The lower envelope r-band 50% relative response wavelength on the blue side.

555 nm rLowerBlue_50

The lower envelope r-band 100% relative response wavelength on the blue side.

567 nm rLowerBlue_100

The lower envelope r-band 100% relative response wavelength on the red side.

676 nm rLowerRed_100



71


The lower envelope r-band 50% relative response wavelength on the red side.

689 nm rLowerRed_50

The lower envelope r-band zero relative response wavelength on the red side.

701 nm rLowerRed_0

The upper envelope r-band zero relative response wavelength on the blue side.

537 nm rUpperBlue_0

The upper envelope r-band 50% relative response wavelength on the blue side.

550 nm rUpperBlue_50

The upper envelope r-band 100% relative response wavelength on the blue side.

562 nm rUpperBlue_100

The upper envelope r-band 100% relative response wavelength on the red side.

681 nm rUpperRed_100

The upper envelope r-band 50% relative response wavelength on the red side.

694 nm rUpperRed_50

The upper envelope r-band zero relative response wavelength on the red side.

706 nm rUpperRed_0

3.3.1.7 i-band Response

ID: OSS-REQ-0243


Specification: The response relative to the in-band average (as measured between rLowerBlue_100 and rLowerRed_100) of the r-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative i-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal i-band zero relative response wavelength on the blue side.

679 nm iNomBlue_0

The nominal i-band 50% relative response wavelength on the blue side.

691 nm iNomBlue_50

The nominal i-band 100% relative response wavelength on the blue side.

704 nm iNomBlue_100

The nominal i-band 100% relative response wavelength on the red side.

806 nm iNomRed_100

The nominal i-band 50% relative response wavelength on the red side.

818 nm iNomRed_50

The nominal i-band zero relative response wavelength on the red side.

831 nm iNomRed_0


The lower envelope i-band zero relative response wavelength on the blue side.

681 nm iLowerBlue_0

The lower envelope i-band 50% relative response wavelength on the blue side.

694 nm iLowerBlue_50

The lower envelope i-band 100% relative response wavelength on the blue side.

706 nm iLowerBlue_100

The lower envelope i-band 100% relative response 803 nm iLowerRed_100



72


wavelength on the red side.

The lower envelope i-band 50% relative response wavelength on the red side.

816 nm iLowerRed_50

The lower envelope i-band zero relative response wavelength on the red side.

828 nm iLowerRed_0

The upper envelope i-band zero relative response wavelength on the blue side.

676 nm iUpperBlue_0

The upper envelope i-band 50% relative response wavelength on the blue side.

689 nm iUpperBlue_50

The upper envelope i-band 100% relative response wavelength on the blue side.

701 nm iUpperBlue_100

The upper envelope i-band 100% relative response wavelength on the red side.

808 nm iUpperRed_100

The upper envelope i-band 50% relative response wavelength on the red side.

821 nm iUpperRed_50

The upper envelope i-band zero relative response wavelength on the red side.

833 nm iUpperRed_0

3.3.1.8 z-band Response

ID: OSS-REQ-0244


Specification: The response relative to the in-band average (as measured between zLowerBlue_100 and zLowerRed_100) of the z-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative z-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal z-band zero relative response wavelength on the blue side.

806 nm zNomBlue_0

The nominal z-band 50% relative response wavelength on the blue side.

818 nm zNomBlue_50

The nominal z-band 100% relative response wavelength on the blue side.

831 nm zNomBlue_100

The nominal z-band 100% relative response wavelength on the red side.

910 nm zNomRed_100

The nominal z-band 50% relative response wavelength on the red side.

922 nm zNomRed_50

The nominal z-band zero relative response wavelength on the red side.

935 nm zNomRed_0


The lower envelope z-band zero relative response wavelength on the blue side.

808 nm zLowerBlue_0

The lower envelope z-band 50% relative response wavelength on the blue side.

821 nm zLowerBlue_50

The lower envelope z-band 100% relative response wavelength on the blue side.

833 nm zLowerBlue_100



73


The lower envelope z-band 100% relative response wavelength on the red side.

909 nm zLowerRed_100

The lower envelope z-band 50% relative response wavelength on the red side.

921 nm zLowerRed_50

The lower envelope z-band zero relative response wavelength on the red side.

934 nm zLowerRed_0

The upper envelope z-band zero relative response wavelength on the blue side.

803 nm zUpperBlue_0

The upper envelope z-band 50% relative response wavelength on the blue side.

816 nm zUpperBlue_50

The upper envelope z-band 100% relative response wavelength on the blue side.

828 nm zUpperBlue_100

The upper envelope z-band 100% relative response wavelength on the red side.

914 nm zUpperRed_100

The upper envelope z-band 50% relative response wavelength on the red side.

926 nm zUpperRed_50

The upper envelope z-band zero relative response wavelength on the red side.

939 nm zUpperRed_0

3.3.1.9 y-band Response

ID: OSS-REQ-0245


Specification: The response relative to the in-band average (as measured between yLowerBlue_100 and yLowerRed_100) of the y-band filter shall lie between the upper and lower envelopes defined in the tables below. Discussion: The target relative y-band response is defined by the nominal parameters below. Description Value Unit Name

The nominal y-band zero relative response wavelength on the blue side.

918 nm yNomBlue_0

The nominal y-band 50%relative response wavelength on the blue side.

930 nm yNomBlue_50


943 nm yNomBlue_100


INDEF nm yNomRed_100


N/A nm yNomRed_50

The nominal y-band zero relative response wavelength on the blue side.

N/A nm yNomRed_0


The lower envelope y-band zero relative response wavelength on the blue side.

919 nm yLowerBlue_0

The lower envelope y-band 50%relative response wavelength on the blue side.

931 nm yLowerBlue_50

The lower envelope y-band 100%relative response 944 nm yLowerBlue_100



74


wavelength on the blue side.

The lower envelope y-band 100%relative response wavelength on the red side.

1057 nm yLowerRed_100

The lower envelope y-band 50% relative response wavelength on the red side.

1069 nm yLowerRed_50

The lower envelope y-band zero relative response wavelength on the red side.

1082 nm yLowerRed_0

The upper envelope y-band zero relative response wavelength on the blue side.

914 nm yUpperBlue_0

The upper envelope y-band 50% relative response wavelength on the blue side.

926 nm yUpperBlue_50

The upper envelope y-band 100% relative response wavelength on the blue side.

939 nm yUpperBlue_100

The upper envelope y-band 100% relative response wavelength on the red side.

INDEF nm yUpperRed_100

The upper envelope y-band 50% relative response wavelength on the red side.

N/A nm yUpperRed_50

The upper envelope y-band zero relative response wavelength on the red side.

N/A nm yUpperRed_0

3.3.2 Optical Throughput ID: OSS-REQ-0246


Discussion: The instantaneous throughput requirements specified here define sensitivity performance of the overall system components required to meet the limiting magnitude specified in the LSST System Requirements. These requirements include the response definitions of the six LSST filters, and the total system throughput integrals for each filter. The total system throughput integrals are allocated to the camera and telescope subsystems as a percentage throughput specified at three critical wavelengths for each filter. TBR Throughput requirements are being reviewed (see Document-11267) and will be made consistent with the filter definitions above.

3.3.2.1 Total Optical Throughput

ID: OSS-REQ-0247


Specification: Averaged over the 10-year survey period, the total system response integral over a given filter bandpass shall meet or exceed the following specified parameters for each of the LSST's six filters defined previously. Discussion: The system response includes the efficiency of photon detection, lens and mirror coating performances, and the transmission of the atmosphere referenced at zenith under nominal conditions found at the Cerro Pachon site. https://www.lsstcorp.org/docushare/dsweb/Get/Document-8857

u-Band Throughput





75


The lower wavelength limit (5% filter response) for the system u-band response shall be

318.5 nm uLambdaLower

The reference (equivalent to the effective response weighted mean) u-band response shall be

365.5 nm uLambdaRef

The upper wavelength limit (5% percent filter response) for the system u-band response shall be

405.2 nm uLambdaUpper

The system response efficiency, less filter, at the u-band lower limit wavelength, uLambdaLower, shall be at least

8.8 Percent uThroughputLower

The system response efficiency, less filter, at the u-band reference wavelength, uLambdaRef, shall be at least

21.7 Percent uThroughputRef

The system response efficiency, less filter, at the u-band upper limit wavelength, uLambdaUpper, shall be at least

30.5 Percent uThroughputUpper

The integrated u-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.0411 - uSysIntegral

g-band Throughput

ID: OSS-REQ-0249



The lower wavelength limit (5% filter response) for the system g-band response shall be

387.5 nm gLambdaLower

The reference (equivalent to the effective response weighted mean) g-band response shall be

480.4 nm gLambdaRef

The upper wavelength limit (5% percent filter response) for the system g-band response shall be

559.2 nm gLambdaUpper

The system response efficiency, less filter, at the g-band lower limit wavelength, gLambdaLower, shall be at least

44.0 Percent gThroughputLower

The system response efficiency, less filter, at the g-band reference wavelength, gLambdaRef, shall be at least

44.0 Percent gThroughputRef

The system response efficiency, less filter, at the g-band upper limit wavelength, gLambdaUpper, shall be at least

44.0 Percent gThroughputUpper

The integrated g-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.1387 - gSysIntegral

r-band Throughput

ID: OSS-REQ-0250


Discussion: The r-band specifications for the system integral and average throughput at each of the reference wavelengths deviate from those required to meet the SRD. This is because when losses are accounted for on all optical surface it is not feasible to meet the SRD design requirement. The system requirement specified here meets the SRD minimum r-band limiting magnitude requirements, but fall short of the design requirement by 0.25mag.



76


The lower wavelength limit (5% filter response) for the system r-band response shall be

534.2 nm rLambdaLower

The reference (equivalent to the effective response weighted mean) r-band response shall be

622.4 nm rLambdaRef

The upper wavelength limit (5% filter response) for the system r-band response shall be

701.0 nm rLambdaUpper

The system response efficiency, less filter, at the r-band lower limit wavelength, rLambdaLower, shall be at least

50.0 Percent rThroughputLower

The system response efficiency, less filter, at the r-band reference wavelength, rLambdaRef, shall be at least

50.0 Percent rThroughputRef

The system response efficiency, less filter, at the r-band upper limit wavelength, rLambdaUpper, shall be at least

50.0 Percent rThroughputUpper

The integrated r-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.1134 - rSysIntegral

i-band Throughput

ID: OSS-REQ-0251



The lower wavelength limit (5% filter response) for the system i-band response shall be

670.1 nm iLambdaLower

The reference (equivalent to the effective response weighted mean) i-band response shall be

754.1 nm iLambdaRef

The upper wavelength limit (5% filter response) for the system i-band response shall be

837.0 nm iLambdaUpper

The system response efficiency, less filter, at the i-band lower limit wavelength, iLambdaLower, shall be at least

39.2 Percent iThroughputLower

The system response efficiency, less filter, at the i-band reference wavelength, iLambdaRef, shall be at least

39.2 Percent iThroughputRef

The system response efficiency, less filter, at the i-band upper limit wavelength, iLambdaUpper, shall be at least

39.2 Percent iThroughputUpper

The integrated i-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.0674 - iSysIntegral

z-band Throughput

ID: OSS-REQ-0252



The lower wavelength limit (5% filter response) for the system z-band response shall be

798.9 nm zLambdaLower

The reference (equivalent to the effective response weighted mean) z-band response shall be

868.1 nm zLambdaRef



77

The upper wavelength limit (5% filter response) for the system z-band response shall be

948.3 nm zLambdaUpper

The system response efficiency, less filter, at the z-band lower limit wavelength, zLambdaLower, shall be at least

30.8 Percent zThroughputLower

The system response efficiency, less filter, at the z-band reference wavelength, zLambdaRef, shall be at least

30.8 Percent zThroughputRef

The system response efficiency, less filter, at the z-band upper limit wavelength, zLambdaUpper, shall be at least

30.8 Percent zThroughputUpper

The integrated z-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.0376 - zSysIntegral

y-band Throughput

ID: OSS-REQ-0253


Note: The current project y-band baseline is "y4". Description Value Unit Name

The lower wavelength limit (5% filter response) for the system y-band response shall be

955.3 nm yLambdaLower

The reference (equivalent to the effective response weighted mean) y-band response shall be

1005.0 nm yLambdaRef

The upper wavelength limit (5% filter response) for the system y-band response shall be

1100.0 nm yLambdaUpper

The system response efficiency, less filter, at the y-band lower limit wavelength, yLambdaLower, shall be at least

15.4 Percent yThroughputLower

The system response efficiency, less filter, at the y-band reference wavelength, yLambdaRef, shall be at least

6.4 Percent yThroughputRef

The system response efficiency, less filter, at the y-band upper limit wavelength, yLambdaUpper, shall be at least

0.0 Percent yThroughputUpper

The integrated y-band throughput, not including the atmosphere response, over all wavelengths (300-1200nm) shall be at least

0.0110 - ySysIntegral

3.3.2.2 Telescope Throughput Allocation

ID: OSS-REQ-0254


Specification: The 10-year mean throughput response of the telescope (3-mirror) system averaged over each of the 6 filter passbands between their 90% response points defined above shall be meet the specifications in the table of attributes below. Discussion: Based on the performance of aged protected aluminum coatings. Description Value Unit Name

When averaged over the u-band filter the telescope throughput shall be at least

67.6 Percent telAveThroughput_u



78


When averaged over the g-band filter the telescope throughput shall be at least

68.3 Percent telAveThroughput_g

When averaged over the r-band filter the telescope throughput shall be at least

65.9 Percent telAveThroughput_r

When averaged over the i-band filter the telescope throughput shall be at least

59.2 Percent telAveThroughput_i

When averaged over the z-band filter the telescope throughput shall be at least

59.0 Percent telAveThroughput_z

When averaged over the y4-band filter the telescope throughput shall be at least

68.6 Percent telAveThroughput_y4

3.3.2.3 Camera Throughput Allocation

ID: OSS-REQ-0255


Specification: The 10-year mean throughput response of the camera system, including the lenses, filters, and sensors, averaged over each of the 6 filter passbands between their 90% response points defined above shall be specified by the table of attributes below. Discussion: The total camera throughput specifications must include the constraints imposed by the specifications for the filter bandpasses and anti-reflection coating performance. Description Value Unit Name

When averaged over the u-band filter the camera throughput shall be at least

30.3 Percent camAveThroughput_u

When averaged over the g-band filter the camera throughput shall be at least

59.5 Percent camAveThroughput_g

When averaged over the r-band filter the camera throughput shall be at least

63.9 Percent camAveThroughput_r

When averaged over the i-band filter the camera throughput shall be at least

61.0 Percent camAveThroughput_i

When averaged over the z-band filter the camera throughput shall be at least

48.5 Percent camAveThroughput_z

When averaged over the y4-band filter the camera throughput shall be at least

10.1 Percent camAveThroughput_y4

3.3.2.4 Throughput variation

ID: OSS-REQ-0256


Specification: The variation of system throughput, defined as the RMS/Mean, over all science pixels within the 3.5 degree FOV shall meet the performance defined in the table maxThroughputVariation below for each filter band. Discussion: The performance values defined here are set to meet the allowed variation in limiting magnitude (LSR-0109). These values assume a Gaussian distribution convolved with the field dependent effective aperture caused by vignetting. These specifications are TBR.



79


The throughput variation in the u-band shall be no more than uThroughputVar.

0.176 uThroughputVar

The throughput variation in the g-band shall be no more than gThroughputVar.

0.235 gThroughputVar

The throughput variation in the r-band shall be no more than rThroughputVar.

0.260 rThroughputVar

The throughput variation in the i-band shall be no more than iThroughputVar.

0.259 iThroughputVar

The throughput variation in the z-band shall be no more than zThroughputVar.

0.262 zThroughputVar

The throughput variation in the y-band shall be no more than yThroughputVar.

0.260 yThroughputVar

3.3.3 10-year Integrated Throughput ID: OSS-REQ-0258


Specification: Integrated performance of the system to meet the 10 year survey requirements. Discussion: These requirements deal mostly with fill factor and other losses to the focal plane coverage that impact the integrated 10-year depth performance. Other terms, like down time, are allocated in the system availability requirements.

3.3.3.1 Focal Plane Coverage

ID: OSS-REQ-0259


Specification: The base design coverage of the imaging area shall comply with the specifications detailed in the table below. Description Value Unit Name

The nominal geometric area of the focal plane covered by science grade imaging devices with sciFillFactor coverage shall be at least equivalent to a 3.5 degree circle (TBR).

9.6 SquareDegrees

fpaScienceArea

The area covered by science grade imaging devices within the nominal 3.5 degree circular FOV shall be at least

85.0 Percent fpaFillFactor

The fill factor of active pixels in the area covered by science grade imaging devices shall be at least

90.0 Percent sciFillFactor

3.3.3.2 Focal Plane Losses

ID: OSS-REQ-0260


Specification: The total losses due to "dead" or "bad" pixels within the 3.5 degree FOV averaged over the 10-year survey shall be no more than fpaLosses. Discussion: The allocation for fpaLosses is determined by the estimated debits against the difference between the predicted number of visits over 18000 sq. deg. and the required number of visits. Description Value Unit Name



80


The fraction of unusable pixels (those that can not be calibrated to meet SRD/LSR specifications) at the time of instrument deliver shall be no more than deliveredPixelLoss.

2 Percent deliveredPixelLoss

The additional pixel loss over and above the deliveredPixelLoss when averaged over the 10-year survey lifetime shall be no more than agedPixelLoss.

2 Percent agedPixelLoss

3.4 Camera System

The imaging system shall convert the incident optical beam to an electronic signal that is in computer readable form.

3.4.1 Image Delivery ID: OSS-REQ-0261



3.4.1.1 Science Image Delivery

ID: OSS-REQ-0262


Specification: The imaging system shall deliver the science data with a unique identifier per device per exposure.

3.4.1.2 Raw Science Image Data

ID: OSS-REQ-0263


Specification: The LSST imaging system (e.g. Camera) shall provide raw pixel data from the science imager, in response to a request for one or more specific images.

3.4.1.3 Crosstalk-corrected Science Image Data

ID: OSS-REQ-0264


Specification: The LSST imaging system (e.g. the Camera) shall provide crosstalk-corrected pixel data from the science imager to client subscribers.

3.4.2 Image Acquisition ID: OSS-REQ-0265



3.4.2.1 Science Data Crosstalk

ID: OSS-REQ-0346




81

[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the hierarchy.] Discussion: The camera design synchronizes the charge transfer and digitization across all amplifiers in the focal plane. We assume that for the purposes of crosstalk correction it is only necessary to consider pixels sampled at the same time. Because of the synchronization these have a fixed geometrical relationship across the focal plane. These requirements are based on an underlying assumption of linearity of the actual crosstalk, as well as of a linear correction algorithm.

Crosstalk Magnitude Limits

ID: OSS-REQ-0327


Specification: The LSST Imaging system (i.e., the Camera) shall provide raw pixel data with crosstalk performance allocations listed in the table xtalkPerfAlloc. In particular, before correction, crosstalk between any two electronic channels within a single focal plane unit (i.e., one raft) shall not exceed maxXtalkIntraRaft; and crosstalk between focal plane units (i.e., raft-to-raft) shall not exceed maxXtalkInterRaft, with a goal of goalXtalkInterRaft. Discussion: The "Aggressor Limits" requirement, OSS-REQ-0328, in this section limits raft-to-raft crosstalk above the data release production threshold relevant to the science to a limited number of amplifiers (presumably nearby neighbors), to limit the data-transfer scope of the downstream corrections Data Management must perform. If the above "goal" is met, then all inter-raft crosstalk will be below the (less stringent) threshold for alert production, consistent with the current design for crosstalk correction by the Camera for the purposes of alert production. If not, then some mitigation will be required. Description Value Unit Name

Maximum crosstalk between any two electronic channels within a single Science Raft

0.002 float maxXtalkIntraRaft

Maximum crosstalk between rafts 0.0001 float maxXtalkInterRaft

Non-normative goal for inter-raft crosstalk 2.5e-5 float goalXtalkInterRaft

Crosstalk Aggressor Limits

ID: OSS-REQ-0328


Specification: The LSST system shall be capable of applying pixel crosstalk correction subject to the constraints given in the table xtalkAggressorLimits. In particular: for all the pixels on a given Science Raft, the Camera shall have no more than maxXtalkAggressor amplifiers on other rafts that contribute crosstalk greater than xtalkAggressorThresh, per aggressor. Discussion: The crosstalk is defined in terms of aggressors and victims. A set of pixels is read out simultaneously by the camera (one per amplifier). For any specific pixel (the victim), all the other pixels in the set are the potential aggressors. The threshold xtalkAggressorThresh is deliberately set to the same value as xtalkSciAccuracy below, and together they represent the idea that for data release purposes it is acceptable either for the raw crosstalk to be below this value, or for it to be correctable to this level. Description Value Unit Name



82


Maximum number of amplifiers from other rafts that may contribute above-threshold crosstalk to the pixels on a single raft

256 int maxXtalkAggressor

Threshold above which off-raft crosstalk aggressor limit applies

1e-6 (TBR)

int xtalkAggressorThresh

Crosstalk Accuracy

ID: OSS-REQ-0329


Specification: The accuracy to which crosstalk is determined and corrected shall meet the requirements in the table xtalkAccuracyAlloc. In particular:

The product of any given crosstalk coefficient to be used in the data release production crosstalk correction process and the relative accuracy with which it is known shall not exceed xtalkSciAccuracy;

The product of any given crosstalk coefficient to be used in the alert production crosstalk correction process and the relative accuracy with which it is known shall not exceed xtalkAlertAccuracy.

The crosstalk from any full-scale pixel to any other pixel shall be stable to xtalkSciAccuracy (and thus xtalkAlertAccuracy) over a period of at least xtalkStability, or the crosstalk correction algorithms shall be capable of using available metadata to correct any variations to the required precision. Discussion:The references to production "processes" above incorporates all steps in the data chain, whether crosstalk correction is actually performed in the Camera or in Data Management.By way of example, if the crosstalk proves to be temperature dependent in a predictable way, camera temperature telemetry could be used to improve the crosstalk correction. Description Value Unit Name

The product of any given crosstalk coefficient used in the data release production process and the relative accuracy with which it is known

1e-5 float xtalkSciAccuracy

The product of any given cross-talk coefficient used in the alert production process and the relative accuracy with which it is known

2.5e-5 float xtalkAlertAccuracy

Crosstalk stability period 14 Days xtalkStability

Crosstalk Measureability

ID: OSS-REQ-0330


Specification: The crosstalk coefficients used by the data release production process, and those used by the alert production process, shall be measurable at least at intervals of xtalkStability (see the "Crosstalk Accuracy" requirement OSS-REQ-0329 above). Discussion: The two sets of coefficients that apply for any given moment's data need not be the same. The coefficients for data release production are not needed, typically, until months after the collection of the science images. Sets of these coefficients may be computed for periods of time chosen after the fact, and can be determined, for each period, from the data from that period. For alert production, coefficients must be available at the time the images are acquired, and therefore the set of coefficients for a given time can only be determined from data previously taken. This means, that,



83

say, for fixed two-week blocks of data, DRP coefficients may be taken from the mid-point of the interval, while AP coefficients will be applied to data at or after the end of the interval and therefore may be more out of date. However, since the stability requirement for AP coefficients is less stringent, this is likely to be OK. This requirement is intended to apply whether in practice crosstalk coefficients are measured on the sky using only the normal science data, or whether they are measured with a dome-based calibration system, potentially in competition with other needs for calibration data. The intent is that, either way, two weeks is enough time to collect the required data.

Crosstalk Correction Capability

ID: OSS-REQ-0347


[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the hierarchy.] Discussion: The capabilities described are meant to be interpreted as capabilities of the end-to-end processing of the Observatory, able to be allocated to subsystems (i.e., Camera or Data Management) as an engineering judgment. In fact we do plan to allocate the crosstalk correction for alert production to the Camera, as indicated elsewhere in this section. These requirements do not specify the algorithms to be used (although a baseline of a linear "matrix multiplication" type of correction is implicit in the design) and in particular they do not require the data release and alert production corrections to use the same algorithm or the same coefficients. The DRP corrections might well be more sophisticated in form, as well as just considering additional, off-raft, amplifiers as aggressors.

Alert Production Crosstalk Correction

ID: OSS-REQ-0348


Specification: For each science raft, the alert production process shall be capable of applying crosstalk corrections across all the amplifiers within that raft. Discussion: This is sufficient to meet the xtalkAlertAccuracy requirement above if the Camera achieves the goal raft-to-raft crosstalk requirement goalXtalkInterRaft in OSS-REQ-0327.

Data Release Production Crosstalk Correction

ID: OSS-REQ-0349


Specification: The data release production process shall be capable of applying crosstalk corrections for a given raft based on the data from that raft and at least dataRelXtalkMaxAmp amplifiers from other rafts. Discussion: This capability is matched to the need for such corrections being limited (OSS-REQ-0328) to using no more than this many off-raft amplifiers, i.e., the capability is mandated to meet or exceed the need. Note that this requirement significantly exceeds the number of nearest-neighbor amplifiers for a raft,



84

which is 2*3*8 (short edges) + 2*3*2 (long edges) + 4 (corners) = 64. 256 is the number of amplifiers on nearest-neighbor CCDs, 4*3 (sides) + 4 (corners), 16 amplifiers each. It is believed that proximity of amplifier segments and their leads is likely to be the most relevant factor in producing inter-raft crosstalk. Description Value Unit Name

Minimum capability for the number of amplifiers on other rafts which can be considered in corrections for a full raft

256 int dataRelXtalkMaxAmp

3.4.2.2 Science Data Bit Depth

ID: OSS-REQ-0266


Specification: The imaging system shall acquire science data with a bit depth of least pixelBitDepth. Description Value Unit Name

The number of bit per pixel in the digitally recorded image data

16 int pixelBitDepth

3.4.2.3 Science Data Pixel Noise

ID: OSS-REQ-0267


Specification: The electronic noise from the LSST Camera system shall contribute no more than camSysNoise to each pixel per visit in the data from the science sensor array. Discussion: This top level noise budget includes all sources internal to the camera system that contribute to the base noise in each pixel, including readout noise, residual noise from dark current, additional noise in the electronics, etc... Specified pixel noise per visit implied 9.0e- per 15 sec exposure. Description Value Unit Name

The camera system noise contributed to each pixel per visit in the science data.

12.7 electrons camSysNoise

3.4.2.4 Dynamic Range

ID: OSS-REQ-0268


Specification: The LSST Camera system shall have a single exposure unsaturated dynamic range of at least camDynamicRange above the 5-sigma point source r-band limiting magnitude in a standard 15 second exposure. Discussion; This requirement is referenced to the fiducial conditions used to define the limiting magnitude requirements. Description Value Unit Name

The camera minimum dynamic range in a single 15 sec. exposure.

8 ABmag camDynamicRange

3.4.2.5 Filter Change



85

ID: OSS-REQ-0269


Specification: The camera system shall accept an external command to select and change any one of the five internal filters into the optical beam per the optical design specifications.

3.4.2.6 Filter Swap

ID: OSS-REQ-0270


Specification: The internal filter complement of the Camera shall be re-configurable by swapping any one of the internal filters with one stored externally without requiring the removal of the Camera from the telescope.

3.4.2.7 Supported Image Types

ID: OSS-REQ-0271


Specification: The LSST camera system shall support the acquisition of the following image types:

standard exposures image

bias image (zero integration readout of the FPA)

dark image (finite duration integration with a closed shutter)

3.4.3 Imaging Control ID: OSS-REQ-0272


Specification: The LSST Camera system shall acquire images in the current filter on command from the OCS by specifying exposure time and number of exposures. Discussion: Filter change is a separate function requiring coordination between both the Telescope and Camera

3.5 Photometric Calibration

The highest-level performance requirements for calibration of LSST data are specified in the LSST Science Requirements Document (SRD) and LSST System Requirements (LSR). The photometric calibration process will be divided into three main elements that contribute to calibration of LSST data: 1. An Instrument Calibration System that is tasked with calibrating the overall LSST system instrumental response to photons that are within the field of view of the telescope and camera; 2. An Auxiliary Telescope and thermal IR Cloud Camera that are tasked with characterizing the extinction of light as it travels from the top of the atmosphere to the entrance pupil of the telescope; and 3. The processing of Reference and Standard stars in LSST science images by algorithms in the DM pipelines. The flow-down of functional specifications from the highest level SRD requirements to these three elements of the calibration system is described in Document-7658, "LSST Calibration Functional Requirements", in the LSST archive. The first column of Table 1 in Document-7658 gives specifications on the temporal variation of calibration errors. The values in the second column are specifications on the spatial variation of calibration errors. The values in the final column are specifications on chromatic errors. The table lists specifications for the



86

LSST griz optical bands; specifications for the u and y bands are 50% larger. This document addresses the functional performance requirements for each of these dimensions for each of the three elements involved in calibration of LSST data. Bright isolated point sources are functionally stars that are not merged with other sources and are bright enough (17<r<20) to provide single measurements with S/N > 100.

3.5.1 Calibration of the Instrumental Transmission ID: OSS-REQ-0282


Specification: The LSST System shall calibrate the wavelength-dependent instrumental transmission function such that it contributes no more than the allocations in the table instCalAlloc for repeatability, uniformity, and relative accuracy. Discussion: The instrumental transmission function includes the effect of the three telescope mirrors, three camera refractive elements, filters, and the sensors making up the FPA. Sub-allocations for specific effects are given in the requirements that follow. These allocations include further distinction between the maximum uncorrected effect and the minimum required attenuation from either measurement and/or software algorithms. Description Value Unit Name

The maximum allowed RSS contribution to the overall photometric repeatability in "g", "r", "i", or "z" filters of bright isolated point sources caused by errors in estimating the wavelength-dependent instrumental transmission function shall not exceed instCalRep_griz.

1.9 mili-mag instCalRep_griz

The maximum allowed RSS contribution to the overall photometric repeatability in "z" and "y" filters of bright isolated point sources caused by errors in estimating the wavelength-dependent instrumental transmission function shall not exceed instCalRep_zy.

5.3 mili-mag instCalRep_zy

The maximum allowed RSS contribution to the overall uniformity across the sky of the photometric zero-point of bright isolated point sources caused by errors in estimating the wavelength-dependent instrumental transmission function.

2.0 mili-mag instCalUniformity

The maximum allowed RSS contribution to the overall accuracy of the color zero points of bright isolated point sources caused by errors in estimating the wavelength-dependent instrumental transmission function.

3.0 mili-mag instColorZP

3.5.1.1 Filter Variation Allocations

ID: OSS-REQ-0331


Specification: Photometric errors caused by uncertainties in filter placement and/or variations over the FOV shall result in an RSS contribution of not more than photFiltVarErr to the repeatability of magnitudes for bright isolated point sources with allocations to maximum uncorrected effect and minimum attenuation give in table photFiltVarAlloc.



87


The maximum post correction RSS contribution to the photometric repeatability budget from positioning errors and or variations over the FOV shall be no more than photFiltVarErr.

0.5 mili-mag photFilterVarErr

The maximum un-modeled RSS contribution to the photometric repeatability budget from filter placements errors and/or response variations over the FOV shall be no more than maxFiltVarEffect.

0.5 mili-mag maxFiltVarEffect

Attenuation of the raw un-modeled filter placement errors and/or response variation over the FOV (maxFiltVarEffect) either by direct measurement or through software algorithms shall be at least minFiltVarAttenuation.

1.0 int minFiltVarAttenuation

3.5.1.2 FPA Gain Allocations

ID: OSS-REQ-0332


Specification: FPA sensor gain variation errors shall result in an RSS contribution of not more than photFPAGainErr to the repeatability of magnitudes for bright isolated point sources with allocations to maximum uncorrected effect and minimum attenuation give in table photFPAGainAlloc. Description Value Unit Name

The maximum post correction RSS contribution to the photometric repeatability budget from FPA gain variation errors shall be no more than photFPAGainErr.

1.4 mili-mag photFPAGainErr

The maximum error in photometric repeatability from uncorrected gain variations over spatial scales equal to or exceeding a single imaging device (e.g. CCD) over a 12 hour observing period shall not exceed maxLSGainEffect.

10 mili-mag maxLSGainEffect

Attenuation of the raw large scale gain variation errors (maxLSGainEffect) either by direct measurement or through software algorithms shall be at least minLSGainAttenuation.

100 int minLSGainAttenuation

The maximum error in photometric repeatability from uncorrected gain variations over spatial scales equal a single output amplifier and over a 12 hour observing period shall not exceed maxSSGainEffect(>1hr).

10 mili-mag maxSSGainEffect(>1hr)

Attenuation of the raw amplifier scale gain variation errors over periods greater than 1 hour (maxSSGainEffect(>1hr)) either by direct measurement or through software algorithms shall be at least minSSGainAttenuation(>1hr).

10 int minSSGainAttenuation(>1hr)

The gain offset for an area with a spatial scale equal to a single amplifier relative to the gain of the imaging device (e.g. CCD) on which that area resides shall vary by no more than maxSSGainEffect(<1hr) for periods less than 1 hour.

1.0 mili-mag maxSSGainEffect(<1hr)

Attenuation of the raw small scale short term gain variation errors (maxSSGainEffect(<1hr)) either by direct measurement or through software algorithms shall be at least minSSGainAttenuation(<1hr).

1.0 int minSSGainAttenuation(<1hr)



88

3.5.1.3 FPA Temperature Allocations

ID: OSS-REQ-0333


Specification: FPA temperature variation errors shall result in an RSS contribution of not more than photFPATempErr to the repeatability of magnitudes for bright isolated point sources with allocations to maximum uncorrected effect and minimum attenuation give in table photFPATempAlloc. Discussion: This requirement only applies to y-band photometric repeatability due to the temperature sensitivity of the extreme red (~1 micron) QE response of silicon. Description Value Unit Name

The maximum post correction RSS contribution to the photometric repeatability budget from FPA temperature variation errors shall be no more than photFPATempErr.

5.0 mili-mag photFPATempErr

The maximum un-modeled RSS contribution to the y-band photometric repeatability budget from un-modeled FPA temperature variation errors shall be no more than photFPAGainErr.

5.0 mili-mag maxFPATempEffect

Attenuation of the raw un-modeled temperature variation errors (maxFPATempEffect) either by direct measurement or through software algorithms shall be at least minFPATempAttenuation.

1.0 int minFPATempAttenuation

3.5.1.4 Flat Fielding Allocations

ID: OSS-REQ-0334


Specification: Flat fielding errors shall result in an RSS contribution of not more than photFlatFieldErr to the repeatability of magnitudes for bright isolated point sources with allocations to the maximum uncorrected effect and minimum attenuation given in table photFlatFieldAlloc. Description Value Unit Name

The maximum post correction RSS contribution to the photometric repeatability budget from flat fielding errors shall be no more than photFlatFieldErr.

0.6 mili-mag photFlatFieldErr

The maximum error in photometric repeatability from uncorrected flat fielding errors shall not exceed maxFlatFieldEffect.

250 mili-mag maxFlatFieldEffect

Attenuation of the raw flat fielding errors (maxFlatFieldEffect) either by direct measurement or through software algorithms shall be at least minFlatFieldAttenuation.

400 int minFlatFieldAttenuation

3.5.1.5 Shutter Timing Allocations

ID: OSS-REQ-0335


Specification: Shutter timing errors shall result in an RSS contribution of not more than photShutterErr to the repeatability of magnitudes for bright isolated point sources with allocations to the maximum uncorrected effect and minimum attenuation given in table photShutterAlloc.



89


The maximum post correction RSS contribution to the photometric repeatability budget from shutter timing errs shall be no more than photShutterErr.

0.4 mili-mag photShutterErr

The maximum error in photometric repeatability from uncorrected shutter timing errors shall not exceed maxShutterEffect.

20.0 mili-mag maxShutterEffect

Attenuation of the raw shutter timing errors (maxShutterEffect) either by direct measurement or through software algorithms shall be at least minShutterAttenuation.

50 int minShutterAttenuation

3.5.1.6 Calibration Meta Data

ID: OSS-REQ-0317


Specification: As required by OSS-REQ-0063, the Telescope and Site and the Camera systems shall provide all real-time metadata needed to maintain the required photometric precision and accuracy during operations between daily and periodic acquisition of dedicated calibration data.

3.5.2 Calibration of the Atmospheric Transmission ID: OSS-REQ-0276


Specification: The LSST System shall calibrate the wavelength-dependent transmission of the atmosphere above the Summit Site such that it contributes no more than the allocations in the table atmCalAlloc for repeatability (parameter atmCalRep), uniformity (atmCalUniformity), and relative accuracy (atmCalColorZP). Sub-allocations for specific effects are given in the requirements that follow. These allocations include further distinction between the maximum uncorrected effect and the minimum required attenuation from either measurement and/or software algorithms. Description Value Unit Name

The maximum allowed RSS contribution to the overall photometric repeatability of bright isolated point sources in the "u", "g", "r", and "i" filters caused by errors in estimating the wavelength-dependent atmospheric transmission function shall not exceed photAtmColorErr_ugri.

1.0 mili-mag photAtmColorErr_ugri

The maximum error in photometric repeatability from uncorrected wavelength dependent atmospheric transmission errors shall not exceed maxAtmColorEffect_ugri in the "u", "g", "r" and "i" filters.

50 mili-mag photAtmColorEffect_ugri

The maximum allowed RSS contribution to the overall photometric repeatability of bright isolated point sources in the " "z", and "y" filters caused by errors in estimating the wavelength-dependent atmospheric transmission function shall not exceed photAtmColorErr_zy.

2.0 mili-mag photAtmColorErr_zy

Attenuation of the raw wavelength dependent atmospheric transmission errors (maxAtmColorEffect) either by direct measurement or through software algorithms shall be at least minFAtmColorAttenuation.

50 mili-mag photAtnColorAttenuation



90


The maximum error in photometric repeatability from uncorrected wavelength dependent atmospheric transmission errors shall not exceed maxAtmColorEffect_zy in the "z" and "y" filters.

100 mili-mag photAtmColorEffect_zy

3.5.2.1 ATM Color Allocations

ID: OSS-REQ-0277


Specification: Photometric errors caused by uncertainties in the measurement of the wavelength dependent (color) atmospheric transmission shall result in an RSS contribution of not more than photAtmColorErr to the repeatability of magnitudes for bright isolated point sources with allocations to maximum uncorrected effect and minimum attenuation give in table photAtmColorAlloc. Description Value Unit Name

The maximum allowed RSS contribution to the overall photometric repeatability of bright isolated point sources caused by errors in estimating the wavelength-independent atmospheric transmission function shall not exceed photAtmGrayrErr.

2.0 mili-mag photAtmGrayErr

The maximum allowed RSS contribution to the overall uniformity across the sky of the photometric zero-point of bright isolated point sources caused by errors in estimating the wavelength-dependent atmospheric transmission function.

4.0 mili-mag atmCalUniformity

The maximum allowed RSS contribution to the overall accuracy of the color zero points of bright isolated point sources caused by errors in estimating the wavelength-dependent atmospheric transmission function.

3.0 mili-mag atmCalColorZP

The maximum allowed RSS contribution to the overall photometric repeatability across the sky of the photometric zero-point in the "u", "g", "r", and "i" filters of bright isolated point sources caused by errors in estimating the atmospheric transmission function shall not exceed atmCalRep_ugri.

3.2 mili-mag atmCalRep_ugri

The maximum allowed RSS contribution to the overall photometric repeatability across the sky of the photometric zero-point in the "z" and "y" filters of bright isolated point sources caused by errors in estimating the atmospheric transmission function shall not exceed atmCalRep_zy.

3.6 mili-mag atmCalRep_zy

ATM Color Spectral Range

ID: OSS-REQ-0279


Specification: The atmospheric transmission function shall be estimated over a range of wavelengths with resolution defined in the table atmTranSpec. Description Value Unit Name

The maximum wavelength of the spectral range over which the atmospheric transmission function is estimated.

1125 nm atmLambdaMax



91


The minimum wavelength of the spectral range over which the atmospheric transmission function is estimated.

315 nm atmLambdaMin

The maximum resolution of the estimated atmospheric transmission function at 500nm.

1.5 nm atmLambdaRes

Atmospheric Transmission Sky Coverage

ID: OSS-REQ-0278


Specification: The atmospheric transmission function shall be mapped over the nightly survey operating area. Spatial and temporal proximity with respect to the LSST pointings is TBD (will be resolved as the Photometric calibration plan is fully detailed).

Atmospheric Transmission Temporal Sampling

ID: OSS-REQ-0280


Specification: The atmospheric transmission function shall be determined with a period no longer than atmTempSamp between measurements. Description Value Unit Name

The maximum time between measurements of the atmospheric transmission function for a single point on the sky.

5 Minute atmTempSamp

3.5.2.2 ATM Gray Allocations

ID: OSS-REQ-0336


Specification: Photometric errors caused by uncertainties in the measurement of the wavelength independent (gray) atmospheric transmission shall result in an RSS contribution of not more than photAtmGrayErr to the repeatability of magnitudes for bright isolated point sources with allocations to maximum uncorrected effect and minimum attenuation give in table photAtmGrayAlloc. Description Value Unit Name

The maximum allowed RSS contribution to the overall photometric repeatability of bright isolated point sources caused by errors in estimating the gray atmospheric transmission function shall not exceed photAtmGrayErr.

3.0 mili-mag photAStmGrayErr

The maximum error in photometric repeatability from uncorrected gray atmospheric transmission errors shall not exceed maxAtmGrayEffect.

250 mili-mag maxAtmGrayEffect

Attenuation of the raw gray atmospheric transmission errors (maxAtmGrayEffect) either by direct measurement or through software algorithms shall be at least minFAtmGrayAttenuation.

83 mili-mag minAtmGrayAttenuation

Cloud Map (TBR)



92

ID: OSS-REQ-0281


Specification: A cloud map, meeting cloudMapPerf specifications, showing relative cloud densities (grey extinction) across the LSST's field-of-view (3.5 deree) will be provided for each survey science image. Discussion: The intent of the cloud map described here is to provide additional information on how to interpolate the grey extinction variation occurring between reference stars used to anchor the internal LSST photometric system. Description Value Unit Name

The resolution (rms) for the map showing the relative grey extinction (clouds) across the LSST FOV for each survey science image.

60 Arcsec cloudMapRes

The sensitivity to variations in grey extinction (clouds) within a resolution element.

0.005 ABmag cloudMaprelSens

3.5.3 Calibration Data Processing ID: OSS-REQ-0273



3.5.3.1 Calibration Processing Performance Allocations

ID: OSS-REQ-0275


Specification: The LSST System shall photometrically calibrate raw image data such that the data processing contributes no more than the allocations in the table procCalAlloc for repeatability (parameter procCalRep), uniformity (procCalUniformity), and relative accuracy (procCalZP). Discussion: These allocations include effects from calibration algorithms, errors and noise in producing the necessary calibration data products, as well as errors and uncertainties in any reference catalogs used in the calibration process. Description Value Unit Name

The maximum allowed RSS contribution to the overall photometric repeatability of bright isolated point sources caused by errors introduced in the data processing pipelines.

0.003 ABmag procCalRep

The maximum allowed RSS contribution to the overall uniformity across the sky of the photometric zero-point of bright isolated point sources introduced in the data processing pipelines.

0.007 ABmag procCalUniformity

The maximum allowed RSS contribution to the overall accuracy of the color zero points of bright isolated point sources introduced by the data processing pipelines.

0.003 ABmag procColorZP

3.5.3.2 Extrapolation of Calibration from Reference

ID: OSS-REQ-0318




93

Specification: The LSST data processing system shall be able to extrapolate calibration performance established with bright isolated stars to faint resolved source with a degradation that is no worse that the growth of errors from Poisson noise.

3.5.4 Data Products for Photometric Calibration ID: OSS-REQ-0284


Specification: The LSST Data Management system output shall include the calibration data products required to support the photometric calibration requirements within this document. The Data Management system shall archive all Calibration Data Products.

3.5.4.1 Reference Star Catalog

ID: OSS-REQ-0285


Calibration of LSST data will require a catalog of non-variable main-sequence reference stars with magnitudes 17 < r < 20. This catalog shall contain 10000 stars in each LSST 9.8sq deg survey field.

3.5.4.2 White Dwarf Flux Standards

ID: OSS-REQ-0286


Determination of transformations between LSST filter bands will require a catalog of hydrogen (DA) and helium (DB) white dwarf stars with magnitudes within the range of the LSST main telescope. This catalog must contain at least one DA or DB WD in each LSST 9.8sq deg survey field.

3.6 System Timing and Dynamics

3.6.1 Cadence and Visit Timing ID: OSS-REQ-0287



3.6.1.1 Standard Visit Duration

ID: OSS-REQ-0288


Specification: The total elapsed time for a standard visit (2 x 15 sec exposures), from the command to begin the first exposure to the end of the second exposure when the shutter is fully closed, shall be no more than visitDuration. Discussion: The end point of the second exposure is defined when the shutter is fully closed and does not include the readout time. This is because the readout of the second exposure is done while the system is being re-pointed to the next field location. The baseline sequence for a standard visit is 1 sec open shutter; 14 sec integration; 1 sec close shutter; 2 sec pixel readout 1 sec shutter open; 14 sec integration; 1 sec shutter close. Description Value Unit Name



94


The maximum duration of a visit is visitDuration. 34 Seconds visitDuration

3.6.1.2 Time Interval Between Visits

ID: OSS-REQ-0289


Specification: The median time between successive visits shall be less than medianVisitInterval over the full set of survey observations. Specification: The average time between successive visits shall be less than aveVisitInterval over the full set of survey observations. Discussion: This requirement is derived from the total number of visits per field and the total number of fields needed to cover the defined survey area. The interval between successive visits starts when the shutter of the second exposure of the visit is fully closed, and ends when the shutter of the first exposure of the next visit opens. The minimum interval between visits is limited by the FPA readout time when there is not a repositioning of the telescope. Operating for an entire night at that cadence is the extreme limit of what might be required in deep-drilling operations. That specification does not require that this mode of operation be able to be sustained indefinitely. Description Value Unit Name

The median interval as defined above over all successive visit pairs over the 10 year survey.

5 Seconds medianVisitInterval

The average interval as defined above over all successive visit pairs over the 10 year survey

10 Seconds aveVisitInterval

3.6.1.3 Continuous Exposures

ID: OSS-REQ-0319


Specification: The Observatory shall be capable of continuous operation throughout a night with the interval between successive visits equal to the FPA readout time. Discussion: This mode of observing is needed to support observations when the telescope is not being re-pointed. For example observing "deep drilling" fields, where successive exposures are obtained through one or more filters over an extended period, and obtaining calibration images adjuring a cloudy night..

3.6.1.4 Minimum Exposure Time

ID: OSS-REQ-0291


Specification: The camera shall be able to obtain a single exposure with an effective minimum exposure time of no more than minExpTime. Discussion: The camera thermal stability may be affected if the duty cycle differs from the standard 15



95

second exposure. If the exposure is shortened from the 15 second nominal, the spacing between successive exposures should be extended to maintain the average readout rate consistent with a 15 second exposure. If the exposure is lengthened from the 15 second nominal, the thermal stability may be affected, which may affect photometric accuracy. Description Value Unit Name

The maximum shortest exposure time of a single exposure is minExpTime.

5 Seconds minExpTime

3.6.2 Filter Swaps & Changes ID: OSS-REQ-0292


Specification: The system shall be designed such that the following performance specifications are met: 1. maximum time to change the operational filter 2. maximum time to swap a single filter from the internal complement

3.6.2.1 Maximum time for operational filter change

ID: OSS-REQ-0293


Specification: The camera system shall provide the capability of changing the operational filter with any other internal filter in a time less than tFilterChange. Discussion: This time allocation includes any overhead required to position the camera into a specific orientation required to execute the filter change. This requirement allocates 30 seconds to the telescope (reorient the camera to its nominal zero angle position on the rotator) and 90 seconds to the camera subsystem (for executing the change). Total time allowed for moving any one of the internal filters in the camera into its operating position. This includes any overhead required to place the camera in a specific orientation prior to the change. Description Value Unit Name

Total time allowed for moving any one of the internal filters in the camera from a stowed position into its operating position. This includes any overhead required to place the camera in a specific orientation prior to the change.

120 Seconds tFilterChange

3.6.2.2 Maximum time to swap internal filter

ID: OSS-REQ-0294


Specification: The filter complement internal to the camera shall be reconfigured by swapping one of the internal filters with one stored externally in a time less than tFilterSwapOut. Discussion: This time is allocated between two activities involving the telescope and camera, operational needs. Nominal allocation is 1.5 hours to each subsystem. This requirement does not include the time required to obtain the necessary calibration data needed when the filter complement is changed.



96


Maximum time required to swap a single filter in the complement of 5 internal filters to the camera with one that has been externally stored.

3 Hours tFilterSwapOut

3.6.2.3 Filter Change Count

ID: OSS-REQ-0295


Specification: For design purposes the number of daily and nightly operational filter changes shall be dailyFiltChanges and nightlyFiltChanges given in the table below. Discussion: Based on calibration baseline of taking dome flats twice per day (beginning / end of night). These value need to be check against the most recent OpsIm output Description Value Unit Name

The expected minimum number of daily filter changed shall be dayFiltChnages. (TBR)

8 int dailyFiltChanges

The expected minimum number of nightly filter change shall be dayFiltChnages. (TBR)

4 int nightlyFiltChanges

3.6.2.4 Filter Swap Count

ID: OSS-REQ-0320


Specification: For design purposes the number of monthly filter complement swaps shall be at least monthlyFiltSwaps given in the table below. Discussion: The number of swaps supports replace one of the red filters with the u-band filter during the dark time around new moon. Description Value Unit Name

The minimum number of filter swaps per month shal be taken as monthlyFiltSwaps.

2 int monthlyFiltSwaps

3.6.3 Observatory Pointing and Tracking ID: OSS-REQ-0297



3.6.3.1 Absolute Pointing

ID: OSS-REQ-0298


Specification: The LSST shall point to a defined set of sky coordinates with an RMS accuracy of absPointErr. Discussion: It is understood that pointing does not require direct access to any sky references (e.g. guide stars).



97


The minimum RMS point error of the full range of operational sky coverage.

2 Arcsec absPointErr

3.6.3.2 Field de-rotation

ID: OSS-REQ-0299


Specification: The LSST shall provide the ability to track the apparent field rotation caused by tracking the sky in altitude and azimuth. Discussion: It is understood that the telescope mount configuration will be that of an altitude over azimuth design.

Rotator Range

ID: OSS-REQ-0300


Specification: The LSST shall be capable of maintaining rotation tracking the duration of a standard visit over a range of angles rotTrackRange on either side of a nominal reference with respect to the optical bore sight. Discussion: This requirements is designed to allow analysis of PSF shape systematics generated by the optical system to meet the full survey ellipticity performance requirements. Description Value Unit Name

The half range of the rotator motion. 90 Degrees rotTrackRange

Rotator tracking Time

ID: OSS-REQ-0301


Specification: The LSST shall be able to maintain field rotation tracking over a period of at least rotTrackTime without the need to reset (e.g. unwind cable wraps). Discussion: This requirements is driven by the need to conduct extended "deep drilling" observations on a single field. Description Value Unit Name

Minimum time required for continuous rotation tracking 1 Hour rotTrackTime

3.6.3.3 Offset Pointing

ID: OSS-REQ-0302


Specification: The LSST shall be capable of offset pointing within a single field-of-view with a precision of no more than offsetPointingErr. Description Value Unit Name

The RMS error for offset pointing within the FOV. 0.2 Arcsec offsetPointingErr



98

3.6.3.4 Open Loop Tracking

ID: OSS-REQ-0303


Specification: The LSST shall be capable of open loop tracking without the assistance of real time optical feedback to an accuracy of openTrackErr over any 10 minute duration during normal night time operations. Discussion: This requirement is somewhat soft and is driven primarily by ease of operation while acquiring guide stars for optical tracking feed back. It also partially driven by the need to be able to track well enough without guiding to assess optical performance during the early commissioning phase of the project. Description Value Unit Name

Allowed open loop tracking error in 10 minutes. 1.0 Arcsec openTrackErr

3.6.3.5 Tracking Range

ID: OSS-REQ-0304


Specification: The LSST telescope shall maintain tracking over all elevation angles over a range given by trackRange below. Description Value Unit Name

Minimum high elevation limit where tracking is to be maintained.

86.5 Degrees maxTrackEl

Minimum low elevation limit where tracking is to be maintained.

15.0 Degrees minTrackEl

3.6.3.6 Guiding

ID: OSS-REQ-0305


Specification: The LSST system shall improve the tracking of the optical system to the sky by means of active guiding over the whole accessible sky. The history of the feedback signal involved shall be archived in the telemetry database. Discussion: Guiding includes providing feedback of the tracking errors of the mount in both axes as well as the field de-rotation. The required performance for closed loop tracking with guiding is derived from the image quality allocation to the telescope.

Guide Signal Source

ID: OSS-REQ-0306


Specification: It is the responsibility of the LSST instrument (i..e. Camera) to provide a suitable signal to the mount control system to enact guide error feedback.

3.7 Education and Public Outreach



99

3.7.1 EPO - National Priorities ID: OSS-REQ-0355


Specification: LSST EPO shall contribute directly or indirectly to four of the top five priority STEM investment areas as described in the "Federal STEM Education 5-Year Strategic Plan":

Improve STEM instruction

Increase and Sustain Youth and Public Engagement in STEM

Enhance STEM experience of Undergraduate Students

Better Serve Groups Historically Underrepresented in STEM fields Discussion: The “Federal STEM Education 5-Year Strategic Plan” can be accessed at: http://www.whitehouse.gov/sites/default/files/microsites/ostp/stem_stratplan_2013.pdf

3.7.1.1 EPO - Emphasize Diversity

ID: OSS-REQ-0356


Specification: LSST EPO shall actively partner with minority-serving institutions and organizations to engage traditionally under-represented groups in LSST activities. Discussion: In order to maximize our reach into this targeted audience, we will coordinate with existing programs and leverage their efforts.

3.7.1.2 EPO - Audience Definition

ID: OSS-REQ-0357


Specification: The LSST EPO subsystem shall serve four main categories of users: the General Public, Citizen Scientists, Content Developers at Science Museums and Planetariums, and Instructors and Students in research experiences. Discussion: Each audience will be served through an individualized interface to data products.

3.7.1.3 EPO - Direct and Indirect Users

ID: OSS-REQ-0358


Specification: EPO data products, interfaces, materials, and support shall be provided to direct users of LSST EPO as well as to content developers at partner organizations for their use and deployment. Discussion: LSST cannot be everything to everyone; some audiences will be served indirectly through content providers. For example, LSST will provide modules to content creators in science centers who will incorporate those products into their productions (kiosks, video, digital planetarium shows, etc.)

3.7.1.4 EPO - System Deliverables

ID: OSS-REQ-0359


Specification: The EPO system will provide data products, user interfaces, data access and analysis tools, educational materials, support facilities, performance metrics, links to external datasets, and a



100

collaborative framework to support its users. Discussion: These deliverables will be available from the EPO center.

3.7.1.5 EPO - Evaluation

ID: OSS-REQ-0360


Specification: LSST EPO shall conduct regular internal and external evaluations of EPO products and share assessment results with the science education community. Discussion: Outcomes and metrics will be tracked for all registered users and directly-supplied learning experiences

3.7.1.6 EPO - Sustainable Partnerships

ID: OSS-REQ-0361


Specification: LSST EPO shall build partnerships with local, regional and national organizations, institutions, agencies, museums, schools, and interested groups to facilitate education and outreach programs for diverse audiences. Discussion: "If you want to go fast, go alone. If you want to go far, go with others." LSST EPO wants to go far and remain useful through operations and beyond. This is best accomplished in partnership with other organizations with similar goals.

3.7.1.7 EPO - Flexible Interface Design

ID: OSS-REQ-0362


Specification: The EPO User Interface design shall be agile and capable of evolving in response to user experience and demand. Discussion: The EPO interface is certain to change with time as new user needs are identified, new technology capabilities come on line, and opportunities arise due to partnerships, new funding, or social trends. LSST EPO must be able to identify these changes and adapt to them.

3.7.1.8 EPO - Cloud Capable

ID: OSS-REQ-0363


Specification: LSST EPO shall be designed such that it is capable of using the cloud for data storage and distribution. Discussion: The EPO user load is much less predictable and is more volatile than the science user load. Compatibility with the use of elastic cloud technologies ensures that EPO can handle the potential load volatility.

3.7.1.9 EPO - System Responsiveness

ID: OSS-REQ-0364


Specification: LSST EPO shall serve each user in a acceptable response time.



101

Discussion: Acceptable response times have been established for each user action and must be achieved to meet the audience need. See EPO-REQ-0092 for further derivation of this requirement.

3.7.1.10 EPO - Conform to Software Standards

ID: OSS-REQ-0365


Specification: LSST EPO shall conform to project-wide software standards and practices. Discussion: In order to maximize the cost-savings and expertise-sharing, EPO software will follow the project-wide standards and practices.