robostrategy: Field and Target Assignment Optimization in the Sloan Digital Sky Survey V

TL;DR

robostrategy provides a rigorous framework for field cadence allocation and fiber assignment in SDSS-V, framing the problem as a linear-programming optimization to maximize total target value under time and cadence constraints across two telescopes. It separats planning into a field-cadence LP (with variables $w_{ijk}$, $N_{ij}$, $T_k$, etc.) and a subsequent fiber-assignment stage that predominantly uses greedy methods, with a constraint-programming option for single-design cases. The approach accommodates complex cadences, calibration requirements, bright-neighbor exclusions, and evolving target lists, delivering a concrete, actionable observing plan that adapts to weather and progress. The work demonstrates a practical, scalable methodology for optimizing large, time-domain spectroscopic surveys and highlights trade-offs and future enhancements for even more efficient survey planning.

Abstract

We present an algorithmic method for efficiently planning a long-term, large-scale multi-object spectroscopy program. The Sloan Digital Sky Survey V (SDSS-V) Focal Plane System performs multi-object spectroscopy using 500 robotic positioners to place fibers feeding optical and infrared spectrographs across a wide field. SDSS-V uses this system to observe targets throughout the year at two observatories in support of the science goals of its Milky Way Mapper and Black Hole Mapper programs. These science goals require observations of objects over time with preferred temporal spacinges (referred to as "cadences"), which can differ from object to object even in the same area of sky. robostrategy is the software we use to construct our planned observations so that they can best achieve the desired goals given the time available as a function of sky brightness and local sidereal time, and to assign fibers to targets during specific observations. We use linear programming techniques to seek optimal allocations of time under the constraints given. We present the methods and example results obtained with this software.

Figures (14)

• Figure 1: Software context for robostrategy. Cylinders indicate databases, rectangles indicate processes and software, and arrows indicate a flow of information. The fundamental catalog from which targets are drawn is in the database catalogdb. The target_selection pipeline selects specific targets and specifies desired cadences, and stores the results in targetdb. robostrategy takes these targets as inputs, and delivers a set of field locations, a set of designs to observe for each field, a desired LST distribution in which to observe the designs in each field, and a set of assignments of robots to targets in each design. The operations software system, guided by the observers, uses this information from targetdb to perform the observations and stores the as-observed set of configurations in opsdb. When designs are deemed completed, this information is included in future runs of robostrategy.
• Figure 2: Layout of the focal plane for the FPS system used by SDSS-V. The layout shown is as-built for APO; the LCO layout is nearly identical. The $X$ and $Y$ axes are position in the focal plane, with the boresight at $X=Y=0$ mm. We show each positioner as an annulus describing its patrol area. The pink annuli are the 298 positioners that carry both BOSS and APOGEE fibers. The grey annuli are the 202 positioners that carry a BOSS fiber but not an APOGEE fiber. The focal plane is divided into eight zones, as labeled, for the purposes of distributing APOGEE standard stars. The fiber reach extends to around 315.5 mm in radius at the vertices of the hexagon, or about 1.422 deg at APO and 0.953 deg at LCO, accounting for the radial distortions at the edge of the field. This reach yields a solid angle within the hexagon of 5.255 deg$^2$ at APO and 2.360 deg$^2$ at LCO.
• Figure 3: Simplified schema of the database for SDSS-V planning. Primary keys are labeled "PK" and foreign keys used to join tables are labeled "FK." Not all tables or table columns from the full schema are shown (which is why some foreign keys are not connected to tables). The blue section represents the data produced prior to robostrategy, and the green section is what robostrategy determines. A detailed description is given in Section \ref{['sec:inandout']}.
• Figure 4: Example of the definition of two different cadences, a 3-epoch cadence and a 2-epoch cadence, and the ways a target with the 2-epoch cadence could be included in a field with this 3-epoch cadence. After each epoch, the cadence defines an acceptable timing of the next epoch, as a range of days between $\delta_{\rm min}$ and $\delta_{\rm max}$; the ranges are shown as the horizontal bands for each cadence. The top row shows the 3-epoch cadence; in the third epoch, we show both the range of acceptable timing relative to the first epoch (lighter band) and relative to the second epoch, assuming it was observed at the preferred timing $\delta$. Given a target with the 2-epoch cadence as shown, its timing requirements can be satisfied either by observing it in epochs 0 and 1, or epochs 1 and 2, of the 3-epoch field. But its timing requirements cannot be guaranteed by observing it in epochs 0 and 2. For the 2-epoch cadence to "fit" into the 3-epoch cadence, the requirements on the number of observations and the sky brightness must also be satisfied. In actual operations, the roboscheduler will prefer timing close to $\delta$, but will not necessarily strictly respect $\delta_{\rm min}$ and $\delta_{\rm max}$.
• Figure 5: Example of how targets with various cadences could be observed by a single robot in a field with a specific cadence. The nomenclature of the cadences is "number of epochs by number of designs per epoch." The top four rows show cadences which can "fit" into the field epoch shown, i.e., that they have an equal or smaller number of epochs and an equal or smaller number of designs per epoch (assuming that the detailed timing of the epochs fits per Figure \ref{['fig:cadence-timing']}). Since in this case the field is a dark time field, the target with a bright time cadence has its sky brightness requirements fulfilled, whereas in a bright time field cadence, a target with a dark time cadence would not have its sky bright requirement fulfilled. The bottom row shows a target cadence that cannot be fulfilled in this field.