wiki:ConceptDesignReview
Last modified 10 years ago Last modified on 12/19/2007 02:02:07 PM

DM Concept Design Review Work Plan

from: LSST Table of Contents.

INFORMATION FROM DON SWEENEY Per NSF, confirmed September 17 - 20 in Tucson. Room at Vine Buidling, UA Foundation. Board room layout, not auditorium, good electronic/video resources. Will have dry runs 8/22 in Seattle and in Tucson later, need to have Review Package ready 1 -2 weeks before review, negotiate with Chairman. Review will be 4 days in duration, 1.5 days plenary presentations, 1 day breakouts, 1.5 day committee report. We will schedule plenary sesssions ourselves: 25% on PM, Sys Eng, Science, EPO; 25% each on T&S, Camera, DM. Each subsystem should assume 2.5 hours, spend .5 hours on management/budget, rest on technical. Keep to 3 speakers or less per subsystem, up to 6 or so for breakouts. Breakout groups will cover separate review areas. Chairman of the review committee will decide overall format. LSST has suggested 8 – 10 reviewers, cannot be current LSST affiliated, red team members ok. Using SysML for requirements traceability, FPRD, OCDD. Technical design will be same level of detail as MREFC plus backup material. Design is evolving and we want to show evolution since D&D is still going. The overall messages/themes of the CoDR are:

  • Connection/flowdown of science requirements to reference design
  • Presentation of reference design
  • Presentation of feasible execution plan (including prototypes/data challenges)

PMO will telecon weekly on Tuesdays at 1:30pm PT to work on CoDR from now until CoDR.

We should consider partial DC2 demonstration for CoDR.

The NSF sent a draft CoDR Charge letter, which include the following DM-related instructions:

  • Cyberinfrastructure requirements. The Review Panel is asked to review and assess:
    • Proposed architecture for the LSST observing facility cyberinfrastructure and data centers, including network connectivity, network control facilities, and network science user requirements.
    • Processing scale and storage requirement.
    • Data products delivery including possible to the planned Virtual Astronomical Observatory
    • General and special purpose (e.g. moving object) pipelines
    • Network security
    • Database design and management
    • Data policy, and
    • Plans for developing the required software.

The charge also asked for the following DM-related breakouts:

  • Data Acquisition and Pipeline Processing
  • Data Management and Data Product Delivery

Schedule/Status?:

  • Review MREFC proposal for baseline 3/9 COMPLETED
  • Create work plan 3/15/07 90% COMPLETED, missing Image Processing, Detection, Association Pipelines, Long-Haul Networks, Data Access Center sections
  • Refine work plan, request feedback/refinement from contributors accordingly 6/30 IN PROGRESS
  • Develop initial diagrams based on proposal, UML model 7/22
  • Collect initial 1/2 page powerpoint info from contributors 7/25
  • Deliver rough draft by 7/31
  • DM-only dry runs/mini-reviews and updates 8/1 - 8/15
  • LSST management and inter-subsystem dry runs and updates 8/22 in Seattle and 8/31? in Tucson

Notes:

  • Simplicity and clarity will probably necessitate reworking of some model diagrams to be more intuitive to the non-UML cognisant.
  • Try to restrict differences from MREFC as refinements that carry more detail
  • Highlight how data challenges are shaping the evolution of the design.

Additional Themes:

  • Technical Themes
    • The LSST SRD requirements drive challenges
      • Astrometric and photometric algorithmic precision
      • Computing throughput and reliability
      • Storage capacity and input/out rates
      • Long-haul network bandwidth from Chile to U.S.
    • The DMS is technically feasible
      • Reference design with current (2006 - 09) technology
      • Validated with scaled performance tests (Data Challenges)
      • Design for evolution to leverage technology advances (2010 - 24)
    • LSST DM drives the synergy of astronomy, physics, and computer science
      • Advanced, large-scale database techniques
      • Supercomputing and grid technologies
      • Advanced software engineering techniques
  • Management Themes
    • The DMS is financially feasible
      • Estimate is within the allocated construction/operations budget including contingency
      • Non-labor estimates based on historical and industry-projected technology price/performance trends, just-in-time acquisition
      • Labor estimates based on multiple, formal estimation methods
    • The DMS is deliverable
      • Schedule is within the planned construction and commissioning window with reasonable free slack
      • Executable with available, experienced resources
      • Managed with an integrated project planning and control system

Section Plans:

Functional Requirements Overview – Tim Axelrod

This can be taken over from the MREFC with minor additions and updates.

Sizing and Performance Requirements and Requirements Flowdown – Jeff Kantor

The requirements flowdown will be a reformatting of the EA matrix of SysML requirements to DM requirements and use cases and domain model objects. The sizing and performance section will amplify on Table 4-8 and the accompanying text in the proposal, with minor updates. Backup material will be the latest versions of the sizing model.

Architecture/Layers – Jeff Kantor

This will be extracted from the Layered Architecture section of the proposal. It will amplify on figure 4-62 and the accompanying text.

Application Layer Overview– Tim Axelrod

A lot has been done in this area since the MREFC was prepared. The MREFC text will need substantial additions and updates.

LsstData (Astronomy) Classes/Application? Framework – Tim Axelrod

The framework was not really discussed in the MREFC due to space limitations. A document generated by EA from the class descriptions will form the skeleton of this part.

Data Products – Tim Axelrod, Kem Cook

The MREFC text is a good start, but needs to be expanded. The text for this is largely on hand from earlier MREFC drafts before they were shrunk to fit the size requirements.

Database Schema - Jacek Becla

  • Material to use for the schema section is schema document generated by EA (rtf). Change history of the PrecursorSchema package should serve as a good summary of all schema-related changes done since writing MREFC. Highlight:
    • Main catalogs
    • Provenance
    • Image metadata
    • Calibration
    • Auxiliary telescope/ir camera
    • Indexes, foreign keys
    • Sources with low signal-to-noise stored together in one row
    • Extensions to Object table (eg Object_photoz)
    • Classification of variability in Object table (25 scalegrams x 6 colors)
    • Logistics: schema in EA, UML diagrams, official validations using mysql and sql server
    • Size related issues: comparing to MREFC: added x tables, y columns, impact on db size...

Pipelines Overview - Tim Axelrod

The MREFC text will do fine as the overview.

Image Processing and Detection - Andy Becker/Nicole? Silvestri/Robert? Lupton

Association – Ani Thakar/Serge? Monkewitz

Moving Object - Francesco Pierfederici

This section will consist of documents extracted from the Pan-STARRS MOPS CDR.

Deep Detection – David Wittman/Tim? Axelrod

Will need to consult with David on recent progress. The default is to use the AAS poster from 2006 for this section.

Classification, Alerts – Tim Axelrod

This section needs to be written from scratch - one page should be sufficient.


Middleware Overview – Ray Plante

  • Outline of slides:
    • High level diagram: of middleware showing connection from DMS/orchestration to application piplines.
    • Extra-pipeline components:
      • either a slide each or try to combine into 1 or 2
      • include listing of candidate technologies
      1. Pipeline Construction/Execution?
      2. Data Access Framework/Database? System Arch/Data? Transfer
      3. Events, Alerts, and System Management
    • Application Layer Support interfaces to Middleware
    • Metadata, Provenance, Persistence
    • Data Quality and End User Access Middleware
    • Conclusions, results/refinements from Data Challenges

Pipeline Construction/Execution? – Greg Daues/Franceceso? Pierfederici

  • Pipeline Control and Management
    1. configures and deploys a pipeline to a grid/cluster platform and monitors its progress
      • Orchestration/Workflow? middleware
        • OGRE/OgreScript (1,2)
        • Virtual Data System (VDS)
          • Part of Virtual Data Toolkit; formerly Chimera, contains Pegasus
      • Grid middleware
        • Condor and Globus technology (1,2)
        • ZeroC ICE : object middleware
        • MOAB scheduler
    2. manages parallel processing on HPC system : a Pipeline Manager instructs worker Slices in the execution of Stages
      • Message Passing interface [MPI-2 functionality with MPICH2] (1,2)
  • Pipeline Construction
    1. assemble pluggable stages into a full pipeline sequence
    2. support incorporation of upgraded modules to apply new algorithms seamlessly
      • Lightweight Python Glue Layer (1,2)
      • Common Component Architecture implementations : SCIRun, Ccaffiene
        1 - used in DC1, 2 - part of DC2

Data Access Framework - Ray Plante

Data Replication – Ray Plante

  • hops: mtn-base-archive center, archive center-data centers, internal replication (archive-processing platform)
  • a replication system featuring high-bandwidth utilization
  • a configurable framework that can make use of different protocols/strategies (what's available, tuned to use of data)
  • replica location management for smart replication
  • tools of interest:
    • UDT & Sector (2)
    • NOAO Data Service (1,2)
    • SRB->IRODS (1)
    • Xrootd
    • parallel filesystems
    • Trebuchet (1) 1 - used in DC1, 2 - part of DC2

Data Access and Archive Services Ray Plante

  • identifier based access
  • VO services

Database System Architecture - Jacek Becla

  • DB System Architecture features to highlight
    • query partitioning
    • data/index partitioning
    • serving main indexes from memory
    • concepts from scalable google architecture
    • concepts from scalable ebay architecture

Events, Alerts, and System Management – Steve Pietrowicz

  • Event System Architecture features to hightlight
    • Event types: Monitor, Exception, Fault, Alert
    • Event topic subscriptions
    • Event archival
    • Portal interface to event status
    • Leveraging existing technologies: Mule, JMS, STOMP, Netlogger

Application Layer Support interfaces to Middleware – Ray Plante

Metadata, Provenance, Persistence – Ray Plante/Jeff? Kantor

This will be an extract of the EA DC2 model for these support classes.

Data Quality and End User Access Middleware – Deborah Levine/Serge? Monkewitz


Infrastructure Overview – Don Dossa

  • Overall high level computing infrastructure from camera/RNA output to archive center
  • Will use MREFC as starting point
    • New detailed configuration slides reflecting latest comp/disk needs
    • Computing configuration if built today
    • Likely computing/disk products and costs at construction based upon real system performance projections and not merely chips

Mountain/Base Computing/Storage/Local? Networking – Don Dossa

  • Image buffering on mountain cluster to parallel file system
  • Summit / base network config
  • Base camp cluster and file systems for DB, images, templates, alert generation
  • Reliability estimate and single point of failure analysis
  • Base computer room power and space requirements
    • LSST computing/storage
    • Chilean data access center
  • Interface into long haul network

Long Haul Networking – Ron Lambert/Chris? Smith

Archive Center Computing/Storage/Local? Networking – Chris Cribbs

  • Archive Center Infrastructure
    • Compute Node Infrastructure
    • Storage Infrastructure
    • Tape vs Disk for long term storage.
    • Power consumption and floor space requirements
    • Network Infrastructure

U.S. Data Access Center Computing/Storage/Local? Networking – Arun Jagatheesan

Chilean Data Access Center Computing/Storage/Local? Networking – Chris Smith

Remaining R&D/Data Challenges – Jeff Kantor

This will be an extract and summary of the DM Section of the LSST R&D Plan.

Software Standards and Process – Robyn Allsman/Jeff? Kantor

This will be an extract and summary of the C++, Python, Code Review, and Build documentation in the trac