LSST will begin its Construction phase in an epoch where software in general, and astronomical software in particular, is evolving towards increasingly distributed, cooperative and open access approaches. At the same time, LSST will generate an extremely large coherent dataset with unique characteristics and much of the community-shared development is in its infancy at the time of this design. Therefore, the design presented aims to strike a balance between facilitating maximal compatibility with externally-developed resources and ensuring control over a sufficient portion of the system, so that the project can ensure that a useable interface to the data is available to the community when the telescope and camera have been commissioned, without relying on development it does not control.
 
With that in mind, a design philosophy has been established. It includes the following:
 

·	Utilize Program-friendly interfaces as a communications layer between LSST-specific software running at the DAC and end-user applications. Include application programming interfaces (APIs) for any tool or service developed.
·	Utilize common protocols (e.g., VO protocols) in the API layer to facilitate making the data available through any compatible service. Develop new protocols only if needed, and whenever possible, strive to do so within the context of generalized utility and community discussion.
·	Use a development model in which service components can be located either with user interface components in a distributed way or co-located with the data at a DAC, so that an optimum balance can be struck between utilizing local resources and co-locating tasks that access a large fraction of the LSST data with the data.
·	Facilitate access through existing tools; use COTS where targeted development is not needed (e.g., Helpdesk software).
·	Concentrate development effort where most needed. We believe this to include:
o	The APIs;
o	A SUI infrastructure which sits between the DM-developed middleware and the APIs that enable access to the LSST data;
o	Any LSST-unique functionality;
o	A “front door” data search and retrieval interface that provides the Tier1 functionality to the community;
o	An Alert subscription and notification service.

 
The conceptual design comprises a layered architecture, which is responsive to the requirements and to the project’s philosophy of working with shareable and extensible architectures and tools. The requirements and design are both informed by the Example Use Cases documented in Appendix A.
 
To facilitate concentrating the effort where it is most needed, we will carry out a comparison of the required functionality with existing tools that might provide either a model, a base for customization or plug-and-play functionality, given suitable detailed design of the underlying layers of the architecture. The beginnings of this effort appear in Appendix B. Although not complete as of this version, it is also certainly the case that this type of technology evaluation will need to be ongoing throughout the design and development of the SUI/T.

 
Classic science information systems design has involved building up from data access through higher-level data processing constructs and wrapped by graphical user interface (GUI) components to provide a uniform and integrated system for the end user. However, data volumes are increasing geometrically, processing is becoming ever more complex and distributed, and more and more tools are being developed specific to a narrow discipline. It is beyond the capability of any one organization to capture all the functionality desired by a diverse astronomical community in a single monolithic and opaque construct.
 
There is an enormous wealth of skill and existing software tools in the community that can be brought to bear on LSST data handling and analysis problems if the right framework is in place. The LSST SUI must therefore be largely about interconnectivity and facilitating development of solutions, rather than building a single top-down system.

 
These components handle SUI-related requests that impact resources at the DACs (analogs may also exist on external servers hosting computational engines external to the DACs). Some examples of existing systems which would be considered during detailed design in this area include Condor, developed for distributed use of under-utilized compute nodes; the ROME queue management, a job framework used for the Montage mosaic service, which has the ability to keep track of real-time applications messages and to reorder the execution queue; bgTools, a simple framework allowing "foreground" browser- initiated jobs from timing out and existing Cloud and Grid tools.
 

 
These components provide the computation or search functions that operate directly on the LSST data through the middleware for activities where the job is too big to consider transporting the data to an external service. Examples might include, e.g., producing a color-color density map for all galaxies in the survey, cross-correlation with other large datasets, producing a reduced mosaic of the focal plane for a given epoch of observation. During detailed design, a careful examination of each task will need to be made, and those common services which need to be co-located with the data identified and a corresponding engine designed.

 
The SUI/T will run on dedicated web/application servers, which provide the web services framework supporting data access queries and data product retrieval, as well as computational capability, at a DAC. These servers will control and interact with the User Workspace disk storage via cluster nodes and file servers, and this overall infrastructure is networked to the database nodes. The SUI/T interface layer will handle user queries and communicate/translate these to the database via the database middleware. Files produced as query results will be returned to the User Workspace cluster for immediate access and storage available to the users. The files will be stored in workspace directories for some set of period of time until being automatically purged. The compute servers will provide capacity for user tools, as well as engines for data visualization.

 
These would be LSST-specific services necessary to ensure compatibility with existing tools and services that do not need to be co-resident with the data. Most of these would be developed in conjunction with tools development.
 

 
This comprises the software needed to "provide automated and human assistance in working with the DMS and data products" per the WBS. No custom development is anticipated here, the bulk of the task is to choose and configure a COTS Helpdesk system (e.g., Kayako). The remainder of the task falls into the areas of providing and cataloging documentation and website design.
 

 
The User Workspace Interface provides access to data housed remotely, notably at a DAC, in conjunction with time awarded to a researcher on the heavy compute resources at, e.g., NCSA. Conceptually this interface allows the user to interact with the data as if it were on a local file system, and supports uploading, downloading, read/write protection, etc.
 
It is anticipated that the User Workspace will either be VOSpace or will be modeled closely after VOSpace.
 

 
This is the basic interface used to subscribe to alerts and to manage the subscription to alerts. It includes functionality to subscribe and unsubscribe, to design custom filters and to receive notification through specified means.
 
The development related to raising alerts and publishing them rests with the DM Pipeline development, and the presumptive mechanism is VOAlert. Some event brokers already exist and it has been argued that LSST need not develop its own brokerage service. At this point in time, this item represents a placeholder; if externally developed broker services meet the needs of the LSST community, it may not be necessary to build a tool. However, alert handling is key to many of the science goals.

 
This is an LSST-developed User Interface that meets the bulk of the Tier 1 requirements in the archive query and represents the fundamental "Science User Interface" to the LSST data. This capability is needed early and must be robust and user friendly. Because some degree of data visualization is a necessary part of working with the archive, both for catalog type queries and for image queries, the "Front door" incorporates both query and data visualization functionality in a way that appears seamless to the user.
 
The basic interface would initially support by-position CCD or sub-CCD level image browsing and retrieval and searches of the source and object catalogs (including forced sources, etc.), applying selection criteria against a first-tier subset of the catalog fields and image metadata identified as being of primary importance. This would include searches by target coordinates, either individually or by uploading a list, and other comparable “basic” criteria. This level of functionality is needed at the start of Commissioning. The expectation is that this will be extended to include a second-tier catalog field data and image metadata, an SQL-like expert query function, and hierarchical multi-scale image view and retrieve. The latter functionality could be delivered after the start of Commissioning; i.e., some functionality would be delivered during the Commissioning phase and some during the first year to two years of Operations.
 
IPAC has a heritage in developing and deploying successful systems of this type. The Spitzer, WISE and Planck archives were developed using a powerful, configurable system for building web-based user interfaces; it is configured through an XML file so that very little code must be written to implement a new archive and is designed to interface with pre-existing services, such as VAO services. It focuses on presentation, user interaction, and visualization. Although it is unlikely that this system, Firefly or the technologies it relies upon, will remain static and available during the LSST Construction phase, it provides a good model for the type of functionality the "Front Door" interface would provide.
 
In this paradigm searches are performed using “drop-in” components that connect external data services to the rest of the system. Data results can be visualized in multiple ways using interactive tables and true FITS image visualization. External data visualization and analysis services can also be supported in a "drop-in fashion," which allow the interface to leverage the resources available as data co-resident services, to break down large-volume problems to a browser-manageable size.
 
Technologies and approaches that we might consider during detailed design of a "Front Door" user interface include Canvas, for 2D graphics, and WebGL, which takes significant advantage of GPUs, for 3D graphics in the browser.
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Appendix A:

Representative Use Cases

 
This Appendix contains representative science use cases from the LSST Science Drivers as examples of paths through the software set. They are not in any way intended to be complete but rather illustrative.

A.	Mapping the Milky Way Use Case

B.	Exploring The Transient Optical Sky Use Case

 

C.	Taking an Inventory of the Solar System Use Case

 

 
 

D.	Constraining Dark Energy and Dark Matter Use Case

 

Appendix B:

Existing Tools & Technology Analysis