The annual Data Release Production is scheduled to take 12 months. The following diagram shows the notional budget for each component.
The Data Release Production processes all data up to a cutoff date. This date is expected to be just before the execution of the DRP.
The DRP will run to the greatest extent possible with a single release of the LSST Stack code. That release will have been integrated and tested for both scientific and computational performance in the staging environment using all available test data prior to the beginning of the DRP.
First, the annual Calibration Products Production is executed to generate master calibration images and a new version of the calibration database for this data release, using all available information.
Next, a single region of the sky, amounting to about 1/12th of the total survey area, is processed as if it were the entire survey. This initial run provides a final verification that the software is ready to perform the DRP. If any problems are detected, emergency patches may be applied.
The main DRP processing then begins. Each visit is processed independently first. The results from Source measurements on those visits are used to perform global photometric and astrometric calibration. The visits are then processed again, in sky tile order. Sections of various coadds, as specified in the DPDD, and templates are generated. Measurements on the coadds by deep detection produce a variety of CoaddSources. The templates are meanwhile used to compute difference images, which are then measured to calculate the reprocessed Level 1 data products (DiaSources and DiaObjects). Unassociated DiaSources are fed to MOPS to generate SSObjects. The Sources, CoaddSources, DiaSources, Objects, DiaObjects, SSObjects, and external catalogs are all combined, associated, and deblended to generate a final list of Objects. These are then measured using Multifit and forced photometry in the Object Characterization step.
SDQA is performed on all outputs as they are generated, and outputs that pass SDQA checks are ingested into the database.
Finally, after the entire release has been generated, checked, and certified, the oldest on-disk release in each Data Access Center is swapped for this current release, and the release is made active.