Output Files

Astra Data Products

Data products that are produced by Astra can be categorized in the following ways:

• A summary of all observed targets is stored in the mwmTargets file, which includes source-level information (e.g., identifiers, cartons, astrometry, and photometry). The mwmTargets (datamodel) file lists all stellar sources observed thus far in Milky Way Mapper, regardless whether they were observed with BOSS, APOGEE, or were part of APOGEE in Data Release 17. The mwmTargets file has very little information about the spectra we have collected for those targets, just the number of spectra that we have from APOGEE and BOSS. This file is more lightweight than mwmAllStar and mwmAllVisit, discussed below.

• Summary of all observed spectra. There are two kinds of summaries here:
  • the mwmAllVisit file (datamodel) describes the visit-level spectra (nightly stacked exposures of a given source); and 
  • the mwmAllStar file (datamodel) describes at the star-level (stacked visit spectra for a given star and instrument).

For DR20, the APOGEE HDUs for the mwmAllVisit and mwmAllStar files are present but empty, because there is no new APOGEE data released in DR20. There is a column in the DR20 files called sdss_dr19_apogee_flag. If True, this indicates that there is an APOGEE spectrum in DR19 for that star, which can be retrieved via the DR19 Data Access page.

We do not coadd spectra across instruments that were observed at from both observatories (e.g., we do not co-add APOGEE spectra from LCO with APOGEE spectra from APO). We also do not coadd APOGEE DR17 data with MWM APOGEE data if the star has been observed pre-SDSS-V and SDSS-V.

• Spectrum data products. These are value-added data products constructed from reduced products from the data reduction pipelines. There are two files created for each sdss_id. These are:
  • mwmVisit (datamodel): this contains all rest-frame resampled visit spectra from all telescopes and all instruments for a given sdss_id; and
  • mwmStar (datamodel): this contains all co-added rest-frame resampled spectra from all telescopes and all instruments for a given sdss_id.

• Pipeline summary tables include results from a pipeline, but they do not include data arrays (e.g., best-fit model spectra are not included in pipeline summary tables). Summary files can be found here. There are two kinds of summary tables here, with links to their datamodels:
  • astraAllVisit<PIPELINE>: this contains all <PIPELINE> results for all visit-level spectra.
    • AstroNN
    • BOSSNet
    • corv
    • LineForest
    • MDwarfType
    • SnowWhite
  • astraAllStar<PIPELINE>: this contains all <PIPELINE> results for all stacked spectra.
    • APOGEENet
    • ASPCAP
    • AstroNN
    • AstroNNdist
    • BOSSNet
    • corv
    • LineForest
    • MdwarfType
    • Slam
    • SnowWhite

• Pipeline spectrum data products include pipeline results for a single sdss_id. For pipelines which do not produce data arrays (e.g. best-fit spectra), these do not contain any information that is not already found in the pipeline summary tables, astraAllVisit and astraAllStar. Consistent with other data products, the pipeline spectrum-level products are distinguished by whether the input spectra were visit- or star-level products:
  • astraVisit<PIPELINE>: this contains the <PIPELINE> results for visit-level spectra for a given sdss_id. Everything in this file will also exist in the corresponding pipeline summary table, except the astraVisit<PIPELINE> file will also contain the best-fitting model spectrum, the best-fit continuum, and any other pixel arrays.
    • SnowWhite
  • astraStar<PIPELINE>: this contains the <PIPELINE> results for star-level spectra for a given sdss_id.
    • ASPCAP
    • SnowWhite 

The pipeline spectrum data products all share a reasonably consistent data model and design, but might vary in detail about the fields that exist. For example, only the astraStarASPCAP file contains fields like model_flux_al_h, which is the best–fit model spectrum when we fit [Al/H], since no other pipeline produces this output.

Spectrum data product details

Astra creates mwmVisit and mwmStar spectrum data products before any pipelines are analyzed, for convenience to the collaboration and the public. These data products can then be analyzed by various pipelines within Astra.

When Astra creates a mwmStar or mwmVisit file from SDSS-IV APOGEE DR17 spectra, the data arrays (flux, inverse variance) are copied exactly from the SDSS-IV apStar file. No re-sampling or interpolation is done on the data.

mwmVisit files

The Milky Way Mapper visit (mwmVisit) files include all APOGEE and BOSS visit spectra taken from Apache Point Observatory and Las Campanas Observatory, and taken any time between SDSS-IV and SDSS-V. Here a “visit” refers to something like a “nightly visit”: a single or set of exposures taken in a night from a particular telescope.

For DR20, the APOGEE HDUs for the mwmVisit and mwmStar files are present but empty, because there is no new APOGEE data released in DR20. There is a column in the DR20 files called sdss_dr19_apogee_flag. If True, this indicates that there is an APOGEE spectrum in DR19 for that star, which can be retrieved via the DR19 Data Access page.

The mwmVisit FITS header data units are organized in the following order, which mimics the mwmStar files:

1. Source-level metadata (headers only).
2. BOSS visit spectra acquired from Apache Point Observatory
3. BOSS visit spectra acquired from Las Campanas Observatory
4. APOGEE visit spectra acquired from Apache Point Observatory
5. APOGEE visit spectra acquired from Las Campanas Observatory

The mwmVisit files are value-added products created from APOGEE apVisit files and BOSS specFull files. However, unlike the apVisit and specFull files, the mwmVisit spectra are stored in vacuum wavelengths in the stellar rest-frame. This implies that we need a reliable radial velocity to shift the spectrum to the rest-frame. If no reliable radial velocity exists, then the spectrum will still be stored in the mwmVisit file, but it will be stored in the observed frame.  

Additionally, the mwmVisit files include a stellar continuum found through the constrained linear model described in Casey et al. 2026. Here the stellar absorption, telluric transmission, and the joint continuum-instrument response are fit simultaneously. The stellar absorption and telluric transmission are each modeled by factorizing a grid of rectified theoretical spectra into two nonnegative matrices with a chosen number of basis components, meaning the model can represent all possible spectra with relatively few parameters. The resulting modeled flux (nmf_rectified_model_flux) and joint continuum-instrument response (continuum) are store in the mwmVisit file for each visit.

mwmStar files

The Milky Way Mapper star (mwmStar) files include co-added APOGEE and BOSS spectra taken from both Apache Point Observatory and Las Campanas Observatory. This file represents our best combined spectrum of a star, as observed by a given telescope and instrument combination.

The mwmStar FITS header data units are organized in the following order, which mimics the mwmVisit files:

1. Source-level metadata (headers only).
2. BOSS coadded spectrum from all Apache Point Observatory observations
3. BOSS coadded spectrum from all Las Campanas Observatory observations
4. APOGEE coadded spectrum from all Apache Point Observatory observations
5. APOGEE coadded spectrum from all Las Campanas Observatory observations

As with the mwmVisit files, mwmStar includes the modeled flux (nmf_rectified_model_flux) and joint continuum-instrument response (continuum) using the method from Casey et al. 2026.

The SDSS-V APOGEE Data Reduction Pipeline presently cannot reduce APOGEE spectra that were taken during SDSS-IV and released as part of Data Release 17. This is a result of numerous hardware and software improvements between SDSS-IV and SDSS-V (e.g., from plates to robots; installation of the Fabry Perot Interferometer), which naturally lead to different data characteristics. The SDSS-V APOGEE Data Reduction Pipeline team naturally prioritized the processing of SDSS-V data. 

If a star was observed with APOGEE in SDSS-IV and with APOGEE in SDSS-V, then this is a special case. In these situations astronomers will find the mwmVisit file includes spectra from both SDSS-IV and SDSS-V, and those spectra can be differentiated by the apred column. However, in the mwmStar file we only use the SDSS-V visits to produce a co-added spectrum: the SDSS-IV visits are not used in the co-add. This can be checked by the in_stack field in the mwmVisit file: if the star was observed with APOGEE in SDSS-IV and SDSS-V then the in_stack column will be False for all SDSS-IV observations. The reason that we do not currently co-add spectra between SDSS-IV and SDSS-V is because they were reduced differently, and we have not fully quantified potential differences in the reduced spectra. This is in line with the decision not to coadd APOGEE spectra from different telescopes. Expert users should know that these decisions will be reconsidered for Data Release 20: analyses should not hard-code in this assumption.

Keywords from the SDSS-IV APOGEE DR17 files are homogenised to the SDSS-V keywords and the Astra glossary. For example, what was called V_HELIO in DR17 will appear as V_RAD in the SDSS-V files. There are a very small number of these translations that have been done to include the SDSS-IV APOGEE DR17 spectra in Milky Way Mapper as seamlessly as possible.