Child pages
  • LSST Key Numbers
Skip to end of metadata
Go to start of metadata

A need has arisen for the a single, agreed-upon, list of values with key numbers that we will use consistently across all presentation for Final Design Review and beyond (esp. as they relate to data volumes, etc.).

Below is that list. Please cross-check your slides and make sure they're consistent with these numbers.

This list must be updated on CCB or DM/TCT actions that cause the underlying numbers to change. Robert McKercher is responsible for keeping track.

Note that a version of this list is also in Docushare as Document-16168.  There is an open JIRA issue, PST-21, for the updating of the list.

Principal references:

  • LSST Science Requirements Document (SRD), LPM-17
  • LSST System Requirements (LSR), LSE-29
  • Observatory System Specifications (OSS), LSE-30
ParameterValueNotesFormal Source Document(s)

Fiducial number of visits per pointing in the main survey.

825Given by the SRDLSR-REQ-0098, Nv1Sum

Fiducial main survey area

18,000 deg2

Given by the SRDLSR-REQ-0098, ASky
Estimated total covered area, including special programs25,000 deg^2
  • Includes the estimate for the extra area covered in the northern Equatorial spur (for asteroids), and the southern galactic cap (Magellanic clouds). Survey-strategy dependent.
  • The true covered area will strongly depend on the details of the strategy, and the decision on how to spend the 10% time devoted to special programs. The number given is a "not-to-exceed" number (from the data sizing point of view).
LSE-81 cell G92
Single exposure 5-sigma point source depth

u = 23.9

g = 25.0

r = 24.7

i = 24.0

z = 23.3

y = 22.1

Design spec from the SRD.SRD
10-year idealized 5-sigma point source depth

u = 26.1

g = 27.4

r = 27.5

i = 26.8

z = 26.1

y = 24.9

Cadence dependent; this is an illustration from the SRD from a plausible OpSim run assuming the above single-exposure depths.SRD

Number of visits collected over 10 years

2.75 million
  • This is now in the OSS, as a requirement on number of exposures (550 thousand per year). It it a not-to-exceed number.
  • OpSim has achieved ~2.6M
Computed from OSS-REQ-0190

Number of images collected in 10 years

5.5 million

Simply equal to 2.75 * 2

Number of visits per night"about a 1000"

This is 2.75 million / 10 year / 300 days/year = 920 visits/night, rounded up to 1000.

Derived from OSS, SRD

Number of calibration exposures


  • This is an average
  • Requirement in the OSS, comes from the Calibration Plan.

Number of data collected per 24 hr period

"about 20 TB"

This is the number of exposures per night + calibration exposures per day(= !2450), with 8.2 GB per exposure (562*2098 pixels including overscan × 16 amplifiers × (189 science CCDs + 4 wavefront sensors) × 18 bits/pixel / 8 bits/byte).

Considering that the in-memory form and the compressed form are both varying physical representations of the "true" logical information, we use 18 bits/pixel.

Derived from OSS, SRD; LSE-81 for pixel size upper bound
Number of data for 10 year mission"about 60PB"

10 years  x 298.35 observing nights/year

= 1.5M total calibration images
= 1.35M total calibration images
= 7M total images

= 8.2GB x 7M total images = 57.4 PB of raw data = 56.2 PB

Per-24 hour period
~ 2450 science and calibration images/24 hr period = ~ 20 TB/24 hr period
(~20 * 300 * 10 = ~60 PB which matches total)

Standard visit exposure duration

15 s

A visit consists of two exposures. Specified in the SRD.


Time to take a single exposure

18 s
  • One second to open one shutter blade set.
  • Fourteen seconds of fully open exposure.
  • One second to close the other shutter blade set, and
  • Two seconds to read out the FPA.
Expected median slew time between visits4.8 s

Derived from the current baseline cadence (see Observing strategy white paper, section on baseline cadence minion_1016). The mean value for minion_1016 is 6.8 s. Similar, but not identical, values are expected for future cadence realizations.

Requirement: 5 sec (OSS-REQ-0289)

Derived from minion_1016 analysis
Time to take one visit in normal survey modeMedian: 39 s
Mean: 44 s 

Computed from two 18-second units, with the 5-second slew overlapped with the 2-second readout of the second exposure, thus 18 + 18 - 2 + 5 = 39 seconds (and the mean should be 44 seconds, as the mean slew time is 10 seconds).  (Slew times taken from OSS-REQ-0289, not from simulation.)

Derived from OSS
Estimated number of objects in DR1137 billion
  • 20 B galaxies, 17 B stars. Note that uncertainties on the number of stars is significant (on order of ~30%), and accounted for in the sizing model. Computed from LSE-81 by dividing B66 by (1+C52), the margin for galaxies, and D66 by (1+C51), the margin for stars.
  • Some of these will be objects outside of the main survey area (in the deep drilling fields, northern Equatorial spur, Magellanic clouds, etc.)
  • Codified as a requirement in the OSS.


OSS-REQ-0192, OSS-REQ-0193

Estimated number of single-epoch sources in DR117 trillion

Comes from the DM sizing model (LDM-141, db2 sheet), by dividing F17 (number of sources in DR11) by 1.28 (the technical margin factor, derived by dividing D17 by 37 billion above).

(this is a reasonable answer to the question "how many rows are there in your database")


Estimated number of forced measurements in DR1130 trillion
  • This is "forced photometry", i.e., a flux measurement performed at the position of all objects in all epochs.
  • Computed as 37 billion objects * 825 observations; it's a very rough estimate. DM sizing model, with technical margins included, assumes 50 trillion.


Estimated numbers for DR1 release

Objects: 18 billion
Sources: 350 billion
ForcedSources: 0.75 trillion

  • Number of objects comes from the DM sizing model (db2!E6), divided by the 1.28 margin (see above).
  • Similarly so for the number of sources
  • Number of forced sources is computed as 18 B * (825/10years/2). The final division by 2 is to account for DR1 being done using just 6 months worth of data.
Average number of alerts per night"about 10 million"

The science estimate used to be 2M per night. However, this did not include the Galactic plane where we'll have significantly more variability. Also, the SRD requires us to support ~10k/visit, which roughly translates to ~10M/night; before it was interpreted as the "peak", but we didn't have a strong justification why. We're now treating it as an average, so the number of alerts per night flows from that.

Network bandwidths
  • 100 - 600 Gbps Cerro Pachon - La Serena
  • 40 - 200 Gbps La Serena - Santiago
  • 100 - 300 Gbps Santiago - Florida
  • 100 - 200 Florida - Chicago, Chicago - Champaign

The 2 x NNN nomenclature is designed to convey that the data will be transmitted through two independent links; if one gets cut, the other one continues to operate. DM and Camera baselines can operate with a only a single link being up.

x00 - y00 range indicates lower end (some links down) - upper end (all links operating). Any link would go to zero if all links are down, but that is deemed < 0.1% probability.

NOTE: As of 20171220 La Serena - Santiago still negotiating for 100 Gbps lower end, 75% likely



Data and compute sizes
  • Final image collection (DR11): 0.5 Exabytes
  • Final database size (DR11): 15 PB
  • Final disk storage: 0.4 Exabytes
  • Peak number of nodes: 1750 nodes
  • Peak compute power in LSST data centers: 1.8 PFLOPS
  • The sizes include the technical margins that DM included in their sizing models. That is, if you took the expected number of objects, sources, etc., and plugged them in the model, you'd obtain lower numbers than the table above.
  • The numbers for nodes and storage include the Archive and Base centers.
  • The database size includes data and persistent overhead (does not include temporary disk space to run analyses).
  • The image collection includes 24 PB of raw images, 16.5 of processed, retained, data (coadds, master calib, cutouts, epo, disk-based science calibrated, disk-based templates), and 475 PB of virtual data (all science calibrated exposures and templates not already on disk). These are all compressed sizes; uncompressed size is roughly 2x larger.

  • These numbers are computed/transcribed from LDM-141 in Document-11928 (a powerpoint presentation). See that slide set for detailed explanation on how they were derived.



Number of Data Releases11

DR1 will include the first 6 months of data
DR2 will include the first year of data
DR3 will include the first two years of data

Date of DR1 releasetime of ops start + 12 months

A common misconception is that the first data release will be released 6 months after the start of the survey. It will be released 12 months after the start of the survey. It's because we collect data for 6 months, and then it takes 6 months to process it.

Ops plan?

Read noise

<9e- rms, at nominal 2 second readout time________________ __

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... The camera read noise requirement per exposure is derived from the OSS requirement of 12.7e- per visit and the standard definition of two exposures per visit.

LSE-59 Camera Subsystem Requirements


CCD Blooming Full WellPixel charge capacity shall be no greater than 175,000 electrons.

Defined as the point at which the detector response (volts out divided by mean per pixel integrated photo-generated charge) saturates when illuminated by a flat field. 

CCD-008 in LCA-128
  • No labels


  1. Will the contents of this page be made available on some public web site?

  2. This page is very DM- and data-volume-centric.  The addition of basic metrics on collecting area, image quality, etc., would make it a more community-useful data sheet as well as a better resource for preparing and fact-checking talks.

    Was the plan to expand it in this direction to something along the lines of the old Document-16?

  3. I think any metrics, quantities or notes that are frequently looked up for talks or science estimates could be added here. Some care will have to be taken not to overdo it, but I wouldn't worry about it until (or if) we find ourselves in that situation.

  4. A link to the Confluence page is on the Project Tools page of

  5. It'd be nice to have some nominal camera numbers.  Number/pixel count of CCDs (OK, so I know that).  Readnoise at 500 kHz.  Dark current.  Full well (and expected gain).  Non-linearity.  Cross-talk.  QE(lambda).  Lens reflectivities.

    1. I second this. I haven't been able to find this information (specifically the full well depth) on the camera confluence page either...

      1. Sorry, only recently saw this. I have added the info to the table.

  6. Pixel scale also ..

  7. While reviewing the key figures section of the for scientists web site, we found a few numbers that could be added to that page. Here is a list, with some guesses 

    Optical System:
    Etendue ( AΩ ) = 319 meter2degrees2
    Field of View =3.5 degrees (9.6 square degrees)
    Primary mirror diameter =8.4 m
    Effective clear aperture =6.68 m (on-axis)
    Mean effective aperture = 6.423 m (area weighted over FOV)
    Final f-ratio =f/1.234

    Imaging System:
    Pixel count =3.2 Gpixels
    189 4kx4k science CCD chips
    Pixel pitch = 0.2 arcsec/pixel
    Pixel size = 10 microns
    **Filling factor / chip gap (>90 %)

    Photometric accuracy 10 mmag
    Astrometric accuracy 50 mas
    Astrometric precision 10 mas

    Spectral Response:
    System 50% response points (nm) (plus spectral response graph/table,
    u 324-395
    g 405-552
    r 552-691
    i 691-818
    z 818-921
    y 922-997
    Depth for one year (DR1) ?
    Real-time alert latency =60 seconds
    PSF : median (.67 arcsec) - distribution?
    Time to change a filter (max, median)
    typical number of filter changes per night, max per lifetime of the system

    Site coordinates: (Cerro Pachon) lat -30:14:40.68 lon -70:44:57.90
    Altitude: 2647m
    53% of night time is photometric

  8. Q. Time to take one visit in normal survey mode has a clear explanation, but the mean slew time used (for the mean)  is stated as 10 sec. Is that from requirements? Because the only reference to this number is the minion number 6.8 noted in `Expected median slew time between visits`. For the latest baseline, this seems to be 8.1 for WFD. 

    1. Yes, this (and I believe the median as well) is from OSS-REQ-0289 (Time Interval Between Visits).  Given the variability in cadence design and simulations thereof, sticking with the worst case for this page seems best.

  9. Eric Aubourgthese are excellent suggestions! The team is working

    on verifying the new entries. Could you please provide the source of 

    information for the altitude of 2647 m (the overview paper uses 2652 m)
    and for the 53% of nights being photometric? Also, did you compute the
    50% response points yourself, or copied them from somewhere in our

    throughput github pages? 

    1. Hi Zeljko Ivezic. Those figures were taken from various sources, especially the old version of the "for scientists" section of the lsst web site and github/confluence. They should be checked and made consistent… We gathered them as we were trying to update the web site in June. It would be great to have verified key figures on the web site.