The Target-selection Pipeline for the Dark Energy Spectroscopic Instrument

In 2021 May, the Dark Energy Spectroscopic Instrument (DESI) began a 5 yr survey of approximately 50 million total extragalactic and Galactic targets. The primary DESI dark-time targets are emission line galaxies (ELGs), luminous red galaxies (LRGs) and quasars (QSOs). In bright time, DESI will focus on two surveys known as the Bright Galaxy Survey (BGS) and the Milky Way Survey (MWS). DESI also observes a selection of"secondary"targets for bespoke science goals. This paper gives an overview of the publicly available pipeline (desitarget) used to process targets for DESI observations. Highlights include details of the different DESI survey targeting phases, the targeting ID (TARGETID) used to define unique targets, the bitmasks used to indicate a particular type of target, the data model and structure of DESI targeting files, and examples of how to access and use the desitarget code base. This paper will also describe"supporting"DESI target classes, such as standard stars, sky locations, and random catalogs that mimic the angular selection function of DESI targets. The DESI target selection pipeline is complex and sizable; this paper attempts to summarize the most salient information required to understand and work with DESI targeting data.


INTRODUCTION
As sky surveys have expanded in size and sophistication, the accompanying software has also become increasingly complex. Improvements in software pipelines are typically driven by, and proceed hand-in-hand with, augmentations in instrumentation and more ambitious scientific goals. Some examples of these algorithmic leaps include the development of techniques to perform spectroscopic reductions in near real-time to improve the completeness of redshift surveys (e.g. Tonry & Davis 1979), and the automated cataloging of galaxies using scanning machines in order to better sample and characterize large-scale-structure (e.g. Loveday et al. 1992).
With the advent of multi-object spectrographs (e.g. Bagnuolo et al. 1990; Lewis et al. 2002;Smee et al. 2013), spectroscopic surveys have greatly expanded in scope. This has facilitated larger campaigns with objectives that required greater accuracy and precision. Surveys with lower shot-noise are more prone to being affected by subtly heterogeneous source catalogs, and survey pipelines have had to became increasingly elaborate to mitigate inhomogeneity. Targeting for the 2dF Surveys, for example, incorporated color equations to account for different emulsions on glass plates versus films, and the survey pipeline generated masks to mitigate density fluctuations caused by bright stars, varying flux limits, satellite tracks and plate defects (e.g. Colless et al. 2001Colless et al. , 2003Croom et al. 2004;Smith et al. 2005).
The Sloan Digital Sky Survey (SDSS; York et al. 2000), in particular, greatly advanced the frontiers of software development for large sky surveys. Specialist pipelines were developed for imaging reductions (Lupton et al. 2001;Blanton et al. 2011), spectroscopic reductions, source classifications and redshift-fitting (Sub-baRao et al. 2002;Bolton et al. 2012), and tiling and fiber assignment (Blanton et al. 2003), among other goals. Crucially, the source code for these pipelines was made public, and the associated algorithms and data model were extensively documented (e.g. Stoughton et al. 2002).
Targeting pipelines also advanced with later iterations of the SDSS, such as the SDSS-III Baryon Oscillation Spectroscopic Survey (BOSS; Dawson et al. 2013) and the SDSS-IV extended Baryon Oscillation Spectroscopic Survey (eBOSS; Dawson et al. 2016). The BOSS and eBOSS quasar targeting pipelines (Ross et al. 2012;Myers et al. 2015), for instance, not only incorporated long-established approaches such as color cuts and cross-matches to multi-wavelength catalogs, but also implemented targeting techniques based on variability in multi-epoch data (Palanque-Delabrouille et al. 2011, forced photometry (Lang et al. 2016), ma-chine learning methods (Yèche et al. 2010), and rigorous Bayesian approaches (Kirkpatrick et al. 2011;Bovy et al. 2011Bovy et al. , 2012. The Dark Energy Spectroscopic Instrument (DESI) is a robotic, fiber-fed, highly multiplexed spectroscopic surveyor that operates on the Mayall 4-meter telescope at Kitt Peak National Observatory (DESI Collaboration et al. 2016aCollaboration et al. , 2022. DESI, which can obtain simultaneous spectra of almost 5000 objects over a ∼ 3 • field (DESI Collaboration et al. 2016a;Silber et al. 2022, T. Miller et al. 2023, is currently conducting a five-year survey of about a third of the sky. This campaign will obtain spectra for approximately 40 million galaxies and quasars (Levi et al. 2013;DESI Collaboration et al. 2016b), which will produce about an order-of-magnitude more extragalactic redshifts than measured by BOSS and eBOSS combined (see Ahumada et al. 2020, for BOSS and eBOSS source statistics). DESI spectra span wavelengths of ∼3600-9800Å with a blue-end resolution of ∼2000 growing to ∼5000 at the red-end. Effective exposure times are ∼1000 seconds for dark-time targets and ∼180 seconds in bright time (see §4 of Guy et al. 2022). Quasar targets that DESI measures to be at redshifts of z ≥ 2.1 are observed multiple times to improve signal-to-noise in the Lyman-α Forest, and can ultimately amass ∼4000 seconds of exposure time (see §4 of E. Schlafly et al. 2023, in preparation).
The sheer scale of the DESI experiment necessitates multiple supporting software pipelines and products. These include significant imaging from the DESI Legacy Imaging Surveys (Zou et al. 2017;Dey et al. 2019, D. Schlegel et al. 2023, an extensive spectroscopic reduction pipeline (Guy et al. 2022), a template-fitting pipeline to derive classifications and redshifts for each targeted source (Redrock; S. Bailey et al. 2023, in preparation), a pipeline to assign fibers to targets (A. Raichoor et al. 2023, in preparation), a pipeline to tile the survey and to plan and optimize observations as the campaign progresses (E. Schlafly et al. 2023, in preparation), and a pipeline to select targets for spectroscopic follow-up (desitarget; this paper).
Target selection approaches for DESI are, themselves, varied and extensive. Other publications that accompany this work include a paper describing the DESI Survey Validation (SV) phase (DESI Collaboration et al. 2023, in preparation), two papers describing how visual inspection of spectra of targets acquired during SV produced truth tables to inform target selection for the DESI Main Survey (Alexander et al. 2022;Lan et al. 2022), and a series of five papers detailing the selection of DESI bright-time and dark-time science targets (Chaussidon et al. 2022a;Zhou et al. 2022;Raichoor et al. 2022;Cooper et al. 2022;Hahn et al. 2022, see also §4.1.1).
In this paper, we detail the DESI target selection pipeline, which we refer to throughout as desitarget. In §2 we give an overview of how DESI uses bitmasks to record which targets were selected by each classification algorithm. In §3 we detail the unique identification number (TARGETID) that DESI adopts to track targets. In §4 we give a technical overview of the main DESI target classes. In §5 we highlight some important known issues and caveats that should be considered when working with DESI targets. Finally, we present some closing thoughts in §6. Throughout this paper, code examples are given in the Python programming language and HEALPixel 1 nside numbers (Górski et al. 2005;Zonca et al. 2019) are always expressed in the NESTED scheme. The desitarget codebase, and the entire history of its development, is publicly accessible 2 . Much of the data model for files produced by desitarget, including definitions of quantities in these files, is also available online 3 .

BITS AND BITMASKS
The chief purpose of the desitarget pipeline is to determine which sources selected by a variety of algorithms will be targeted for follow-up spectroscopy by DESI. To record that a specific source has been selected by a particular targeting algorithm, desitarget uses a number of bitmasks. A tutorial to further help elucidate DESI bitmasks is available on GitHub 4 .
The full set of targeting bitmasks assigned by desitarget will be tabulated in forthcoming DESI Data Release papers (e.g., DESI Collaboration et al. 2023, in preparation). Here, though, we will introduce (and refer to) some of the principal DESI targeting bitmasks to help illustrate the functionality of the desitarget pipeline.

An Overview of DESI Target Classes
The primary dark-time target classes observed by DESI (DESI Collaboration et al. 2016b) are emission line galaxies (ELGs; Raichoor et al. 2020Raichoor et al. , 2022, luminous red galaxies (LRGs; Zhou et al. 2020Zhou et al. , 2022 and quasi-stellar objects (QSOs, also known as quasars; Yèche et al. 2020;Chaussidon et al. 2022a). During survey bright-time, DESI also targets galaxies as part of a dedicated Bright Galaxy Survey (BGS; Ruiz-Macias et al. 2020;Hahn et al. 2022), and a variety of Galactic sources as part of a Milky Way Survey (MWS; Allende Cooper et al. 2022). Finally, to calibrate the output from its spectroscopic pipeline, DESI also targets calibration sources such as standard stars and blank sky locations. These target classes will be described in more detail in §4.
The DESI survey also incorporates a plethora of programs that are not driven by the main cosmological goals of the primary campaign. These are referred to as "secondary" programs, and include, for example, studies of high-proper-motion stars in our Galaxy, a campaign to target M31 , studies of peculiar velocities in local galaxies, broad censuses of extragalactic sources, follow-up of gravitational lenses, and identification of quasars at redshifts of z ∼ > 5 (J. Yang et al. 2023, in preparation). These target classes will be detailed in forthcoming DESI Data Release papers (e.g., DESI Collaboration et al. 2023, in preparation)-but we include some technical details about DESI secondary targets in §3.2 and §4.6. All DESI primary targets, and the vast majority of secondary classes, are selected using properties from imaging. Based on algorithms applied to these photometric quantities, a bitmask (see §2.2) is constructed to designate a source as being a member of a particular target class or classes. Note that as the bits corresponding to "QSO," "ELG," "LRG," etc. are assigned using only imaging quantities, subsequent DESI spectroscopy will reveal that some sources are inconsistent with their target class or classes, i.e., not all QSO targets will have quasar-like spectra.

A Brief Introduction to Bitmasks
As an example of how a bitmask is constructed, consider two types of source that DESI will target; LRGs and ELGs. Let's assume that LRGs are designated by bit 0 and ELGs by bit 1, and that the name of the variable used to store the targeting bitmask is DESI TARGET. Then, DESI TARGET = 1 (≡ 2 0 ) would signify a source selected by the LRG targeting algorithm, DESI TARGET = 2 (≡ 2 1 ) would signify a source selected by the ELG targeting algorithm and DESI TARGET = 3 (≡ 2 1 + 2 0 ) would signify a source selected by both of the LRG and ELG targeting algorithms. The desitarget pipeline uses 64-bit signed integers to represent bitmasks. But the desitarget bit-values that are used to distinguish target classes are never negative numbers, so each of the bitmasks can register up to 63 distinct selections (bit 0 to bit 62) 5 .
During this phase, a number of target classes were defined to calibrate the instrument, such as dither stars to test pointing models, standard stars to test throughput, and "first light" science targets. The commissioning phase of DESI is typically abbreviated as CMX by the desitarget pipeline. Although a general reader is unlikely to encounter commissioning targets, it should be noted that: -CMX observations were highly preliminary and, for expediency, were not carefully tracked and documented by desitarget. From a targeting perspective, CMX observations therefore should not be used for general scientific analyses. Nevertheless, broadly, commissioning bitmasks can be handled by replacing occurrences of SV1 or sv1 (see below) with cmx or CMX and occurrences of desi mask with cmx mask 6 . -The CMX data a general reader is most likely to encounter is a tile of observations of M33 with TILEID = 80615 7 .
• Prior to commencing its main 5 yr mission, DESI underwent a period of Survey Validation (see DESI Collaboration, 2023, in preparation). The major objectives of this phase were to validate the endto-end DESI systems, to provide observations to refine the purity and completeness of the targeting algorithms that would be used for the main DESI survey, and to stress-test the procedures that would be needed for day-to-day DESI operations. Survey Validation is typically abbreviated as SV by the desitarget pipeline, and SV itself was divided into three distinct stages: -SV1: The first iteration of SV ran, mainly 8 , from the night of 20201214 to the night of 20210402 9 and encompassed DESI tiles with TILEID numbers in the interval 80605-80975 10 . A total of 189 tiles were targeted in the context of SV1. These tiles were spread widely across the sky and were observed over multiple months in order to sample a wide range of observational conditions. The main goals of SV1, from a data pipeline perspective, were to collect sufficient spectra of different target classes to train target selection algorithms and to refine the spectroscopic pipeline (see also Guy et al. 2022). The targeting algorithms deployed during SV1 were deliberately loosened to allow targeting to be refined. -SV2: The second phase of SV (also referred to as "the 0.1% Survey") ran from the night of 20210324 to the night of 20210511, covering DESI tiles in the interval 81000-81099. During SV2, 39 tiles were observed. The purpose of SV2 was to test critical end-to-end operational procedures, such as establishing the processing of "Merged Target Ledgers" (MTLs; see E. Schlafly et al. 2023, in preparation), in which spectroscopic classifications and redshifts are used to decide whether a target requires additional observations. -SV3: The final stage of SV (also known as "the One-Percent Survey," but typically referred to as SV3 in this paper) ran from the night of 20210405 to the night of 20210610, although it was mostly completed by the end of the night of 20210513. SV3 covered DESI 8 A few SV1 observations were conducted alongside SV2, and occasional SV1 tiles were observed even later. 9 The night of a DESI observation is recorded in the form YYYYM-MDD where Y=Year, M=Month and D=Day. 10 In January 2022, an additional SV1 tile was observed with TILEID=82633.
tiles with IDs in the interval 1-596. During SV3, 488 tiles were observed, 239 in dark time, 214 in bright time, and 35 as part of a "backup" program (see §2.5 and §4.1.2).
Observations were conducted in 20 separate "rosette" patterns consisting of 11 overlapping pointings arranged in a circle comprising a little more than 7 deg 2 of total area. A few additional passes were made in some rosettes to further increase completeness. The main goals of SV3 were to conduct DESI observations in a mode that mimicked main-survey observations, and to sample main-survey target classes at high completeness.
The DESI collaboration typically refers to SV1 as "Survey Validation" and SV3 as "the One-Percent Survey" (again, see DESI Collaboration et al. 2023, in preparation). But, this paper will refer to the entire period encompassing SV1, SV2 and SV3 as "Survey Validation," as such terminology better matches the nomenclature embedded in the desitarget data model.
• Finally, DESI embarked upon its five-year Main Survey, which is typically denoted main by the desitarget pipeline. First observations for the Main Survey began on 20210514. The target classes that had been refined using spectra from SV1 and observed at high completeness during SV3 then began to be observed in earnest. Observations were conducted using procedures that were introduced during SV2 and finalized near the end of SV3.

DESI Bitmask Denominations, Values and Access
The DESI bit-names and bit-values are available on GitHub for SV1 11 , SV2 12 , SV3 13 and the Main Survey 14 . Note that, although the vast majority of targets for SV1 used version 0.51.0 of the desitarget code, some SV1 from desitarget.sv3.sv3 targetmask import desi mask, bgs mask, mws mask, scnd mask main from desitarget.targetmask import desi mask, bgs mask, mws mask, scnd mask a desi mask, bgs mask, mws mask and scnd mask, here, correspond to the different target type columns listed in Table 2. Any of the individual masks can be omitted from the command. The specific column names used to store each target type for each survey phase are listed in Table 2. It may be helpful to illustrate the use of DESI targeting bitmasks with a short example. Say we wish to know if a target has been selected by (at least) the quasar targeting algorithm in the Main Survey. Further, let's assume that the appropriate data file has been read into a structure called targs, then the necessary commands to determine which indexes in targs correspond to quasar targets would be: Much additional functionality exists for working with DESI targeting bitmasks. Two utility functions, in particular, are worth mentioning. First, any integer (i) can be converted to the corresponding bitnames using the mask.names(i) function. For example, desi mask.names(7) will return the list ['LRG', 'ELG', 'QSO']. Second, the function main cmx or sv can be used to directly extract the relevant bitmasks, column names, and survey phase (detailed in Table 1 and 2) from a DESI data file. For example: from desitarget.targets import main cmx or sv column names, masks, survey = main cmx or sv(targs) .

Observing Conditions and Programs
Depending on the quality of the observing conditions at Kitt Peak, DESI pursues one of three different observing programs, corresponding to three different sets of targets (see, e.g., E. Schlafly et al. 2023, in preparation, for more details). During DARK time, DESI observes ELG, LRG and QSO targets; the bits for such targets are stored in columns with names that resemble DESI TARGET (see Table 2) and are described in the desi mask mask (see Table 1). During BRIGHT time, DESI observes BGS targets, stored in columns like BGS TARGET and recorded in the bgs mask mask, and MWS targets, stored in columns like MWS TARGET and recorded in the mws mask mask. Finally, during more marginal observing conditions, DESI pursues a BACKUP program (see §4.1.2); the bits that indicate targets that are part of the backup program are also stored in columns like MWS TARGET and are recorded in the mws mask mask.
Because the same target can be selected to be observed in both, e.g., bright and dark time, it is useful to record the specific programs associated with each target. In DESI targeting files, such information is stored in a column called OBSCONDITIONS and the corresponding bit-names and bit-values are accessible in the obsconditions mask 15 , which can be accessed using a similar command to those listed in Table 1: from desitarget.targetmask import obsconditions .
Note that there are some placeholder bits included in the obsconditions mask (e.g., GRAY) that were deprecated for the DESI Main Survey or that were never adopted for DESI operations.

TARGETID -A UNIQUE IDENTIFIER FOR DESI TARGETS
DESI utilizes a unique ID, similar to the objID used by the SDSS (e.g. Stoughton et al. 2002), to track targeted objects through the end-to-end pipeline. In DESI, this unique targeting ID is denoted TARGETID. It is critical for DESI operations that each TARGETID is associated with only one object. However, it is less crucial that each object is associated with only one TARGETID , particularly for targets that will not be used in the key DESI large-scale-structure analyses. So, it is important to note that (for most cases) TARGETID does not have coordinate-based provenance-and targets at the same coordinates can therefore have a different TARGETID. Instead TARGETID is constructed using information from the imaging survey used to select a target.
An illustrative example in DESI might be a target selected from the Legacy Imaging Surveys versus a target selected using only information from Gaia (e.g. Gaia Collaboration et al. 2018a). Although an object might share a location on the sky in Gaia and the Legacy Surveys, desitarget does not perform an exhaustive coordinate-match across all possible input surveys. Therefore, such a target can have a TARGETID derived from Legacy Surveys information (see §3.1) and a TARGETID derived from Gaia information (see §3.1.5).
An exception to the rule that the DESI TARGETID is not coordinate-based is negative values of TARGETID. Negative TARGETIDs, which are described in §3.3.2, are used to distinguish sky locations that need to be rapidly assigned during survey operations. Figure 1 depicts the bitmask that defines the DESI TARGETID 16 . In the rest of this subsection, we will detail the bits that comprise a "primary" TARGETID, by which we mean the unique identifier for a source that is part of one of the primary DESI subprograms, i.e., LRGs, ELGs, QSOs, the BGS or the MWS, rather than being part of a secondary program (see, e.g., Table 2).

The OBJID and BRICKID Bits
Imaging from the Legacy Surveys (Dey et al. 2019, D. Schlegel et al. 2023, on which DESI targeting draws, is processed through the legacypipe pipeline 17 to produce catalogs of sources. The legacypipe code extracts these sources in individual regions of the sky denoted bricks. The bricks cover an area of roughly 0.25 • × 0.25 • on the sky, and each brick is assigned a unique integer from 1 to 662,174. Each extracted source in each brick is assigned an integer from 0 to N − 1, where N is the total number of sources extracted by legacypipe in the brick. The unique brick number is called BRICKID and the unique source number is called OBJID 18 . Figure 1. The bits that comprise a positive DESI TARGETID. The least significant bit (i.e. 2 0 ) is depicted to the right of this diagram. The 58 least significant bits (2 0 -2 57 ) record information from the Legacy Imaging Surveys. The next two most significant bits are Boolean flags that indicate whether a target is drawn from a mock or random catalog (2 58 ) and whether a target is a blank sky location (2 59 ). The remaining two populated bits (GAIADR), which are used to indicated targets that are selected solely using Gaia information, store the Gaia Data Release number. (2 60 -2 61 ). Bit 62 is not used. Note that DESI also uses a differently structured negative TARGETID to distinguish some sky locations (see §3.3.2).
Together, OBJID and BRICKID encode a unique legacypipe-extracted source. TARGETID inherits these two numbers as a method to track unique sources, and they occupy the two least significant sets of bits in TARGETID (see Figure 1).

The RELEASE Bits
OBJID and BRICKID encode a unique source, but not the imaging reductions from which that source was extracted. To track this, starting with Data Release 4 (DR4), the Legacy Surveys included a column RELEASE that records image-processing information 19 . RELEASE is an integer in the 1000s, with the first digit denoting the Data Release and subsequent digits representing the photometric system.
The Legacy Imaging Surveys commenced with Data Release 1, which means RELEASE numbers < 1000 have no pre-defined meaning. As we will discuss more in subsequent sections, we take advantage of this extra bitspace by using integers with RELEASE < 1000 to indicate a target that (potentially) was selected using information from beyond the Legacy Surveys.

The MOCK Bit and TARGETIDs for Random Catalogs
In preparation for going on-sky, the DESI collaboration produced multiple catalogs of ersatz targets to stress test the end-to-end software pipelines and to model survey outcomes. The MOCK bit is a single bit (again see Figure 1) that encodes whether or not a source is derived from such "mock" data. In addition, the desitarget pipeline includes a randoms module that can be used to produce catalogs of points that mimic the selection function of sources in the Legacy Imaging Surveys (see §4.5.1). A value of "1" for the MOCK bit indicates that a target was generated as part of either a "mock" data run or a random catalog. 19 See, e.g., https://www.legacysurvey.org/release/.
Information at locations created in desitarget random catalogs is derived at the pixel-level using images from the Legacy Surveys (again see §4.5.1). As such, RELEASE and BRICKID are inherited directly from the Legacy Surveys for points in random catalogs. Within a brick, desitarget assigns an OBJID integer for random points sequentially in order of Right Ascension (henceforth RA), such that the object with the smallest RA is assigned OBJID=0. Ordering by RA in this manner guarantees that random points in northern and southern portions of the Legacy Surveys (see §4.1.3) have the same OBJID. Note that even though [RELEASE, BRICKID, OBJID] for random points can resemble similar combinations for real sources from the Legacy Surveys, random points will always have a distinct TARGETID because the MOCK bit will be set.

The SKY Bit and TARGETIDs for Blank Skies
The desitarget pipeline also generates blank sky positions to facilitate spectral calibration (see §4.4.1). The SKY bit is a single bit (again see Figure 1), which, if set, indicates that a target corresponds to a sky position.
The majority of blank sky locations in the DESI footprint are assigned at the pixel-level using blobmaps from the Legacy Surveys imaging (again see §4.4.1). For these sky locations, RELEASE and BRICKID are therefore inherited directly from the Legacy Surveys. Within each brick, the desitarget code assigns sequential integers for OBJID. This schema is guaranteed to produce unique values of TARGETID as setting the SKY bit distinguishes combinations of [RELEASE, BRICKID, OBJID] from any target derived from the Legacy Surveys source catalogs.
DESI also creates files of "supplemental" sky targets to cover areas outside of the Legacy Imaging Surveys (see §4.4.2), which are assigned by using a catalog-level match to avoid bright sources in Gaia. If these supplemental skies are near a bright object in Gaia, they are retained but are designated to be BAD SKY (see §4.4.2 for more details). For BAD SKY supplemental sky targets, RELEASE is set to 0 and the GAIADR indicative bits (see §3.1.5) are set to the Gaia Data Release integer used to assign supplemental skies (typically '2' to indicate Gaia DR2). For other supplemental skies, both the RELEASE and GAIADR bits are populated with the Gaia DR integer. BRICKID is set to the nside = 256 HEALPixel integer of each supplemental sky location, and OBJID is a sequential integer generated within each HEALPixel. The SKY bit, of course, is also always set. Note that setting RELEASE < 1000 guarantees that the TARGETID for supplemental skies will always differ from the TARGETID for pixel-level skies, as there were no Legacy Surveys Data Releases prior to DR1.

The GAIADR bits and Gaia-based TARGETIDs
A substantial set of DESI targets are derived solely using information from Gaia. These targets generally lie outside of the Legacy Imaging Surveys footprint and are intended for BACKUP observations (see §2.5). Objects that are targeted purely using Gaia have the GAIADR bits (depicted in Figure 1) set to the Gaia Data Release used to select the target (i.e '2' for Gaia DR2) 20 . For targets that are selected solely using Gaia, BRICKID is populated with the integer of the nside = 32 HEALPixel that contains the target, and OBJID is set to a sequential integer generated within each HEALPixel. Note that this schema differs slightly from the one described for supplemental skies in §3.1.4 (for which nside = 256 is adopted when populating BRICKID).

Secondary Targets
In addition to "primary" target classes, DESI observes a number of secondary programs (see also §4.6) proposed by the wider DESI collaboration to address specific science goals. In many cases, proposers specified that targets should not share the observing characteristics of a DESI primary target. For example, a supernova in a galaxy that is part of the BGS sample should not be considered to be the same target as the galaxy itself. Such a supernova might not be at exactly the same location as the galactic center, and may, for instance, need to be scheduled for dark-time observations rather than during bright time. The end-to-end DESI pipeline uses TARGETID to ensure correspondence between a target, an allocated fiber, and the resulting spectrum. Therefore, secondary targets that cannot be merged with a corresponding primary target (see §4.6) must, by definition, have a different TARGETID. In some instances, there is an unused primary TARGETID, because a secondary target that is also a source from the Legacy Surveys is not part of the primary DESI campaign. In those instances, a secondary target is simply assigned the primary TARGETID detailed in §3.1. Still, there are cases where a secondary target does not have a corresponding source in the Legacy Surveys or a secondary target is prevented from being merged with a primary target that is already using the primary TARGETID. In those cases, the desitarget pipeline constructs a "secondary" TARGETID that is guaranteed to always be unique, as well as distinct from the TARGETID of any primary target.

The General TARGETID for Secondary Targets
The secondary TARGETID is structured similarly to the schema displayed in Figure 1. BRICKID has the same definition for secondary and primary targets-it is the number of the brick from the Legacy Surveys on which the secondary target lies-but OBJID and RELEASE have different meanings. OBJID, for secondary targets, records the row that a target was listed in a file of secondary targets prepared by a proposer to pass to the desitarget pipeline, after first partitioning by BRICKID. RELEASE, for secondary targets, corresponds to: where X is the iteration of SVX during which the target was observed (see, e.g., Table 2); with [X−1] = 5 used to denote the DESI main survey 21 . Here, S is the bit-value from the scnd mask (see, e.g., Table 1). For example, pseudo-RELEASE = 245 would denote secondary targeting bit 45 from the SV3 campaign and pseudo-RELEASE = 534 would denote secondary targeting bit 34 from the main observing campaign. Note that secondary targets that have not adopted the primary TARGETID can always be identified by virtue of having RELEASE < 1000. TARGETID bits other than OBJID, BRICKID and RELEASE are set to zero for secondary targets.

The TARGETID for Targets of Opportunity
When merited, the DESI survey can occasionally be suspended to pursue rapidly designed, dedicated tiles that place fibers on Targets of Opportunity (ToOs). An example science case might be to follow-up potential host galaxies of gravitational waves or neutrino events (e.g. Palmese et al. 2021). DESI targeting also facilitates an observing mode where some ToOs are added to the existing pool of science targets. As with any DESI target class, ToOs must have a unique TARGETID so that they can be tracked by the end-to-end pipeline. ToOs have a TARGETID that follows the model of Figure 1, and BRICKID has the same meaning as for general primary and secondary targets. The list of all DESI ToOs is maintained in a single ledger, to which new targets can be added but not removed 22 , and the OBJID for ToOs is simply the row number of the corresponding target in that ledger. For ToOs, RELEASE is always set to 9999, which is distinct from any other RELEASE value used to encode a TARGETID. The other possible TARGETID bits are set to zero for ToOs.

Tertiary Targets
Occasionally, special tiles need to be rapidly scheduled for a scientific purpose that doesn't comport with the desitarget scheme for Targets of Opportunity. To facilitate prompt observation of such tiles, desitarget reserves RELEASE bits equivalent to 8888 to denote targets that were "directly" assigned fibers. Targets that have a TARGETID with a RELEASE of 8888 were not processed by the desitarget pipeline and are instead maintained and handled by the DESI fiberassign code (A. Raichoor et al. 2023, in preparation). Such programs are sometimes referred to as "tertiary" programs.

Encoding and Decoding TARGETID
The desitarget codebase includes utility functions for extracting the bits depicted in Figure 1 from a TARGETID and for constructing a TARGETID from its constituent bits. These functions will work for all positively valued TARGETID integers.
Both of the encode targetid and decode targetid functions are written with a high degree of flexibility. For example, targetid can be passed to decode targetid as a single integer or as an array. Similarly, encode targetid can be passed a mix of arrays and integers. Additionally, none of the inputs must be passed. This makes it straightforward to encode a TARGETID that is composed of, say, arrays of BRICKIDs and OBJIDs but only a single RELEASE number.

Negative TARGETIDs
Some TARGETID integers in DESI files have negative values. Typically, these correspond to stuck fibers that could not be used by DESI to observe a science target, so were assigned to sky locations on-the-fly (see, e.g., E. Schlafly et al. 2023, in preparation). Assigning stuck fibers to sky locations frees up fibers to be assigned to science targets elsewhere in the focal plane. The least-significant 29 bits encoded in a negative TARGETID correspond to Declination, partitioning in equal bins in a northerly direction with the Dec = -90 • bin corresponding to bit 0. The next-most-significant 30 bits correspond to RA, partitioned in equal bins with the RA = 0 • bin corresponding to the least significant bit. The remaining four bits allow flexibility to record up to 16 different groups of distinct negative TARGETIDs.
The resulting schema allows unique TARGETIDs to be assigned by location at a resolution of ∼1.2 milliarcseconds. Negative TARGETIDs can be created and decoded using desitarget routines as follows: from desitarget.targets import decode negative targetid, encode negative targetid ra, dec, group = decode negative targetid(targetid) targetid = encode negative targetid(ra, dec, group=group) .
Here, decode negative targetid(targetid) will return the lowest-valued bin edge in RA and Dec (i.e. the "lefthand" and "bottom" edges of the bin). A full description of how negative TARGETIDs are handled by the DESI fiber assignment code is provided in A. Raichoor et al. (2023, in preparation).

DESI TARGET CLASSES
In this section, we detail each of the main DESI target classes and the location and structure of the files in which they are stored. We will frequently refer to columns in these files being populated by certain "target selection bits," which are detailed in §2.

Primary Science Targets
The selection and optimization of DESI science targets for SV3 and the Main Survey are described in a series of papers, listed in Table 3.

DESI TARGET i8
Column name differs for SV; see §2.4.

BGS TARGET i8
Column name differs for SV; see §2.4.

MWS TARGET i8
Column name differs for SV; see §2.4.

HPXPIXEL i8
The nside = 64 HEALPixel of the target. b a BASS, MzLS and DECaLS are the individual surveys that comprise the DESI Legacy Imaging Surveys (e.g. Dey et al. 2019).
The photometric system (bok for BASS, mosaic for MzLS and decam for DECaLS) can be derived from the RELEASE number according to https://www.legacysurvey.org/release/. b This nside is stored in the file header as HPXNSIDE.
Bright-time and dark-time science targets are publicly available online for SV1 23 , SV2 24 , SV3 25 and the Main Survey 26 . Each url links to bright and dark sub-directories which contain bright-time (MWS, BGS) and dark-time (ELG, LRG, QSO) targets, respectively. Note that operational procedures were in flux during SV1, meaning that a (very small) subset of SV1 targets can only be found in earlier versions of the target files than 0.51.0. Similarly, a few hundred targets from the DESI Main Survey are only available in the 1.0.0 version of the target files (see §5.1).
The bright/dark sub-directories host files containing targets that are only selected by bright-time/dark-time target selection algorithms. But, every target in each sub-directory has all of the appropriate targeting bits populated. Consider, for instance, a QSO target that is also targeted by the MWS survey. Such a target will appear in the appropriate file in both of the bright/dark sub-directories with the same bits set in the DESI TARGET and MWS TARGET columns. However, a QSO target that is not also targeted by a bright-time survey will only appear in the appropriate file in the dark subdirectory. Similarly, a bright-time target that is not also Files in the bright/dark sub-directories have names of the form AAAtargets-OBSCON-hp-HPX.fits. Here, AAA is sv1, sv2 or sv3 for SV files and is omitted for Main Survey files, OBSCON is either dark or bright, and HPX refers to the nside = 8 integer of the HEALPixel that contains the targets. 27 The contents of each file described in this section are similar. Information is stored in FITS format (Wells et al. 1981) and data is only included in extension 1 of the FITS file. Most of the data columns are directly derived from the DR9 "sweep" and "light curve sweep" catalogs 28 from which DESI Main Survey targets were selected. Additional columns that are derived by desitarget itself are detailed in Table 4.
In Table 5 and Table 6 we show the densities of the principal DESI Main Survey bright-time and dark-time target classes. We also show how the densities of these target classes overlap (i.e. whether a target is included in both of two target classes). For example, Table 6 demonstrates that ∼0.4% (7.6/1910.5) of MWS targets are also quasar targets. This overlap is driven by the MWS MAIN BLUE sample described in §4.1 of Cooper et al. (2022), which contains blue point sources that resemble quasars in imaging. Densities in these b On-diagonal elements represent the density for a target class, with areas derived using the desitarget weight maps (see §4.5.2).
c Off-diagonal elements represent the overlap in density between two target classes.  b On-diagonal elements represent the density for a target class, with areas derived using the desitarget weight maps (see §4.5.2).
c Off-diagonal elements represent the overlap in density between two target classes.
tables are derived from the target files discussed in this section, with areal weights derived using the desitarget pixelized weight maps detailed in §4.5.2. The resulting matrices of densities can also be seen on the front page of the Quality Assurance (QA) web pages described in §4.5.3.

Backup Targets
In addition to other campaigns, DESI pursues a program of "backup" targets when observing conditions are of insufficient quality to collect signal on bright-time or dark-time science targets (see also §2.5). The principal backup targets are listed in the final part of Table 3 and will be detailed in a forthcoming paper (see MWS et al. 2023, in preparation). Backup targets differ from other science targets in that they are selected solely using Gaia information rather than imaging from the Legacy Surveys. As such, the directory structure for the files that contain backup targets differs slightly from that of other science targets, having gaiadr2 in the directory construction instead of dr9 29 . For versions of desitarget starting with 0.52.0, backup targets are stored in a backup sub-directory but prior to 0.52.0, this sub-directory was instead called supp (for "supplemental"). Backup targets used for the DESI Main Survey are derived from a slightly later release of the desitarget code than for other target classes.   The majority of DESI targets are selected from the Legacy Surveys, which comprises three individual imaging campaigns called BASS, MzLS and DECaLS. Because these surveys overlap (see, e.g., Figure 1 of Dey et al. 2019), it is crucial to decide which imaging to use in each area of the sky. To help decide this, the desitarget pipeline adds a PHOTSYS column to targeting files (see Table 4), which is set to 'N' for targets derived using imaging from the "northern" Legacy Surveys (BASS and MzLS) and 'S' for targets derived using DECaLS imaging. A function called targets.resolve in the desitarget pipeline then uses PHOTSYS to determine (or "resolve") which imaging to adopt in a given area of the DESI footprint.
The desitarget resolve function first defines the "northern" sky to comprise areas that are both north of the Galactic plane (in Galactic coordinates) and north of Dec ≥ 32.375 • (in equatorial coordinates). Any area that does not meet both of these criteria is considered to be "southern" area (again, Figure 1 of Dey et al. 2019, may be helpful to visualize these areas). The desitarget resolve function then ensures unique imaging by only retaining targets that are in the northern sky area and that have PHOTSYS == 'N' set, or that are in the southern sky area and have PHOTSYS == 'S' set. Note that no resolve is necessary for targets-such as backup targets-that are selected purely from Gaia data.
The urls from which to retrieve targets that are provided in §4.1.1 all terminate with a resolve directory, indicating that they have been resolved by desitarget into unique targets in areas where the individual Legacy Surveys overlap. It is possible to use the desitarget pipeline to generate all targets in overlapping imaging areas rather than resolving them, and some (very early) versions of DESI targeting files were processed with this option. Such targets end up in a directory structure that includes noresolve instead of resolve.

Gaia DR2 or Gaia EDR3?
Version 0.58.0 of the desitarget code introduced the option of partially using Gaia Early Data Release 3 (EDR3; Gaia Collaboration et al. 2021) for target selection, with a view to optimizing astrometry-based selection of MWS targets without changing Gaia imaging information for selections used by other target classes. Target files processed with this option have a GAIASUB value in the FITS header that is set to True. EDR3 values are obtained by coordinatematching the Legacy Surveys sweep catalogs used for target selection (see §4.1.1) and EDR3 at 0.2 , after first accounting for EDR3 proper motions. The EDR3 columns that are substituted for Gaia in such target files are listed in Table 7.
So, broadly, SV targets were selected using Gaia DR2 and Main Survey targets were selected using imaging quantities from Gaia DR2 and astrometric quantities from Gaia EDR3. An important caveat to this statement is that, as of the time of writing-corresponding to version 2.5.0 of desitargetbackup targets ( §4.1.2) still always use Gaia DR2 for all quantities. This is due to a bug where the Gaia EDR3 quantities are not substituted for backup targets even though the GAIASUB keyword is set to True.

Standard Stars
The DESI survey requires flux standards for spectrophotometric calibration. To achieve this goal, desitarget defines three principal standard star classes to be used inside of the footprint of the Legacy Surveys imaging, with bit-names STD BRIGHT, STD FAINT (see also Table 5 and Table 6) and STD WD 31 , and three classes for use outside of the Legacy Surveys imaging footprint, GAIA STD BRIGHT, GAIA STD FAINT and GAIA STD WD. The Gaia standard star selections are designed to approximate the principal standard star classes but using imaging from Gaia in place of Legacy Surveys quantities. The STD WD and GAIA STD WD classes are identical to each other-as well as to the MWS WD class described in Cooper et al. (2022)-so won't be further detailed here.
The STD BRIGHT and STD FAINT target classes are designed to select Main Sequence F-stars in a similar fashion to the BOSS selection of spectrophotometric standards 32 . Color constraints differ somewhat from those applied in BOSS, though, both because DR9 of the Legacy Surveys does not include deep u-and i-band imaging (unlike the SDSS) and to ensure sufficient flux standards across the DESI focal plane. The overall approach introduces a small fraction of A-type stars, while retaining sufficiently precise flux calibration to measure signal in the Lyman-α Forest. Broadly, the STD BRIGHT target class is intended to be used for calibration during bright-time programs and the STD FAINT target class is intended for use during dark time.
The STD BRIGHT flux standards are selected as detailed in Table 8. The only difference between STD BRIGHT and 31 "WD" denotes a white dwarf. 32 https://www.sdss.org/dr12/algorithms/boss std ts/ c In this table, X denotes that the criterion is applied for all bands from the Legacy Surveys (g, r and z). d g, r, z denote FLUX G, FLUX R, FLUX Z converted to magnitudes and corrected for Galactic extinction.
e The only difference between the STD BRIGHT and STD FAINT target classes is that STD FAINT extends across 16 ≤

PHOT G MEAN MAG < 19.
STD FAINT targets is that STD FAINT targets extend over the magnitude range 16 ≤ G < 19 instead of 16 ≤ G < 18 (in Gaia G-band) 33 . The selection of the GAIA STD BRIGHT and GAIA STD FAINT flux standards is detailed in Table 9. Again, GAIA STD BRIGHT and GAIA STD FAINT targets only differ because GAIA STD FAINT standards extend over the magnitude range 16 ≤ G < 19. The proper motion cuts listed in Tables 8 and 9 are included to help avoid stars in the thick disk of the Milky Way in favor of a more metal-poor halo turn-off population. Thick disk stars are more numerous at distances of a few kiloparsecs from the Sun-but the halo is hotter. Halo stars therefore typically have larger proper motions than thick disk stars at intermediate distances.
The algorithms used to select standard stars remained the same throughout DESI SV and the Main Survey. Gaia-only standards (GAIA STD BRIGHT, etc.) weren't introduced until version 0.48.0 of desitarget-and weren't actually finalized until version 0.50.0-meaning that these standards do not appear in target files that pre-date SV1. As with 33 Standards appropriate for bright-time were also intended to be used in dark-time, but not vice-versa, meaning that the STD FAINT class is a "fainter" extension of the STD BRIGHT selection. Hence the name "STD FAINT" rather than, say, "STD DARK." other target classes (see §4.1.4) the option to substitute Gaia EDR3 astrometric data became available in version 0.58.0 of the desitarget code, and this option was used to produce targeting files for the DESI Main Survey. Because the Gaia-only standards were designed for observations outside of the Legacy Surveys imaging footprint, the data model for these targets is slightly different to that of the principal flux standards. First, the Gaia-only bits (GAIA STD BRIGHT, etc.) can be accessed via the mws mask bitmask and are stored in the MWS TARGET column (see Tables 1 and 2), whereas the principal standards (STD BRIGHT, etc.) can be accessed via the desi mask bitmask and are stored in the DESI TARGET column. Second, the Gaia-only standards, as is the case for all Gaia-only targets, reside in the backup files outlined in §4.1.2 rather than the bright-time and dark-time targeting files outlined in §4.1.1.

Guiding, Focusing and Alignment (GFA) targets
The DESI instrument requires samples of stars to use for guiding, focusing and alignment. Collectively, we will refer to these as GFA targets, or just "GFAs." The desitarget pipeline includes a module called gfa specifically for assembling these targets. GFAs are publicly available online in directories accompanying those described in §4.1.1, where the directory names terminate with gfas instead of targets 34 . Within a gfas directory, files have names of the form gfashp-HPX.fits. Here, HPX refers to the nside = 8 integer of the HEALPixel that contains the GFAs. 35 The selection of GFAs did not significantly change between iterations of SV and the DESI Main Survey. GFA targets essentially comprise all sources in Gaia limited to G < 21 in the Gaia G-band. We include extra imaging information for Gaia sources that are also in the Legacy Surveys sweep catalogs 36 (i.e. that have REF ID > 0) and that are not part of the 2020 Siena Galaxy Atlas (J. Moustakas et al. 2023, in preparation). This ensures that high-precision fluxes and morphologies are retained for GFAs in the primary DESI targeting footprint to make quality cuts downstream of desitarget, if needed.
Between the SV and Main Survey phases of DESI the desitarget.gfa code was updated to include the option of substituting Gaia-based values from Gaia EDR3 in place of values from Gaia DR2 (see also §4.1.4). GFA targets for the DESI Main Survey included this substitution. In general, files of GFAs that were run with Gaia EDR3 have a GAIADR value in the FITS header that is set to "edr3". For GFAs that have a match in the Legacy Surveys sweep catalogs, only the columns in Table 7  Gaia EDR3. For GFAs that do not match a Legacy Surveys source (i.e. typically objects outside of the Legacy Surveys imaging footprint) all Gaia-derived quantities are updated to EDR3. Some sources that appear in Gaia-particularly in DR2do not have measured proper motions. As astrometric information is essential for DESI guiding, the GFAs incorporate proper motions from the First U.S. Naval Observatory Robotic Astrometric Telescope Catalog (URAT; Zacharias et al. 2015) where Gaia proper motions are missing. Only proper motions for URAT sources that match a Gaia source within 0.5 are substituted for missing Gaia values. The desitarget code has the option of turning off this URATsubstitution mechanism. GFA targets that did include substitution of URAT proper motions in place of missing Gaia values can be identified by having NOURAT set to False in the FITS header of the GFA file.
All of the columns in the desitarget GFA files are derived from the Legacy Surveys sweep catalogs 37 or are provided in Table 4, with the exception of URAT ID, URAT SEP and GAIA PHOT G N OBS. The URAT ID column records the recommended identifier for URAT1 sources (see http://cdsarc. u-strasbg.fr/ftp/I/329/ReadMe), URAT SEP is the separation (in arcseconds) between a URAT source and a GFA target, and GAIA PHOT G N OBS records the number of observations in G band from Gaia (which is useful for characterizing variable sources downstream of desitarget).
In addition, the MORPHTYPE column described in Table 4 has a different provenance for GFA targets that do not have a match in the Legacy Surveys. For such Gaia-only GFAs, a source is recorded as point-like if where G denotes Gaia G-band magnitude (without any correction for Galactic extinction; GAIA PHOT G MEAN MAG), AEN denotes GAIA ASTROMETRIC EXCESS NOISE, and A is 0.5 for Gaia DR2 or 0.3 for EDR3. Sources which do (do not) meet the criterion in Eqn. 2 are designated GPSF (GGAL) in the MORPHTYPE column.

Blank-sky Locations
The DESI fiber allocation software (A. Raichoor et al. 2023, in preparation) assigns fibers to empty or "blank" locations that the DESI spectroscopic pipeline (Guy et al. 2022) uses to perform sky subtraction. To assign these fibers, DESI operations utilizes pre-calculated lists of sky locations that are expected to include minimal flux from astronomical sources when integrated over a DESI fiber. The desitarget pipeline 38 assembles such lists of blank sky locations using two different techniques, a pixel-level approach and a Gaiaavoidance approach, which we describe in this section.
In addition, as of the Main Survey, DESI operations software determines, on-the-fly, whether stuck fibers in the DESI focal plane would collect significant flux during survey observations. Where possible, these stuck fibers then become part of the sky budget, which releases other fibers that can then be used to observe science targets (see §3.3.2). Reassigning sky locations on-the-fly is detailed in A. Raichoor et al. (2023, in preparation) andE. Schlafly et al. (2023, in preparation).

Pixel-based Sky Locations
The legacypipe software used by the Legacy Surveys to extract sources from astronomical images operates on areas, called "blobs," in which pixels have signal that exceeds a certain detection threshold. The legacypipe code builds maps where pixels that lie in a particular blob are set to a positive integer that encodes that blob and pixels that aren't in any blob are set to -1. These "blob maps" are created for each brick of the Legacy Surveys and are available in the metrics sub-directory of the DR9 Legacy Surveys release (D. Schlegel et al. 2023, in preparation), with names resembling metrics/000/blobs-0003m015.fits.gz 39 . The desitarget code adapts these blob maps by setting all pixels that do (do not) have a value of -1 to True (False), essentially building a pixel-map that stores values of True where no sources are detected. The resulting source-detection-maps share the Legacy Surveys native resolution for a brick of 3600 × 3600 38 Using a module called skyfibers. 39 For additional information regarding the Legacy Surveys maps see, e.g., https://www.legacysurvey.org/dr9/files/ #image-stacks-region-coadd. pixels, at 0.262 pixel −1 . So, each map contains 12.96M pixels spread across the approximately 0.0623 deg 2 unique area of a brick.
The desitarget pipeline produces catalogs of pixel-level blank locations at a user-specified density of sky positions. The density used for the Main Survey, for instance, was 18,000 sky locations per square degree, which is easily sufficient to fill the DESI focal plane 40 . The desitarget code then performs a binary erosion on the source-detection-maps (in each unique brick) to achieve the required density. For example, if 18,000 deg −2 sky locations are desired in a 0.0623 deg 2 brick, then a total of about 1120 locations are needed-meaning a brick needs to be eroded until it has dimensions of approximately 34 × 34. In each step of the erosion, in a given grid cell, desitarget calculates the distance (in pixels) of the pixel that is farthest from a detected source; we will refer to this quantity as BLOBDIST. At the conclusion of the erosion procedure, a blank sky target is placed in each grid cell at the location with the maximum value of BLOBDIST. If a grid cell completely overlaps pixels that include source detections, then BLOBDIST will be equal to 0, meaning that there are no completely blank sky locations in that grid.
The desitarget pipeline then uses the photutils (Bradley et al. 2019) routines CircularAperture and aperture photometry to photometer flux at each calculated sky location. Fluxes are measured in the per-filter image and invvar stacks provided by the Legacy Surveys 41 . The measured fluxes, and their associated inverse variances, are then stored as quantities called FIBERFLUX X and FIBERFLUX IVAR X, where X refers to each of the Legacy Surveys optical bands (g, r and z). The measured flux quantities can have multiple values if apertures of different radii are specified when running desitarget 42 , though processing for the DESI SV and Main Survey files exclusively adopted a 0.75 aperture, corresponding to the radius of a DESI fiber.
Given the high density of sky locations required by DESI, it is inevitable that apertures placed at certain positions will not be empty. The desitarget pipeline therefore labels two distinct types of sky locations: particularly good positions and more dubious ones. Sky locations that have any of FIBERFLUX G == 0 or FIBERFLUX IVAR G == 0 or FIBERFLUX R == 0 or FIBERFLUX IVAR R == 0 or BLOBDIST == 0 are referred to as "bad" skies, and are assigned the bit-name BAD SKY 43 . Sky locations that do not meet these criterion are referred to just as "skies" and are assigned the bit-name SKY. The logic behind the criteria that determine whether a sky location is bad is that locations with zero flux or infinite flux variance in the g or r bands are typi-cally missing entirely from the Legacy Surveys-rather than genuinely having flux of exactly zero-and that sky locations with BLOBDIST == 0 certainly intersect a source, as described above.
Pixel-level sky locations are derived within Legacy Surveys bricks. It is important to note that this generally contrasts with other files produced by desitarget, which are stored within HEALPixels. Therefore, before using the desitarget pipeline to make supplemental sky locations by avoiding bright stars in Gaia-which is discussed in the next section of this manuscript-it is important to recast the derived sky locations from a brick-based scheme to a HEALPixelbased scheme. The desitarget function that can be used to achieve this is called skyfibers.repartition skies, and how this function is applied is detailed in the tutorial linked to in §4.7.

Supplemental Sky Locations
To account for the fact that certain areas of the sky covered by DESI might be outside of-or missing in-the Legacy Surveys, the desitarget pipeline generates an additional catalog of sky positions using Gaia. These "supplemental" sky locations are produced at random positions across the sky within HEALPixels at a user-specified density 44 . For SV and Main Survey files, this density was chosen to be 18,000 deg −2 to match the density at which pixel-based sky locations were generated. Supplemental sky locations are then removed if they are within a radius of 2 of any source in Gaia DR2. Finally, to limit the total density of sky locations that could be used by the DESI fiber assignment software, supplemental skies are removed if they share a HEALPixel with a pixelbased sky location at nside = 4096, which corresponds to a resolution of approximately 18,000 deg −2 .
Quantities generated for pixel-based sky locations are also "mocked up" for supplemental sky locations. The BLOBDIST value is set to be the (2 ) radius for avoiding Gaia sources, divided by the 0.262 pixel-scale of the Legacy Surveys imaging. All FIBERFLUX X and FIBERFLUX IVAR X quantities (see 4.4.1) are set to -1. Finally, supplemental skies are assigned the bit-name SUPP SKY; as with other sky locations, this bit is set in the DESI TARGET column and can be extracted using the desi mask bitmask (see §2).

The Data Model for Sky Locations
Files of sky locations derived by desitarget at the pixellevel (see §4.4.1) are available online in the dr9 directory in a similar way to the target files detailed in §4.1.1, with directory names that terminate with skies rather than targets 45 . Files of supplemental sky locations derived by avoiding bright sources in Gaia (see §4.4.2) are available in gaiadr2 directories in a similar manner to what is outlined 44 As with other sky locations, this quantity is stored as NPERSDEG in the header of files produced by desitarget. 45 For example, the appropriate url for the Main Survey is https: //data.desi.lbl.gov/public/ets/target/catalogs/dr9/1.1.1/skies/. in §4.1.2. Directory names for supplemental skies, however, terminate in skies-supp instead of in skies or targets 46 . Within the skies (skies-supp) directory, files have names of the form skies-hp-HPX.fits (skies-supp-hp-HPX.fits). Here, HPX refers to the nside = 8 integer of the HEALPixel that contains the sky locations. As is the case for other desitarget products, the adopted nside is stored in the file header as FILENSID. The skies directory also contains an unpartitioned sub-directory. This stores the original sky locations generated by desitarget before applying the repartitioning code discussed in §4.4.1, i.e., unpartitioned contains files assembled according to which bricks occupy each HEALPixel rather than by which sky locations occupy each HEALPixel. Columns in the skies and supp-skies files are either inherited from the Legacy Surveys sweep catalogs, are provided in Table 4, or were introduced in 4.4.1.

Masking and "Safe" Locations
Locations assigned near very bright stars are potentially unusable for sky subtraction by the DESI spectroscopic pipeline. To help characterize such locations for SV and the Main Survey, the desitarget code 47 was used to compile a "bright star" catalog using all Gaia DR2 sources, supplemented with sources from the Tycho 2 (Høg et al. 2000) catalog 48 . Any matches between Gaia and Tycho 2 within a radius of 10 are first removed from the Tycho 2 catalog to prevent duplication of sources. Then, Gaia-Tycho coordinate matches are performed, after first shifting the location of Gaia sources to the Tycho epoch using Gaia astrometric parameters. Gaia sources with missing proper motions are assigned information from URAT using the same routine as detailed for GFAs (see §4.3). This catalog is then limited to only sources with a magnitude < 12, where the magnitude that is used is Gaia G, Tycho V T , Tycho HP and Tycho BT , in that order of preference-because G is not measured for Tycho-only sources, V T isn't measured for every Tycho source, etc.
A "bright star mask" is then constructed around all sources in this bright star catalog by shifting sources to an epoch of 2023.0 to roughly match the expected central time of the DESI survey. Any sky locations within 5 of this (circa 2023) bright star mask are assigned the bit IN BRIGHT OBJECT from the desi mask bitmask in the DESI TARGET column (see §2).
Similarly, any sky locations within 10 of a bright star are assigned the NEAR BRIGHT OBJECT bit.
Given the extensive sky coverage of the DESI survey, it is impossible to completely avoid placing fibers near bright stars. So, to assist with finding reasonable locations for sky subtraction in regions near bright stars, both the pixel-based and supplemental skies are augmented by additional "safe" locations. Any sky location that has IN BRIGHT OBJECT set is supplemented with six additional, symmetrically placed locations (see Figure 2) around the periphery of the circular mask for any individual star. This placement pattern corresponds to approximately 1 safe location per radius of the mask (with a margin of one extra location), which should be sufficient to ensure a safe location for the vast majority of fibers in the DESI focal plane. These safe locations all have the BAD SKY bit set. They are also assigned the bits IN BRIGHT OBJECT and NEAR BRIGHT OBJECT using the bright star mask (as for any other sky location).
Finally, any pixel-based or supplemental sky locations that have both IN BRIGHT OBJECT and BAD SKY set (including "safe" locations) are removed completely from their respective desitarget output files. This step ensures that any freshly generated safe locations aren't, themselves, inside the boundary of a bright star (again see Figure 2). Sky locations with other combinations of the sky and bright object bits set are retained, but with all of the bits set in the DESI TARGET column to help downstream code identify potentially problematic positions.

Monte Carlo Sampling of the Target-selection Footprint
To help facilitate large-scale structure analyses with DESI, the desitarget pipeline produces Monte Carlo samples that attempt to recreate the angular selection function of the 48 https://heasarc.gsfc.nasa.gov/W3Browse/all/tycho2.html Figure 3. An example use of the desitarget "allsky" random catalogs. Colors distinguish different numbers of g-band observations in DR9 of the Legacy Surveys. For instance, areas colored green (pink) were covered by two (≥ 5) observations. Areas that have zero observations because they are outside of the Legacy Surveys are immediately obvious, as is the lower coverage near the edge of the footprint. The division between BASS and MzLS at a declination of ∼ 32.375 • is also apparent (see also §4.1.3). It is trivial to use these random catalogs to characterize how much area in the Legacy Surveys match specified observational criteria.
Legacy Surveys imaging that was used to select DESI targets. These "random catalogs," and related products, are detailed in this section.

Random Catalogs
The main desitarget module used to create random catalogs is called desitarget.randoms and the main worker function is randoms.quantities at positions in a brick(). Initially, a desired density of random points (deg −2 ) is specified 49 . Then, for each brick in the Legacy Surveys, the desired density is multiplied by the (∼ 0.0623 deg 2 ) brick area, with the resulting number being modified by a (random) draw from the Poisson distribution to produce a final number of points to be sampled in a given brick. Locations (in RA and Declination) are then generated in the brick according to that final number of points.
The desitarget pipeline then queries the Legacy Surveys imaging at the pixel-level, by directly sampling information from the CCDs used to produce the Legacy Surveys. In general, the files used as inputs to desitarget in this context are

FRACAREA f4
Fraction of the HEALPixel with ≥ 1 observation in any band. a

EBV f4
Galactic dust extinction (E[B-V]). b PSFDEPTH X f4 5 √ PSFDEPTH X gives the 5σ flux-detection-limit in nanomaggies for a point source. b, c GALDEPTH X f4 As for PSFDEPTH X but for a round, exponential galaxy of effective radius 0.45 . b, c

PSFSIZE X f4
Weighted average PSF FWHM, in arcseconds. b, d

FRACAREA X f4
Fraction of HEALPixel with ≥ 1 observation in any band with MASKBITS=X. e target name f4 Target density in the HEALPixel for each target class bitname (see Table 3).
a Derived from the NOBS G, NOBS R, NOBS Z quantities in the random catalog.
b This quantity is the median in the HEALPixel from the passed random catalog.
c One each for optical and WISE bands (i.e. X = G, R, Z, W1, W2) where the WISE values are AB, not Vega.
d One for each optical band (i.e. X = G, R, Z).
from the Legacy Surveys coadded stack files 50 . Each random location is converted to a pixel using the World Coordinate System information for a given brick-based stack. The quantities produced for the DESI random catalogs are described in the documentation for the Legacy Surveys 51 . Flux-related columns are derived by integrating over an aperture of a specified radius, as described in §4.4.1. The chosen aperture radius is recorded as APRAD in the header of an output random catalog, and is likely to always be 0.75 , corresponding to the radius of a DESI fiber. In addition to the random catalogs described above, the desitarget pipeline can produce randoms catalogs in bricks that lie outside of the Legacy Surveys footprint. Such catalogs only include a limited number of columns, as most of the informative quantities are not defined where imaging does not exist. The "inside" and "outside" catalogs can also be combined by desitarget to produce all-sky catalogs, which are particularly useful for determining, e.g., the areal coverage of the Legacy Surveys (see Figure 3). Again, columns present in these additional catalogs are detailed in the Legacy Surveys documentation.
As for other files produced by desitarget, random catalogs are available online at the urls specified in §4.1.1. For random catalogs, the directory names terminate with randoms (instead of, e.g., targets) and the most recent desitarget version number used to run a substantial set 50 The stacks are documented at https://www.legacysurvey.org/ dr9/files/#image-stacks-region-coadd. 51 Specifically, under "random catalogs" at https://www. legacysurvey.org/dr9/files/#random-catalogs-randoms.
of random catalogs is 0.49.0 52 . Versions of the random catalogs that have and have not been resolved according to the criteria in §4.1.3 are available in the resolve and noresolve sub-directories. A randomsall sub-directory may also exist, which contains a larger file created by concatenating multiple smaller random catalogs to increase sampling density, as outlined in an accompanying README file. Within the randoms/resolve directory, the inside-the-Legacy-Surveys random catalogs have the form randoms-ISEED-ISPLIT.fits, the outside-the-Legacy-Surveys random catalogs have the form randoms-outside-ISEED-ISPLIT.fits and the combined random catalogs have the form randomsallsky-ISEED-ISPLIT.fits. Here, ISEED refers to the random seed used to produce the catalog and ISPLIT is an integer specifying a particular subset of randoms; the catalogs are split into smaller files from a larger parent set (which is itself randomized) during processing to make them more manageable. The specific integer seed (ISEED) used to produce a given file is stored in the file header as SEED.

Pixelized Weight Maps
The desitarget pipeline-specifically the desitarget.randoms.pixmap() function-can be used to combine files of DESI targets with random catalogs in a convenient HEALPixel-based format to produce maps of important quantities derived from the Legacy Surveys imaging. The resulting "pixweight" files have been made publicly available for both SV3 53 and the Main Survey 54 . Maps of dark-time and bright-time targets are created separately, and so each release directory contains dark and bright subdirectories. The HEALPixel resolution of each pixweight file is nside=256, which is stored in the header of the file as HPXNSIDE. This resolution corresponds to a pixel area of ∼ 0.0525 deg 2 , which approximates the size of a Legacy Surveys brick.
The pixweight maps contain the quantities detailed in Table 10, which are all easily derived from the random catalogs discussed in §4.5.1 (typically from the file in the randomsall sub-directory) and the bright-and dark-time target files described in §4.1.1. One column that appears in Table 10 that we have not previously described is STARDENS, which contains a measure of the stellar density in a given HEALPixel. The STARDENS quantity is derived from a count of sources in Gaia DR2 that have a Gaia G-band magnitude in the range 12 ≤ G < 17 and that are point-like. Point-like, here, is defined using Gaia quantities via: where AEN is the Gaia quantity ASTROMETRIC EXCESS NOISE and G is the Gaia G-band magnitude (i.e. PHOT G MEAN MAG).

Quality Assurance Web Pages
The "pixweight" files described in §4.5.2 can be used to derive useful plots of sky coverage for targets. In particular, the FRACAREA quantity allows target densities to be correctly weighted by the actual areal coverage of the Legacy Surveys imaging. In addition, as the "pixweight" files collate information about observational properties of the imaging surveys, such as depth and local stellar density, they can be used to determine how target densities correlate with systematic effects (see, e.g. Chaussidon et al. 2022b).
The desitarget.QA module can be used to combine the "pixweight" files from §4.5.2 with the target files detailed in §4.1.1 to create web pages of diagnostic plots for DESI targeting. The gateway to these web pages also includes a version of the target density matrices provided in Tables 5  and 6, which are trivial to derive from the "pixweight" files.
These QA web pages have been made publicly available by the DESI collaboration for SV3 55 and the Main Survey 56 . At each url, there are individual sub-directories for bright-time and dark-time targets. Clicking on a sub-directory launches a page that includes target density matrices, plots of observational systematics, and a list of targeting bit-names (see, e.g., Table 3). Clicking on any bit-name produces a page with a number of diagnostic plots for that target class, including sky maps, color-color plots and trends in target density with ob-53 e.g., https://data.desi.lbl.gov/public/ets/target/catalogs/dr9/0. 57.0/pixweight/sv3/resolve/bright/sv3pixweight-1-bright.fits 54 e.g., https://data.desi.lbl.gov/public/ets/target/catalogs/dr9/1.

Secondary Target Classes
In addition to the dark-time targets, bright-time targets, backup targets, calibration targets, and random catalogs discussed elsewhere in this section, the DESI survey incorporates additional targets to pursue science efforts beyond the primary DESI goals. These targets, which we refer to as "secondary" targets, are either conducted as dedicated campaigns or as "filler" programs to mop up spare fibers where no primary DESI targets are available. The dedicated campaigns include tertiary programs (c.f. §3.2.3) and some large Targets of Opportunity campaigns (see §3.2.2 and, e.g., Palmese et al. 2021).

An Overview of Secondary Targets
In §2 we discussed how secondary targets can be retrieved from the DESI target files ( §4.1.1) by applying the scnd mask bit-names to bit-values in columns that resemble SCND TARGET. In §3.2 we detailed the specific, unique TARGETID that desitarget assigns to secondary targets. But, a full description of all of the scientific goals that underlie the DESI secondary target programs is beyond the scope of this paper and will be reserved for forthcoming DESI Data Release papers (e.g., DESI Collaboration et al. 2023, in preparation). We will, however, provide an overview of the process for selecting secondary targets here.
Every secondary program provides lists of targets which are preserved for posterity in a specific directory 57 . This "secondary directory" contains sub-directories for SV1, SV3, the Main Survey and some bespoke programs (sv1, sv3, main, bespoke; no secondary targets were assigned during SV2). Secondary targets added after the Main Survey may also be present in additional directories named main2, main3, etc. Each of these sub-directories includes; a file of notes about each secondary target class; a docs directory of text files or Jupyter notebooks documenting a particular secondary program; an indata directory of the targets supplied by a secondary program to be processed by desitarget; and an outdata directory containing files for bright-time (bright) and dark-time (dark) secondary targets that include the TARGETID, DESI TARGET and SCND TARGET assigned by desitarget (again see §2 and §3.2). The outdata directory contains one or more sub-directories, which correspond to the different versions of the desitarget pipeline that were run to produce secondary targets. Each secondary targeting file is named $bit-name.fits, $bit-name.txt or $bit-name.ipynb where $bit-name is the specific bit-name assigned to a secondary program in the scnd mask (see §2).
Files of targets provided by a secondary program were required to include the columns RA, DEC, PMRA, PMDEC, REF EPOCH, and OVERRIDE. The first five of these columns have the same meaning as for the Legacy Surveys sweep catalogs 58 . The OVERRIDE column, which was required to be set to True or False for each secondary target for each program, is used by desitarget to determine whether a secondary target should be merged with a primary target. When a secondary target is merged with a primary target by desitarget (corresponding to OVERRIDE==False), it inherits all of the properties of that primary target (such as the target's coordinates, observational priority, whether it will be observed in bright-time or dark-time, the primary TARGETID, etc.). If, on the other hand, OVERRIDE is set to True for a target, then the target is free to be observed as defined by the secondary program but a new TARGETID is generated for the secondary target (see §3.2). Secondary and primary targets are merged by performing a coordinate match with a 1 separation 59 .
One benefit to a secondary program of specifying OVERRIDE==False for a secondary target that matches a primary target is that such targets are easier to track, because the same TARGETID will be assigned for the secondary and primary target throughout the DESI program. This choice also guarantees standard processing for a secondary target (such as being automatically coadded by the spectroscopic pipeline in the same manner as for primary targets). But, a major drawback of providing targets with OVERRIDE==False is that the target exactly resembles any matching DESI primary target, meaning that bespoke observational strategies-such as observing a target twenty times, or observing a match to a bright-time primary target in dark-time-cannot be adopted.
Secondary targets that specified OVERRIDE==False are present in the standard dark-time and bright-time files detailed in §4.1.1. Whether a target is both a secondary and a 58 https://www.legacysurvey.org/dr9/files/ #sweep-catalogs-region-sweep. 59 This separation is recorded in output desitarget secondary files as SEP.
primary target can be determined by checking if the SCND ANY bit from the desi mask is set in the DESI TARGET column (see §2). Secondary targets that specified OVERRIDE==True 60 are written to their own monolithic files. These files are in the same root directory as detailed in §4.1.1 for primary targets, except that instead of being stored in the resolve directory they are in the secondary directory. Bright-time standalone secondary targets are compiled in the secondary/bright/targets-bright-secondary.fits file and dark-time standalone secondary targets are in the secondary/dark/targets-dark-secondary.fits file.
Secondary targets that have OVERRIDE set to False aren't necessarily as carefully vetted as primary targets. So, the desitarget code takes several precautions to ensure that DESI fibers aren't placed on very-bright OVERRIDE targets that could contaminate the spectra of primary targets. First, any OVERRIDE targets that lie inside of the bright star mask discussed in §4.4.4 are removed completely from the output files of secondary targets. Second, when secondary targets are matched to primary targets (see above), they are also matched to the Legacy Surveys sweep catalogs 61 . During this match, information from Gaia and the Legacy Surveys is added to the secondary targeting file, including flux and magnitude quantities (FLUX G, FLUX R, FLUX Z, GAIA PHOT G MEAN MAG, GAIA PHOT BP MEAN MAG, GAIA PHOT RP MEAN MAG). If an OVERRIDE target is brighter than 16th magnitude in any of these Gaia or Legacy Surveys bands, it is removed completely from all of the output files of secondary targets.
The introduction of secondary programs and Targets of Opportunity somewhat complicate the provenance of a given target-particularly as secondary programs were allowed to be merged with primary programs if OVERRIDE was set to False. So, it is useful to provide a simple recipe for applying the information in §2 and §3 to determine whether a target is part of the primary DESI campaign or is more exotic. One possible recipe is: • Check the DESI TARGET column for a target, or the equivalent SVX DESI TARGET column (see §2).
• If DESI TARGET only has the bit SCND ANY set (i.e. if it is equal to 2 62 ), then the target is either a secondary or tertiary target, or a ToO.
• Use the decode targetid() utility (see §3.3) to determine release for the target.
-If release < 1000 then the target is a general secondary target (see Eqn.

How to Run the desitarget Pipeline
Researchers may wish to fully recreate a suite of desitarget output files in order to conduct large-scalestructure studies in the context of DESI or to inform target selection for future sky surveys. To help facilitate such endeavors, we have provided a tutorial on GitHub, in the form of a Jupyter Notebook, that includes a detailed overview of how each of the data products outlined in this section were produced for the DESI Main Survey using the desitarget pipeline 62 .

DISCUSSION: IMPORTANT KNOWN ISSUES
As with any evolving software, desitarget underwent several bug-fixes during catalog-creation. In this section, we try to detail some of the most prominent issues and discrepancies that users of the DESI targeting files might encounter.

Target Reproducibility
Perhaps the most important known issue is that output from the desitarget code was not wholly reproducible throughout the Main Survey. This was due to the fact that although primary targets typically supersede secondary targets (see §4.6) the desitarget code was written to allow Milky Way Survey targets to bump each other, regardless of whether they were primary or secondary. Unfortunately, because some MWS targets have similar colors to primary targets-for instance, white dwarfs resemble some QSOsand because MWS white dwarf targets had a relatively high observational priority, the desitarget pipeline fostered occasional glitches where an MWS target could bump a primary target intended for large-scale structure analyses. Notably, in situations where multiple MWS targets matched a primary target during primary-secondary merging ( §4.6), which MWS target was chosen as the match was not ordered. So, on repeated execution of the desitarget code a different MWS target could end up being merged with a particular primary target. The upshot of this bug was that, prior to version 1.1.1 of desitarget, a small subset of bright-time targets, and very occasional dark-time targets, were selected differently each time desitarget was run.
This MWS-prioritizing issue was noticed because a new, high-density, target class (called MWS FAINT) was designed to be introduced for the first iteration of Main Survey targets, which were processed with version 1.0.0 of desitarget. Due to an oversight, these MWS FAINT targets were not included in the 1.0.0 target catalogs. When this oversight was corrected, and the target catalogs were updated, it became clear that a slightly different subset of targets had been selected, even when the MWS FAINT targets were redacted. Any reproducibility bugs were subsequently fixed and new targets were processed with the MWS FAINT selection once more omittedresulting in the version 1.1.1 targets discussed throughout this paper.
While this bug-fix was being addressed, 157 Main Survey tiles were observed with version 1.0.0 targets before updating to version 1.1.1 of desitarget and producing the brighttime and dark-time targets that will be used throughout the remainder of the DESI survey. Fortunately, the scope of the differences between which 1.0.0 targets were scheduled to be observed and which 1.1.1 targets would have been scheduled to be observed is minor. Across the 157 initial tiles, a total of 270 bright-time targets differed in a manner that could have produced discrepancies in fiber placement in the DESI focal plane 63 . Only four dark-time targets differed in such a way. Given that there were ∼785k fibers that could have been assigned fibers across 157 tiles, any reproducibility issues moving from version 1.0.0 to 1.1.1 targets near the start of the DESI Main Survey should have a negligible effect on large-scale-structure analyses.

SUBPRIORITY Reproducibility
Assigning fibers to targets during early DESI Main Survey observations revealed an additional issue that could affect the overall reproducibility of the DESI survey. As noted in Table 4, desitarget adds a SUBPRIORITY column to target files that is used to break ties in the event that the DESI 63 Note that the crucial point is not that 270 different targets were observed, merely that a maximum of 270 different targets could have been observed, potentially impacting the survey selection function for large-scale structure studies.
fiber-assignment code has to choose between two targets that are otherwise equivalent in observational priority. A similar SUBPRIORITY column is added by desitarget to the pixelbased and supplemental sky locations discussed in §4.4. As of version 1.0.0 of the desitarget pipeline, SUBPRIORITY values were added as part of the function that writes files to disk. This meant that if an external routine read a target (or sky) file produced by desitarget and then wrote it back out using the desitarget writing utilities then each SUBPRIORITY would be overwritten with a new value.
Rewriting SUBPRIORITY using the approach of version 1.0.0 of the desitarget pipeline was not a bug, per se, but it proved problematic downstream of desitarget. In particular, the software that assigns fibers to DESI targets (A. Raichoor et al. 2023, in preparation) uses the desitarget writing routines to produce its own output data files. To guard against accidentally overwriting SUBPRIORITY values throughout the Main Survey, the desitarget pipeline was updated to only overwrite zero-valued SUBPRIORITY entriesmeaning that no values are accidentally overwritten when the DESI fiber assignment pipeline (or any other software) uses the desitarget writing functions. Although this issue with SUBPRIORITY was fixed before the Main Survey proceeded with version 1.1.1 targets, differences would persist in how fibers were assigned on the 157 Main Survey tiles that used targets compiled with version 1.0.0 of the desitarget pipeline. To ameliorate any discrepancies, files were constructed that contained the mapping between SUBPRIORITY and TARGETID for the SUBPRIORITY values that were initially assigned to version 1.0.0 Main Survey targets 64 . Versions of the desitarget pipeline subsequent to 1.1.0 incorporate a command-line option that can use these mappings to enforce the values of SUBPRIORITY used on the 157 Main Survey tiles that proceeded with version 1.0.0 targets 65 .

Targets with RELEASE of 9010 in SV1
Early Survey Validation (i.e. SV1) took input information from the DR9 Legacy Surveys sweep catalogs before they were patched due to a data processing issue 66 that altered the imaging properties of some sources. The desitarget pipeline switched to using the "patched" DR9 sweeps as of version 0.49.0 of the desitarget code. Targets that might have different source properties because of this patching bug can be identified because they will have a RELEASE of 9010 in files produced by versions of desitarget prior to 0.49.0 but a RELEASE of 9012 in later target files. Such targets will have similar coordinates but a different TARGETID, both because the RELEASE number changed for all such sources in the patched sweep catalogs and because the OBJID changed for some such sources (see, e.g., Figure 1).

SUMMARY
In this paper, we have provided a detailed overview of the DESI target selection pipeline. The exact algorithms used to classify specific subsets of DESI bright-time and dark-time targets are detailed in other papers (Raichoor et al. 2022;Zhou et al. 2022;Chaussidon et al. 2022a;Cooper et al. 2022;Hahn et al. 2022) but aspects of how these targeting algorithms are implemented are crucial to understanding how to work with DESI data. This paper also details the approaches used to classify targets to help calibrate DESI spectroscopy, such as GFA targets and blank sky locations.
The DESI target selection pipeline, which is known as desitarget, is publicly available on GitHub. As with any software product, some documentation of the desitarget code and the resulting products will be described online, and in other papers related to the DESI end-to-end pipeline (E. Schlafly et al. 2023, in preparation;A. Raichoor et al. 2023, in preparation;Guy et al. 2022, S. Bailey et al. 2023. So, here, we have tried to focus on an overview of the most important concepts related to the technical aspects of DESI target selection. The desitarget pipeline sets bit-values in output data files in a number of different columns, which indicate whether a particular target meets specific selection criteria. The names of these columns resemble DESI TARGET (for darktime DESI targets), BGS TARGET (for bright-time galaxies), MWS TARGET (for Milky Way targets) and SCND TARGET (for targets beyond the primary DESI campaigns). Values in these columns can be interpreted using bitmasks with names like desi mask, bgs mask, mws mask and scnd mask.
Another important output of the desitarget pipeline is a unique TARGETID that allows each target to be tracked throughout the DESI survey. This TARGETID encodes additional, useful information about each DESI target, such as whether a target is selected from Legacy Surveys imaging or from Gaia, whether a target is a sky location or part of a random catalog, and whether a target is part of a secondary program or is a target-of-opportunity.
It is important to note that different versions of the desitarget pipeline were used for different phases of the DESI survey, such as the Survey Validation phase-including the DESI One-Percent Survey-and the Main Survey phase. The evolving nature of desitarget spawned multiple complexities in target selection that we have attempted to document in this paper. Examples of such technical details include (but are not limited to): • That sometimes Gaia EDR3 data, instead of Gaia DR2 data, is incorporated by desitarget when processing certain target selection classes.
• That the URAT survey is used to help select GFA targets for sources that are missing astrometric information in Gaia DR2.
• That a bright-star-mask based on Tycho and Gaia is applied to all sky locations and secondary targets, and that secondary targets are further removed from any DESI program if they are too bright in Gaia or Legacy Surveys imaging.
• That targets processed using version 1.0.0 of the desitarget pipeline were observed for the earliest part of the DESI Main Survey but that, for reproducibility reasons, DESI rapidly updated to observing targets processed with version 1.1.1 of the desitarget pipeline.
The desitarget codebase is now mostly stable as regards producing the static files used for DESI target selection. Further modifications to desitarget might be expected in modules related to producing random catalogs for large-scalestructure analyses, and to converting static files to the dynamic files used to monitor the state of a DESI target as it is observed (see also E. Schlafly et al. 2023, in preparation). Any updates will be documented in later works as the DESI survey progresses.