APS Explorer coverage and deployment

Table 29 summarises the product families and views supported by APS Explorer.

Coverage of WEAVE data products

APS Explorer is a unified Dash application that reuses the L1 preview, IFU viewer and MOS viewer as libraries and provides one application shell, callback layer, session model and dataset loader. An in-browser loading sidebar accepts L1 or L2 paths, processing settings and a raw/unmodified display choice; a server-side path browser avoids transferring a large product merely to select it. A shared Aladin Lite panel places fibres, spaxels and true footprints on a DSS background and can overlay the contributing exposures of stacked or cube products. Its supported input families are:

The detector uses minimal-I/O FITS schema inspection, independent of filename conventions. This is especially important for stacks, superstacks and renamed products: the viewer determines the data family from extensions and tables, then swaps the relevant view components while preserving shared map, selection and export behavior.

For L2 products, users can add a grid of independently configured scientific maps below the master sky and spectrum view. Each panel selects a result quantity and its own range, stretch and colour map. Clicking a point in any panel updates the selected target or bin throughout the application, including the master Aladin view, spectrum, fit tabs and other map markers. The observing block (OB) 11113 example in Fig.Figure 10 of the paper uses this facility to compare stellar velocity, velocity dispersion and the per-bin
$\lambda$

diagnostic. The latter is stored as LAMBDA_R and is calculated separately for each spatial bin. With a common velocity and dispersion within a bin, the implementation reduces to
$|V_i|/\sqrt{V_i^2+{\sigma }_i^2}$

, where
$V_i$

is relative to the median fitted bin velocity. It is not an aperture-integrated galaxy
${\lambda }_R$

. The same per-bin values are available in sortable tables and can be exported as CSV.

Standalone and server-side deployment

APS Explorer is designed to serve both an individual installation and a centrally operated server deployment. Its interfaces are summarised in Table 30. In standalone mode the analyst launches the Dash application with PyAPS and selects products accessible to that installation. The server-side multi-user configuration runs the same application behind a WSGI server, with authenticated session handoff, request-local dataset state, idle-session memory cleanup and masking of server filesystem paths in client-visible messages. Its configured WEAVE Operational Repository link is https://weave.ast.cam.ac.uk/WOR/, allowing a user to return to the operational archive after inspecting a product. This server/cloud deployment concept is intended to support public access without maintaining a second scientific viewer codebase: both forms reuse the same loaders, schema routing and figures.

The server form is portable across institutional, HPC-adjacent or cloud hosts provided that the process has authorised read access to the relevant L1/L2, CAL and CAT trees and a writable configuration/cache location where required. Product selection and loading occur on the server, so users do not upload the large FITS products through the browser. Deployment-wide calibration and catalogue roots can be supplied without exposing their paths in the locked load form. A URL prefix permits several applications to share one reverse proxy host, while /healthz remains available for container liveness checks.

The authenticated handoff uses a short-lived signed token issued by the trusted upstream service. It records the user, applicable survey/programme codes and one dataset identity; after verification, the browser session is restricted to that dataset. Load parameters may be changed, but selecting a different product requires a new handoff. L1 survey codes provide an additional file-level check when available. The token authorises only the selected dataset and its permitted load parameters.

Multi-user state is held in process-local session bundles. Request-local proxies preserve the existing viewer-library interfaces while isolating each browser’s dataset, selection, display state and log. Genuine client inactivity triggers prompt eviction, with a longer passive lifetime as a backstop. This avoids serialising multi-gigabyte APSOB and figure-cache state on every callback, but it also means the current WSGI configuration must use one process with threaded concurrency. Multi-process or multi-host scaling requires a sticky-session or shared-state design. The deployment record identifies the image, authentication boundary, data-access policy and operational monitoring configuration.

Interactive handling of large products

The Explorer contains several independent scaling mechanisms. L2 type detection reads headers without loading all arrays. Three-dimensional cubes are built lazily only when the user switches to 3-D. Once built, wavelength range scrolling is client-side, and the browser can reuse the geometry without a server round trip. FWHM figures are cached per loaded dataset. Large target tables are paginated in the browser and exported in their current filtered or sorted state. The 3-D view applies item and wavelength caps with even subsampling and never silently truncates one region. Session idle cleanup releases server-side memory, and multi-session/authentication modes prevent users from sharing one mutable dataset state.

The three-dimensional view is a wavelength-flux-spatial representation of the loaded cube, built only on demand. Wavelength limits and binning are adjustable, while bounded subsampling prevents the browser from receiving an uncontrolled geometry. Every tabular view can be exported as CSV. Live logs make long loads observable, and the processing-history view connects a selected L2 patch or bin to the preparation decisions that produced it.

These controls address FITS I/O, cube construction, server-side recomputation, browser geometry, table rendering and persistent session memory separately.

Operational and scientific advantages

The main advantage is coverage continuity. A user can inspect a calibrated L1 spectrum, its LSF and header, then select the corresponding target or bin in the L2 product and inspect Redrock ranks, stellar fits, galaxy fits, emission lines or line strengths without learning a separate viewer for each product family. The spatial map links coordinates to spectra, the processing-history tab exposes IFU preparation diagnostics, and the live log makes long APSOB/LSF loads observable instead of appearing frozen.

The shared application calls the production loaders and reuses the existing figure builders, keeping the L1 and L2 interpretations aligned with production code.