LSP Verification/Validation Requirements Analysis

DMS-LSP-REQ-0017: Tabular Data Download File Formats

The LSP shall allow tabular search results, including but not limited to data from the source and object tables and the image metadata tables, to be downloaded or saved to the workspace in at least the following formats: FITS table, VOTable, and ASCII delimiter- separated table (e.g., CSV).

A final set of formats needs to be discussed and approved by the Project. This is primarily a requirement on the API aspect and the DAX services.

For example, the Gaia Archive allows download in FITS, VOTable, CSV, and JSON formats.

MWV: Specifically something like eCSV would be an appropriate format to include units and other metadata.

• clarify
• design
• done

DMS-LSP-REQ-0018: Image Data Download File Format

The LSP shall allow LSST image data products to be downloaded or saved to the workspace as FITS files including the appropriate metadata.

This needs some discussion as to what other formats we may want and must be readable by future releases.

MWV: I think FITS is a reasonable minimum spec. If we go into operations only being able to provide FITS files to download images I think that's fine.

• clarify
• design
• done

The LSP shall simultaneously handle at peak usage 20 * 6 GB = 120 GB downloads.

"This requirement flows down from several requirements in the DMSR (LSE-61) which constrain both the performance of the database systems (via LDM-555) and the Science Platform." We should identify the specific DMSR requirements and associated Verification Elements related to this DMS-LSP-REQ.

MWV: I think this should specified as total bandwidth with number of simultaneous users rather than an absolute volume with simultaneous users but no time frame.

• clarify
• design
• done

DMS-LSP-REQ-0023: Use of External Identity Providers

The LSP shall permit users to authenticate to the system using external credentials, from identity providers determined to be trusted by the LSST project or its operations organization.

Discussion: This means that a user should be able to authenticate to an instance of the LSP using, for example, Github credentials, or credentials from a home institution. The policies for how LSST determines that an external user, with external credentials, has data rights and may establish an identity in LSST systems are set forth in other documents.

Does this need a more specific definition (or some examples) of trusted providers?

• clarify
• design
• done

Non-project-staff users of the LSP shall be required to agree to and abide by an Acceptable Use Policy, to be determined by the LSST project or its operations organization, as a condition of access to any Project instance of the LSP.

Confirm that this policy exists, or is in development.

MWV: Why is this phrased as "Non-project-staff users"? It comes off as implicitly meaning that Project Staff have fewer restrictions on them, which is not the right message to send without context. Project staff users using the LSP to do science should be bound by the same conditions as other users. If Project Staff have non-user roles where they would need to do things inconsistent with the Acceptable Use Policy, that's fine but can be covered by being in a non-user role when undertaking those actions.

• clarify
• design
• done

DMS-PRTL-REQ-0002: Portal Discovery of all Data Products

The Portal aspect shall provide the capability to discover and access all the Project’s released data products, including, but not limited to, the data products enumerated in the DPDD (LSE-163), the calibration database, and the Reformatted EFD, as well as all user data products to which a user has access.

The Portal’s workflows should allow a user to learn what data exist: what data releases are available, what image and catalog data they contain, the names of all databases, tables, and columns, etc. For all tabular data products the Generic Query requirements below cover the basic level of access provided.

Does this need an additional requirement enabling the data discovery described above?

• clarify
• design
• done

DMS-PRTL-REQ-0021: Positional Query: Multiple Positions/Objects

The Portal aspect shall support list-based positional queries, with the coordinates used specified by any of the means of specifying positions required elsewhere herein.

We should specifically enumerate the various means of specifying positions that must be verified.

JLC: From LDM-554: "equatorial, ecliptic or galactic coordinates" in DMS-PRTL-REQ-0020 and DMS-PRTL-REQ-0022, "astrophysical source name" (DMS-PRTL-REQ-0023), "LSST catalog entry identifiers" (DMS-PRTL-REQ-0024), "external Solar System Object identifiers" (DMS-PRTL-REQ-0025).

• clarify
• design
• done

DMS-PRTL-REQ-0023: Positional Query: Astrophysical Source Name Lookup

The Portal aspect shall support the specification of coordinates for use within all positional queries by the use of source names in common community-established astrophysical source name lookup services.

• clarify
• design
• done

DMS-PRTL-REQ-0031: Tabular Data Query Specifications

The Portal aspect shall provide a user interface to execute queries of the (DIA)Object and (DIA)Source tables, driven by the data dictionary associated with the tables.

This should be satisfied almost completely by the "Generic Query - Form-Based" requirement above, but with some additional work on the UI to produce a more friendly workflow.

Add some specifics about the columns to be included in the UI?

• clarify
• design
• done

DMS-PRTL-REQ-0043: Visualization of Ancillary Information

The Portal aspect shall include the ability to visualize selected ancillary information produced by the LSST pipeline including, but not limited to, image regions, image bit-planes, survey footprints, focal-plane footprints and PSF representations.

The intent here is to call attention to the fact there is more than just the survey images and coadds that have a “2-dimension” form that need to be visualized and presented to the user in the interface. The specific ancillary data products to visualize will be determined during construction, based in part on feedback received during PDAC operation and the use of the Portal tools by developers. It is desirable that custom visualizations be available for important and frequently used ones such as Footprints (which can readily be displayed as pixel overlays). Where dedicated Portal visualizations are not available, however, users should be able to use either LSST-provided or community libraries in the Notebook aspect to create custom visualizations.

Define the ancillary products to be included in this requirement.

• clarify
• design
• done

DMS-PRTL-REQ-0068: Display User-provided Images

The Portal aspect shall have the capability to display user-provided images in widely-used astronomical community formats, including FITS, and shall properly interpret a variety of commonly-used WCS specifications in the image headers.

We should list any additional formats besides FITS that should be supported.

MWV: FITS seems fine as a baseline with the goal of this being modular enough such that other formats could be added in the future.

• clarify
• design
• done

DMS-PRTL-REQ-0088: Geometric Figure Overlays

The Portal aspect shall enable the drawing, display, and selection of a closed 2-dimensional polygon on any two-dimensional image.

"This is a general requirement that enables the overlay of a polygon on an image or a plot. A polygon could be a circle, an ellipse, or an N-vertices polygon. The purpose of this is enable area selection on the images or plots."

Given the above statement about selection within the polygon, this requirement would seem to require more specification (or an additional requirement for polygon selection?). I see now that this is covered in DMS-PRTL-REQ-0107: Data Selection From a Plot or Image

• clarify
• design
• done

DMS-PRTL-REQ-0096: False-color Images Creation and Display

The Portal aspect shall have the capability to create and display false-color images composed from any user-selectable set of filters from multiple filter views of the same region.

• clarify
• design
• done

DMS-PRTL-REQ-0097: Statistical Measurements on Image Data

The Portal aspect shall enable the capability to perform a set of statistical measurements (e.g., mean, median, RMS, skew, kurtosis) on user-selected regions in images.

• clarify
• design
• done

DMS-PRTL-REQ-0099: Overlay LSST-Derived Orbits

The Portal aspect shall have the capability to overlay predicted positions from the orbits of solar system objects in the LSST catalog on to images.

It would also be useful to support overlay of predicted positions from user-supplied orbits in community-standard forms. The capabilities to be provided in this area will be determined during construction.

It might further be useful to be able to overlay intermediate data products such as tracks and tracklets; whether it is desirable and feasible to provide this will be determined during construction."

Lots of "TBD during construction" items here...

• clarify
• design
• done

DMS-NB-REQ-0010: Common Astronomy Package Availability

The Notebook Aspect shall provide select standard astronomy packages in the interactive environments.

Discussion: For example, Astropy and S-Extractor.

Add additional packages expected to be installed.

MWV: I don't think Source Extractor is necessary. Sure, it might be nice, but our recommendation can be to use the LSST photometry packages. NB: There are currently three different Python wrappers around Source Extractor: {{pyse}}, {{sewpy}}, and {{sep}}

astropy,

+Not-purely astro: pandas, scipy, scikit-learn, matplotlib, seaborn

JLC: Edited to say "select standard astronomy and data analysis packages", and enumerated a few in the Discussion.

• clarify
• design
• done

DMS-NB-REQ-0019: VOSpace Access

The Notebook Aspect shall be able to interact with VOSpace services available through project or external services.

Discussion: Users will be able to directly use VOSpace APIs within a Notebook. It is not yet decided whether there will be support for user-mode mounting of non-LSP VOSpace (or WebDAV) services as virtual POSIX filesystems.

• clarify
• design
• done

DMS-NB-REQ-0024: Ease of Deployment

The Notebook Aspect shall be deployable to multiple instances and contexts, both private and public.

Discussion: Such as the Commissioning Cluster and the LDF, but also collaborator clusters, subject to the underlying resources available in the specific instance. (What level of effort? 2 days/week/month; one click deployable on a common standard platform: e.g., Kubernetes.) Sort out these details?

• clarify
• design
• done

DMS-NB-REQ-0034: Visualization Linkage

The Notebook Aspect shall provide "drill down" functionality in plots: brushing and linking between plots, interactively discover metadata about particular points, drill down to imaging from measurements.

Discussion: Metadata can be visit properties for a measurement, git commits, etc. (gpdf is concerned that this is too vaguely defined to be verifiable. Should this be in a design document instead?)

• clarify
• design
• done

DMS-NB-REQ-0035: Visualization Interactivity

The Notebook Aspect shall provide interactive plots for certain visualizations: Linked axes on multiple plots, zoom, pan, data point selection

(gpdf is concerned that this is too vaguely defined to be verifiable. Should this be in a design document instead?)

• clarify
• design
• done

DMS-API-REQ-0026: Access to Reference Catalogs

The API Aspect shall provide for retrieval of all reference catalog data via TAP ADQL queries. For the purposes of this requirement a "reference catalog" is an externally sourced catalog used during data production activities.

Discussion: Is this a more general provenance requirement? Just reference catalogs? Or also, e.g., relevant calibration images? Or does it just mean that if we have reference catalogs, they’ll also be queryable? FM and GPDF: we think the latter was meant - i.e., there’s no implication that this requirement mandates linkage. We should settle this, and clarify as needed.

• clarify
• design
• done

DMS-API-REQ-0028: Access to Image Data in FITS Format

The API Aspect shall deliver image data in FITS format, and MAY deliver images in additional formats.

Clarify or remove the italicized text in the Specification?

MWV: I think the MAY text is fine. The minimum is FITS, but we should build to not assume FITS.

• clarify
• design
• done

DMS-API-REQ-0015: SQLite Output for TAP

The API Aspect TAP endpoint SHOULD support SQLite as an alternative available output format .

Discussion: The mandatory status of this requirement should be settled one way or the other as soon as possible. It is a candidate for a efficient and readily consumed format for large results with rich metadata.

• clarify
• design
• done

DMS-API-REQ-0031: Tabular Result Download to Workspace

The API Aspect shall provide a capability for users to save their query results as VOTables in their allocated VOSpace, subject to limitations of a resource quota system.

Discussion: Or any of the other supported formats?

• clarify
• design
• done

DMS-API-REQ-0032: Tabular Upload to Workspace

The API Aspect shall provide a capability for users to upload catalog data products (formatted as VOTables) residing within their allocated VOSpace, such that the catalog products after upload may be joined in queries against data release catalog products, subject to limitations of a resource quota system.

• clarify
• design
• done